문서

• 1: 쿠버네티스 문서
• 1.1: 사용 가능한 문서의 버전
• 2: 시작하기
• 2.1: 학습 환경
• 2.2: 프로덕션 환경
• 2.2.1: 컨테이너 런타임
• 2.2.2: 배포 도구로 쿠버네티스 설치하기
• 2.2.2.1: kubeadm으로 클러스터 구성하기
• 2.2.2.1.1: kubeadm 설치하기
• 2.2.2.1.2: kubeadm API로 컴포넌트 사용자 정의하기
• 2.2.2.1.3: 고가용성 토폴로지 선택
• 2.2.2.2: Kops로 쿠버네티스 설치하기
• 2.2.2.3: Kubespray로 쿠버네티스 설치하기
• 2.2.3: 턴키 클라우드 솔루션
• 2.2.4: 쿠버네티스에서 윈도우
• 2.2.4.1: 쿠버네티스에서 윈도우 컨테이너
• 2.2.4.2: 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드
• 2.3: 모범 사례
• 2.3.1: 대형 클러스터에 대한 고려 사항
• 2.3.2: 여러 영역에서 실행
• 2.3.3: 노드 구성 검증하기
• 2.3.4: PKI 인증서 및 요구 사항
• 3: 개념
• 3.1: 개요
• 3.1.1: 쿠버네티스란 무엇인가?
• 3.1.2: 쿠버네티스 컴포넌트
• 3.1.3: 쿠버네티스 API
• 3.1.4: 쿠버네티스 오브젝트로 작업하기
• 3.1.4.1: 쿠버네티스 오브젝트 이해하기
• 3.1.4.2: 쿠버네티스 오브젝트 관리
• 3.1.4.3: 오브젝트 이름과 ID
• 3.1.4.4: 네임스페이스
• 3.1.4.5: 레이블과 셀렉터
• 3.1.4.6: 어노테이션
• 3.1.4.7: 필드 셀렉터
• 3.1.4.8: 권장 레이블
• 3.2: 클러스터 아키텍처
• 3.2.1: 노드
• 3.2.2: 컨트롤 플레인-노드 간 통신
• 3.2.3: 컨트롤러
• 3.2.4: 클라우드 컨트롤러 매니저
• 3.3: 컨테이너
• 3.3.1: 이미지
• 3.3.2: 런타임클래스(RuntimeClass)
• 3.3.3: 컨테이너 환경 변수
• 3.3.4: 컨테이너 라이프사이클 훅(Hook)
• 3.4: 워크로드
• 3.4.1: 파드
• 3.4.1.1: 파드 라이프사이클
• 3.4.1.2: 초기화 컨테이너
• 3.4.1.3: 파드 토폴로지 분배 제약 조건
• 3.4.1.4: 중단(disruption)
• 3.4.1.5: 임시(Ephemeral) 컨테이너
• 3.4.2: 워크로드 리소스
• 3.4.2.1: 디플로이먼트
• 3.4.2.2: 레플리카셋
• 3.4.2.3: 스테이트풀셋
• 3.4.2.4: 데몬셋
• 3.4.2.5: 잡
• 3.4.2.6: 가비지(Garbage) 수집
• 3.4.2.7: 완료된 리소스를 위한 TTL 컨트롤러
• 3.4.2.8: 크론잡
• 3.4.2.9: 레플리케이션 컨트롤러
• 3.5: 서비스, 로드밸런싱, 네트워킹
• 3.5.1: 서비스
• 3.5.2: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅
• 3.5.3: 서비스 및 파드용 DNS
• 3.5.4: 서비스와 애플리케이션 연결하기
• 3.5.5: 인그레스 컨트롤러
• 3.5.6: 인그레스(Ingress)
• 3.5.7: 서비스 내부 트래픽 정책
• 3.5.8: 엔드포인트슬라이스
• 3.5.9: 네트워크 정책
• 3.5.10: IPv4/IPv6 이중 스택
• 3.6: 스토리지
• 3.6.1: 볼륨
• 3.6.2: 볼륨 스냅샷
• 3.6.3: 퍼시스턴트 볼륨
• 3.6.4: CSI 볼륨 복제하기
• 3.6.5: 볼륨 스냅샷 클래스
• 3.6.6: 스토리지 클래스
• 3.6.7: 동적 볼륨 프로비저닝
• 3.6.8: 스토리지 용량
• 3.6.9: 노드 별 볼륨 한도
• 3.6.10: 볼륨 헬스 모니터링
• 3.7: 구성
• 3.7.1: 구성 모범 사례
• 3.7.2: 컨피그맵(ConfigMap)
• 3.7.3: 시크릿(Secret)
• 3.7.4: 컨테이너 리소스 관리
• 3.7.5: kubeconfig 파일을 사용하여 클러스터 접근 구성하기
• 3.8: 보안
• 3.8.1: 클라우드 네이티브 보안 개요
• 3.8.2: 쿠버네티스 API 접근 제어하기
• 3.9: 스케줄링, 선점(Preemption), 축출(Eviction)
• 3.9.1: 쿠버네티스 스케줄러
• 3.9.2: 노드에 파드 할당하기
• 3.9.3: 파드 오버헤드
• 3.9.4: 테인트(Taints)와 톨러레이션(Tolerations)
• 3.9.5: 노드-압박 축출
• 3.9.6: API를 이용한 축출(Eviction)
• 3.9.7: 파드 우선순위(priority)와 선점(preemption)
• 3.9.8: 확장된 리소스를 위한 리소스 빈 패킹(bin packing)
• 3.9.9: 스케줄러 성능 튜닝
• 3.10: 정책
• 3.10.1: 리밋 레인지(Limit Range)
• 3.10.2: 리소스 쿼터
• 3.10.3: 파드 시큐리티 폴리시
• 3.10.4: 노드 리소스 매니저
• 3.11: 클러스터 관리
• 3.11.1: 인증서
• 3.11.2: 리소스 관리
• 3.11.3: 클러스터 네트워킹
• 3.11.4: 로깅 아키텍처
• 3.11.5: 시스템 로그
• 3.11.6: 쿠버네티스 시스템 컴포넌트에 대한 메트릭
• 3.11.7: kubelet 가비지(Garbage) 수집 설정하기
• 3.11.8: 쿠버네티스에서 프락시(Proxy)
• 3.11.9: 애드온 설치
• 3.12: 쿠버네티스 확장
• 3.12.1: 쿠버네티스 API 확장하기
• 3.12.1.1: 커스텀 리소스
• 3.12.1.2: 쿠버네티스 API 애그리게이션 레이어(aggregation layer)
• 3.12.2: 오퍼레이터(operator) 패턴
• 3.12.3: 컴퓨트, 스토리지 및 네트워킹 익스텐션
• 3.12.3.1: 네트워크 플러그인
• 3.12.3.2: 장치 플러그인
• 3.12.4: 서비스 카탈로그
• 4: 태스크
• 4.1: 도구 설치
• 4.1.1: macOS에 kubectl 설치 및 설정
• 4.1.2: 리눅스에 kubectl 설치 및 설정
• 4.1.3: 윈도우에 kubectl 설치 및 설정
• 4.1.4: 포함된 도구들
• 4.1.4.1: kubectl 설치 검증하기
• 4.1.4.2: kubectl-convert 개요
• 4.1.4.3: macOS에서 bash 자동 완성 사용하기
• 4.1.4.4: zsh 자동 완성
• 4.1.4.5: 다음 단계는 무엇인가?
• 4.1.4.6: 리눅스에서 bash 자동 완성 사용하기
• 4.2: 클러스터 운영
• 4.2.1: kubeadm으로 관리하기
• 4.2.1.1: kubeadm을 사용한 인증서 관리
• 4.2.1.2: kubeadm 클러스터 업그레이드
• 4.2.1.3: 윈도우 노드 추가
• 4.2.1.4: 윈도우 노드 업그레이드
• 4.2.2: 메모리, CPU 와 API 리소스 관리
• 4.2.2.1: 네임스페이스에 대한 기본 메모리 요청량과 상한 구성
• 4.2.2.2: 네임스페이스에 대한 기본 CPU 요청량과 상한 구성
• 4.2.2.3: 네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성
• 4.2.2.4: 네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성
• 4.2.2.5: 네임스페이스에 대한 메모리 및 CPU 쿼터 구성
• 4.2.2.6: 네임스페이스에 대한 파드 쿼터 구성
• 4.2.3: 인증서
• 4.2.4: 네트워크 폴리시 제공자(Network Policy Provider) 설치
• 4.2.4.1: 네트워크 폴리시로 캘리코(Calico) 사용하기
• 4.2.4.2: 네트워크 폴리시로 실리움(Cilium) 사용하기
• 4.2.4.3: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기
• 4.2.4.4: 네트워크 폴리시로 로마나(Romana)
• 4.2.4.5: 네트워크 폴리시로 위브넷(Weave Net) 사용하기
• 4.2.5: DNS 서비스 사용자 정의하기
• 4.2.6: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기
• 4.2.7: 기본 스토리지클래스(StorageClass) 변경하기
• 4.2.8: 네트워크 폴리시(Network Policy) 선언하기
• 4.2.9: 노드에 대한 확장 리소스 알리기
• 4.2.10: 서비스 디스커버리를 위해 CoreDNS 사용하기
• 4.2.11: 중요한 애드온 파드 스케줄링 보장하기
• 4.2.12: 쿠버네티스 API 활성화 혹은 비활성화하기
• 4.2.13: 쿠버네티스 API를 사용하여 클러스터에 접근하기
• 4.2.14: 쿠버네티스 클러스터에서 sysctl 사용하기
• 4.2.15: 클러스터에서 실행되는 서비스에 접근
• 4.2.16: 토폴로지 인지 힌트 활성화하기
• 4.2.17: 퍼시스턴트볼륨 반환 정책 변경하기
• 4.3: 파드와 컨테이너 설정
• 4.3.1: 컨테이너 및 파드 메모리 리소스 할당
• 4.3.2: 윈도우 파드 및 컨테이너에서 RunAsUserName 구성
• 4.3.3: 윈도우 파드와 컨테이너용 GMSA 구성
• 4.3.4: 파드에 대한 서비스 품질(QoS) 구성
• 4.3.5: 스토리지의 볼륨을 사용하는 파드 구성
• 4.3.6: 스토리지로 퍼시스턴트볼륨(PersistentVolume)을 사용하도록 파드 설정하기
• 4.3.7: 프라이빗 레지스트리에서 이미지 받아오기
• 4.3.8: 노드 어피니티를 사용해 노드에 파드 할당
• 4.3.9: 노드에 파드 할당
• 4.3.10: 초기화 컨테이너에 대한 구성
• 4.3.11: 스태틱(static) 파드 생성하기
• 4.4: 쿠버네티스 오브젝트 관리
• 4.4.1: 구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리
• 4.4.2: Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리
• 4.4.3: 명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기
• 4.4.4: 구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리
• 4.5: 시크릿(Secret) 관리
• 4.5.1: kubectl을 사용한 시크릿 관리
• 4.5.2: 환경 설정 파일을 사용하여 시크릿을 관리
• 4.5.3: kustomize를 사용하여 시크릿 관리
• 4.6: 애플리케이션에 데이터 주입하기
• 4.6.1: 컨테이너를 위한 커맨드와 인자 정의하기
• 4.6.2: 종속 환경 변수 정의하기
• 4.6.3: 컨테이너를 위한 환경 변수 정의하기
• 4.6.4: 환경 변수로 컨테이너에 파드 정보 노출하기
• 4.6.5: 파일로 컨테이너에 파드 정보 노출하기
• 4.6.6: 시크릿(Secret)을 사용하여 안전하게 자격증명 배포하기
• 4.7: 애플리케이션 실행
• 4.7.1: 디플로이먼트(Deployment)로 스테이트리스 애플리케이션 실행하기
• 4.7.2: 단일 인스턴스 스테이트풀 애플리케이션 실행하기
• 4.7.3: 스테이트풀셋(StatefulSet) 삭제하기
• 4.7.4: 스테이트풀셋(StatefulSet) 파드 강제 삭제하기
• 4.7.5: Horizontal Pod Autoscaler
• 4.7.6: Horizontal Pod Autoscaler 연습
• 4.7.7: 파드 내에서 쿠버네티스 API에 접근
• 4.8: 잡(Job) 실행
• 4.8.1: 크론잡(CronJob)으로 자동화된 작업 실행
• 4.8.2: 작업 대기열을 사용한 거친 병렬 처리
• 4.8.3: 작업 대기열을 사용한 정밀 병렬 처리
• 4.8.4: 확장을 사용한 병렬 처리
• 4.9: 클러스터 내 어플리케이션 접근
• 4.9.1: 쿠버네티스 대시보드를 배포하고 접속하기
• 4.9.2: 클러스터 접근
• 4.9.3: 다중 클러스터 접근 구성
• 4.9.4: 포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기
• 4.9.5: 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기
• 4.9.6: 서비스를 사용하여 프론트엔드를 백엔드에 연결
• 4.9.7: NGINX 인그레스(Ingress) 컨트롤러로 Minikube에서 인그레스 설정하기
• 4.9.8: 클러스터 내 모든 컨테이너 이미지 목록 보기
• 4.9.9: 공유 볼륨을 이용하여 동일한 파드의 컨테이너 간에 통신하기
• 4.9.10: 클러스터의 DNS 구성하기
• 4.10: 모니터링, 로깅, 그리고 디버깅
• 4.10.1: 동작 중인 파드 디버그
• 4.10.2: 동작중인 컨테이너의 셸에 접근하기
• 4.10.3: 리소스 메트릭 파이프라인
• 4.10.4: 리소스 모니터링 도구
• 4.10.5: 스테이트풀셋 디버깅하기
• 4.10.6: 초기화 컨테이너(Init Containers) 디버그하기
• 4.10.7: 파드 실패의 원인 검증하기
• 4.10.8: 파드와 레플리케이션컨트롤러(ReplicationController) 디버그하기
• 4.11: 쿠버네티스 확장
• 4.11.1: 확장 API 서버 설정
• 4.11.2: Konnectivity 서비스 설정
• 4.12: TLS
• 4.12.1: Kubelet의 인증서 갱신 구성
• 4.12.2: 클러스터에서 TLS 인증서 관리
• 4.13: 클러스터 데몬 관리
• 4.13.1: 데몬셋(DaemonSet)에서 롤링 업데이트 수행
• 4.13.2: 데몬셋(DaemonSet)에서 롤백 수행
• 4.14: 서비스 카탈로그
• 4.14.1: SC로 서비스 카탈로그 설치하기
• 4.15: 네트워킹
• 4.15.1: HostAliases로 파드의 /etc/hosts 항목 추가하기
• 4.15.2: IPv4/IPv6 이중 스택 검증
• 4.16: GPU 스케줄링
• 4.17: HugePages 관리
• 4.18: 플러그인으로 kubectl 확장
• 5: 튜토리얼
• 5.1: Hello Minikube
• 5.2: 쿠버네티스 기초 학습
• 5.2.1: 클러스터 생성하기
• 5.2.1.1: Minikube를 사용해서 클러스터 생성하기
• 5.2.1.2: 대화형 튜토리얼 - 클러스터 생성하기
• 5.2.2: 앱 배포하기
• 5.2.2.1: kubectl을 사용해서 디플로이먼트 생성하기
• 5.2.2.2: 대화형 튜토리얼 - 앱 배포하기
• 5.2.3: 앱 조사하기
• 5.2.3.1: 파드와 노드 보기
• 5.2.3.2: 대화형 튜토리얼 - 앱 조사하기
• 5.2.4: 앱 외부로 노출하기
• 5.2.4.1: 앱 노출을 위해 서비스 이용하기
• 5.2.4.2: 대화형 튜토리얼 - 앱 노출하기
• 5.2.5: 앱 스케일링하기
• 5.2.5.1: 복수의 앱 인스턴스를 구동하기
• 5.2.5.2: 대화형 튜토리얼 - 앱 스케일링하기
• 5.2.6: 앱 업데이트하기
• 5.2.6.1: 롤링 업데이트 수행하기
• 5.2.6.2: 대화형 튜토리얼 - 앱 업데이트 하기
• 5.3: 설정
• 5.3.1: 예제: Java 마이크로서비스 구성하기
• 5.3.1.1: MicroProfile, 컨피그맵(ConfigMaps) 및 시크릿(Secrets)을 사용하여 구성 외부화(externalizing)
• 5.3.1.2: 대화형 튜토리얼 - Java 마이크로서비스 구성하기
• 5.3.2: 컨피그맵을 사용해서 Redis 설정하기
• 5.4: 상태 유지를 하지 않는 애플리케이션
• 5.4.1: 외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기
• 5.4.2: 예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기
• 5.5: 상태 유지가 필요한(stateful) 애플리케이션
• 5.5.1: 스테이트풀셋 기본
• 5.5.2: 예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기
• 5.5.3: 예시: 카산드라를 스테이트풀셋으로 배포하기
• 5.5.4: 분산 시스템 코디네이터 ZooKeeper 실행하기
• 5.6: 클러스터
• 5.6.1: AppArmor를 사용하여 리소스에 대한 컨테이너의 접근 제한
• 5.7: 서비스
• 5.7.1: 소스 IP 주소 이용하기
• 6: 레퍼런스
• 6.1: 용어집
• 6.2: API 개요
• 6.2.1: 클라이언트 라이브러리
• 6.2.2: 쿠버네티스 API 헬스(health) 엔드포인트
• 6.3: API 접근 제어
• 6.3.1: 서비스 어카운트 관리하기
• 6.3.2: 인가 개요
• 6.4: 잘 알려진 레이블, 어노테이션, 테인트(Taint)
• 6.5: 쿠버네티스 이슈와 보안
• 6.5.1: 쿠버네티스 이슈 트래커
• 6.5.2: 쿠버네티스 보안과 공개 정보
• 6.6: 설치 도구
• 6.6.1: Kubeadm
• 6.6.1.1: Kubeadm Generated
• 6.7: 포트와 프로토콜
• 6.8: kubectl
• 6.8.1: kubectl 개요
• 6.8.2: JSONPath 지원
• 6.8.3: kubectl
• 6.8.4: kubectl 사용 규칙
• 6.8.5: kubectl 치트 시트
• 6.8.6: 도커 사용자를 위한 kubectl
• 6.9: 컴포넌트 도구
• 6.9.1: 기능 게이트
• 6.9.2: kube-proxy
• 6.9.3: Kubelet 인증/인가
• 6.10: 스케줄링
• 6.10.1: 스케줄링 정책
• 6.10.2: 스케줄러 구성
• 6.11: 도구
• 7: K8s 문서에 기여하기
• 7.1: 콘텐츠 개선 제안
• 7.2: 새로운 콘텐츠 기여하기
• 7.2.1: 풀 리퀘스트 열기
• 7.3: 변경 사항 리뷰하기
• 7.3.1: 풀 리퀘스트 리뷰
• 7.3.2: 승인자와 리뷰어의 리뷰
• 7.4: SIG Docs에 참여하기
• 7.4.1: 역할과 책임
• 7.4.2: PR 랭글러(PR Wrangler)
• 7.5: 레퍼런스 문서 개요
• 7.5.1: 퀵스타트 가이드
• 7.5.2:
• 7.6: 문서 스타일 개요
• 7.6.1: 새로운 주제의 문서 작성
• 7.7: 고급 기여
• 7.8: 사이트 분석 보기
• 7.9: 쿠버네티스 문서 한글화 가이드

1 - 쿠버네티스 문서

1.1 - 사용 가능한 문서의 버전

이 웹사이트에서는 쿠버네티스 최신 버전 및 이전 4개 버전에 대한 문서를 제공하고 있다.

2 - 시작하기

본 섹션에는 쿠버네티스를 설정하고 실행하는 다양한 방법이 나열되어 있다. 쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고 클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다.

쿠버네티스를 다운로드하여 로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다.

쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, 인증된 플랫폼과 같은 매니지드 서비스를 선택할 수도 있다. 광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 표준화된/맞춤형 솔루션도 있다.

학습 환경

쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용한다. 도구 설치를 살펴본다.

프로덕션 환경

프로덕션 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터(또는 추상화된 객체) 운영에 대한 어떤 측면을 스스로 관리하기를 원하는지, 또는 제공자에게 넘기기를 원하는지 고려한다.

클러스터를 직접 관리하는 경우, 공식적으로 지원되는 쿠버네티스 구축 도구는 kubeadm이다.

다음 내용

• 쿠버네티스를 다운로드한다.
• kubectl을 포함한 도구를 설치한다.
• 새로운 클러스터에 사용할 컨테이너 런타임을 선택한다.
• 클러스터 구성의 모범 사례를 확인한다.

쿠버네티스의 컨트롤 플레인은 리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는 다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다.

• 윈도우 노드를 포함하는 클러스터 구성하기를 살펴본다.

2.1 - 학습 환경

2.2 - 프로덕션 환경

프로덕션 수준의 쿠버네티스 클러스터에는 계획과 준비가 필요하다. 쿠버네티스 클러스터에 중요한 워크로드를 실행하려면 클러스터를 탄력적이도록 구성해야 한다. 이 페이지에서는 프로덕션용 클러스터를 설정하거나 기존 클러스터를 프로덕션용으로 업그레이드하기 위해 수행할 수 있는 단계를 설명한다. 이미 프로덕션 구성 내용에 익숙하여 단지 링크를 찾고 있다면, 다음 내용을 참고한다.

프로덕션 고려 사항

일반적으로 프로덕션 쿠버네티스 클러스터 환경에는 개인 학습용, 개발용 또는 테스트 환경용 클러스터보다 더 많은 요구 사항이 있다. 프로덕션 환경에는 많은 사용자의 보안 액세스, 일관된 가용성 및 변화하는 요구를 충족하기 위한 리소스가 필요할 수 있다.

프로덕션 쿠버네티스 환경이 상주할 위치(온 프레미스 또는 클라우드)와 직접 처리하거나 다른 사람에게 맡길 관리의 양을 결정할 때, 쿠버네티스 클러스터에 대한 요구 사항이 다음 이슈에 의해 어떻게 영향을 받는지 고려해야 한다.

• 가용성: 단일 머신 쿠버네티스 학습 환경은 SPOF(Single Point of Failure, 단일 장애 지점) 이슈를 갖고 있다. 고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다.

  • 컨트롤 플레인과 워크 노드를 분리
  • 컨트롤 플레인 구성요소를 여러 노드에 복제
  • 클러스터의 API 서버로 가는 트래픽을 로드밸런싱
  • 워커 노드를 충분히 운영하거나, 워크로드 변경에 따라 빠르게 제공할 수 있도록 보장

• 스케일링: 프로덕션 쿠버네티스 환경에 들어오는 요청의 양의 일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, 컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다.

• 보안 및 접근 관리: 학습을 위한 쿠버네티스 클러스터에는 완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다. 역할 기반 접근 제어(RBAC) 및 기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. 정책과 컨테이너 리소스를 관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다.

쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를 턴키 클라우드 솔루션 제공 업체 또는 기타 쿠버네티스 파트너에게 넘기는 것을 고려할 수 있다. 다음과 같은 옵션이 있다.

• 서버리스: 클러스터를 전혀 관리하지 않고 타사 장비에서 워크로드를 실행하기만 하면 된다. CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다.
• 관리형 컨트롤 플레인: 쿠버네티스 서비스 공급자가 클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다.
• 관리형 워커 노드: 필요에 맞는 노드 풀을 정의하면, 쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 필요 시 업그레이드 제공을 보장한다.
• 통합: 쿠버네티스를 스토리지, 컨테이너 레지스트리, 인증 방법 및 개발 도구와 같이 사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다.

프로덕션 쿠버네티스 클러스터를 직접 구축하든 파트너와 협력하든, 요구 사항이 컨트롤 플레인, 워커 노드, 사용자 접근, 워크로드 자원과 관련되기 때문에, 다음 섹션들을 검토하는 것이 바람직하다.

프로덕션 클러스터 구성

프로덕션 수준 쿠버네티스 클러스터에서, 컨트롤 플레인은 다양한 방식으로 여러 컴퓨터에 분산될 수 있는 서비스들을 통해 클러스터를 관리한다. 반면, 각 워커 노드는 쿠버네티스 파드를 실행하도록 구성된 단일 엔티티를 나타낸다.

프로덕션 컨트롤 플레인

가장 간단한 쿠버네티스 클러스터는 모든 컨트롤 플레인 및 워커 노드 서비스가 하나의 머신에 실행되는 클러스터이다. 쿠버네티스 컴포넌트 그림에 명시된 대로, 워커 노드를 추가하여 해당 환경을 확장할 수 있다. 클러스터를 단기간만 사용하거나, 심각한 문제가 발생한 경우 폐기하는 것이 가능하다면, 이 방식을 선택할 수 있다.

그러나 더 영구적이고 가용성이 높은 클러스터가 필요한 경우 컨트롤 플레인 확장을 고려해야 한다. 설계 상, 단일 시스템에서 실행되는 단일 시스템 컨트롤 플레인 서비스는 가용성이 높지 않다. 클러스터를 계속 유지하면서 문제가 발생한 경우 복구할 수 있는지 여부가 중요한 경우, 다음 사항들을 고려한다.

• 배포 도구 선택: kubeadm, kops, kubespray와 같은 도구를 이용해 컨트롤 플레인을 배포할 수 있다. 배포 도구로 쿠버네티스 설치하기에서 여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. 배포 시, 다양한 컨테이너 런타임을 사용할 수 있다.
• 인증서 관리: 컨트롤 플레인 서비스 간의 보안 통신은 인증서를 사용하여 구현된다. 인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. PKI 인증서 및 요구 조건에서 상세 사항을 확인한다.
• apiserver를 위한 로드밸런서 구성: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에 외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. 외부 로드밸런서 생성하기에서 상세 사항을 확인한다.
• etcd 서비스 분리 및 백업: etcd 서비스는 다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, 또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. etcd는 클러스터 구성 데이터를 저장하므로 필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다. etcd FAQ에서 etcd 구성 및 사용 상세를 확인한다. 쿠버네티스를 위한 etcd 클러스터 운영하기와 kubeadm을 이용하여 고가용성 etcd 생성하기에서 상세 사항을 확인한다.
• 다중 컨트롤 플레인 시스템 구성: 고가용성을 위해, 컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. 컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, 각 서비스는 최소 3대의 머신에서 실행되어야 한다. 그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 각 서비스 복제본 요청이 보장된다. 스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다. 일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 Raft 합의 알고리즘을 설정한다. 리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다.
• 다중 영역(zone)으로 확장: 클러스터를 항상 사용 가능한 상태로 유지하는 것이 중요하다면 여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 클러스터를 만드는 것이 좋다. 영역의 그룹을 지역(region)이라고 한다. 동일한 지역의 여러 영역에 클러스터를 분산하면 하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다. 여러 영역에서 실행에서 상세 사항을 확인한다.
• 구동 중인 기능 관리: 클러스터를 계속 유지하려면, 상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. 예를 들어 kubeadm으로 클러스터를 생성한 경우, 인증서 관리와 kubeadm 클러스터 업그레이드하기에 대해 도움이 되는 가이드가 있다. 클러스터 운영하기에서 더 많은 쿠버네티스 관리 작업을 볼 수 있다.

컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 보려면, kube-apiserver, kube-controller-manager, kube-scheduler를 참조한다. 고가용성 컨트롤 플레인 예제는 고가용성 토폴로지를 위한 옵션, kubeadm을 이용하여 고가용성 클러스터 생성하기, 쿠버네티스를 위한 etcd 클러스터 운영하기를 참조한다. etcd 백업 계획을 세우려면 etcd 클러스터 백업하기를 참고한다.

프로덕션 워커 노드

프로덕션 수준 워크로드는 복원력이 있어야 하고, 이들이 의존하는 모든 것들(예: CoreDNS)도 복원력이 있어야 한다. 컨트롤 플레인을 자체적으로 관리하든 클라우드 공급자가 대신 수행하도록 하든 상관없이, 워커 노드(간단히 노드라고도 함)를 어떤 방법으로 관리할지 고려해야 한다.

• 노드 구성하기: 노드는 물리적 또는 가상 머신일 수 있다. 직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 적절한 노드 서비스를 추가하고 실행한다. 다음을 고려해야 한다.
  • 워크로드의 요구 사항 (노드가 적절한 메모리, CPU, 디스크 속도, 저장 용량을 갖도록 구성)
  • 일반적인 컴퓨터 시스템이면 되는지, 아니면 GPU, 윈도우 노드, 또는 VM 격리를 필요로 하는 워크로드가 있는지
• 노드 검증하기: 노드 구성 검증하기에서 노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 만족하는지 확인하는 방법을 알아본다.
• 클러스터에 노드 추가하기: 클러스터를 자체적으로 관리하는 경우, 머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. 이러한 방식으로 노드를 추가하는 방법을 보려면 노드 섹션을 확인한다.
• 클러스터에 윈도우 노드 추가하기: 윈도우 컨테이너로 구현된 워크로드를 실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다. 쿠버네티스에서의 윈도우에서 상세 사항을 확인한다.
• 노드 스케일링: 클러스터가 최종적으로 필요로 하게 될 용량만큼 확장하는 것에 대한 계획이 있어야 한다. 실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 대형 클러스터에 대한 고려 사항을 확인한다. 만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다.
• 노드 자동 스케일링: 대부분의 클라우드 공급자는 비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 클러스터 오토스케일러를 지원한다. 자주 묻는 질문에서 오토스케일러가 어떻게 동작하는지, 배치 섹션에서 각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. 온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 스크립트를 구성할 수 있는 가상화 플랫폼이 있다.
• 노드 헬스 체크 구성: 중요한 워크로드의 경우, 해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. Node Problem Detector 데몬을 사용하면 노드가 정상인지 확인할 수 있다.

프로덕션 사용자 관리

프로덕션에서는, 클러스터를 한 명 또는 여러 명이 사용하던 모델에서 수십에서 수백 명이 사용하는 모델로 바꿔야 하는 경우가 발생할 수 있다. 학습 환경 또는 플랫폼 프로토타입에서는 모든 작업에 대한 단일 관리 계정으로도 충분할 수 있다. 프로덕션에서는 여러 네임스페이스에 대한, 액세스 수준이 각각 다른 더 많은 계정이 필요하다.

프로덕션 수준의 클러스터를 사용한다는 것은 다른 사용자의 액세스를 선택적으로 허용할 방법을 결정하는 것을 의미한다. 특히 클러스터에 액세스를 시도하는 사용자의 신원을 확인(인증, authentication)하고 요청한 작업을 수행할 권한이 있는지 결정(인가, authorization)하기 위한 다음과 같은 전략을 선택해야 한다.

• 인증: apiserver는 클라이언트 인증서, 전달자 토큰, 인증 프록시 또는 HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다. 사용자는 인증 방법을 선택하여 사용할 수 있다. apiserver는 또한 플러그인을 사용하여 LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다. 쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 인증을 참조한다.
• 인가: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. 인가 개요에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다.
  • 역할 기반 접근 제어 (RBAC): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다.
  • 속성 기반 접근 제어 (ABAC): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(/version 또는 /apis)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 예시를 참조한다.

프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다.

• 인가 모드 설정: 쿠버네티스 API 서버(kube-apiserver)를 실행할 때, --authorization-mode 플래그를 사용하여 인증 모드를 설정해야 한다. 예를 들어, (*/etc/kubernetes/manifests*에 있는) kube-adminserver.yaml 파일 안의 플래그를 Node,RBAC으로 설정할 수 있다. 이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다.
• 사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우): RBAC 인증을 사용하는 경우, 사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. 그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다. 자세한 내용은 인증서 서명 요청을 참조한다.
• 속성을 포함하는 정책 생성(ABAC을 사용하는 경우): ABAC 인증을 사용하는 경우, 속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. 예시에서 더 많은 정보를 확인한다.
• 어드미션 컨트롤러 도입 고려: 웹훅 토큰 인증은 API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. 웹훅 및 다른 인가 형식을 사용하려면 API 서버에 어드미션 컨트롤러를 추가해야 한다.

워크로드에 자원 제한 걸기

프로덕션 워크로드의 요구 사항이 쿠버네티스 컨트롤 플레인 안팎의 압박을 초래할 수 있다. 워크로드의 요구 사항을 충족하도록 클러스터를 구성할 때 다음 항목을 고려한다.

• 네임스페이스 제한 설정: 메모리, CPU와 같은 자원의 네임스페이스 별 쿼터를 설정한다. 메모리, CPU 와 API 리소스 관리에서 상세 사항을 확인한다. 계층적 네임스페이스를 설정하여 제한을 상속할 수도 있다.
• DNS 요청에 대한 대비: 워크로드가 대규모로 확장될 것으로 예상된다면, DNS 서비스도 확장할 준비가 되어 있어야 한다. 클러스터의 DNS 서비스 오토스케일링을 확인한다.
• 추가적인 서비스 어카운트 생성: 사용자 계정은 클러스터에서 사용자가 무엇을 할 수 있는지 결정하는 반면에, 서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. 기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다. 서비스 어카운트 관리하기에서 새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다.
  • 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. 파드를 위한 서비스 어카운트 구성하기에서 예시를 확인한다.
  • 서비스 어카운트에 RBAC 권한을 할당한다. 서비스어카운트 권한에서 상세 사항을 확인한다.

다음 내용

• 프로덕션 쿠버네티스를 직접 구축할지, 아니면 턴키 클라우드 솔루션 또는 쿠버네티스 파트너가 제공하는 서비스를 이용할지 결정한다.
• 클러스터를 직접 구축한다면, 인증서를 어떻게 관리할지, etcd와 API 서버 등의 기능에 대한 고가용성을 어떻게 보장할지를 계획한다.
• 배포 도구로 kubeadm, kops, Kubespray 중 하나를 선택한다.
• 인증 및 인가 방식을 선택하여 사용자 관리 방법을 구성한다.
• 자원 제한, DNS 오토스케일링, 서비스 어카운트를 설정하여 애플리케이션 워크로드의 실행에 대비한다.

2.2.1 - 컨테이너 런타임

파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에 컨테이너 런타임을 설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고 노드 설정 관련 작업을 설명한다.

이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한 세부 정보가 있다.

• containerd
• CRI-O
• 도커

cgroup 드라이버

Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.

리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는 root control group(cgroup)을 생성 및 사용하는 cgroup 관리자로 작동한다. Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. 컨테이너 런타임과 kubelet이 cgroupfs를 사용하도록 설정할 수 있다. systemd와 함께 cgroupfs를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다.

단일 cgroup 관리자는 할당되는 리소스가 무엇인지를 단순화하고, 기본적으로 사용할 수 있는 리소스와 사용 중인 리소스를 일관성있게 볼 수 있다. 시스템에 두 개의 cgroup 관리자가 있으면, 이런 리소스도 두 개의 관점에서 보게 된다. 현장에서 사람들은 kubelet과 도커에 cgroupfs를 사용하고, 나머지 프로세스는 systemd를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때 불안정해지는 사례를 보고했다.

컨테이너 런타임과 kubelet이 systemd를 cgroup 드라이버로 사용하도록 설정을 변경하면 시스템이 안정화된다. 도커에 대해 구성하려면, native.cgroupdriver=systemd를 설정한다.

cgroup v2

cgroup v2는 cgroup Linux API의 다음 버전이다. cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.

새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다.

• API를 더 쉽고 깔끔하게 사용할 수 있음
• 컨테이너로의 안전한 하위 트리 위임
• 압력 중지 정보와 같은 새로운 기능

일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도, 쿠버네티스는 모든 컨트롤러를 관리하기 위해 동일한 cgroup 버전만 지원한다.

systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 systemd.unified_cgroup_hierarchy=1을 추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.

# dnf install -y grubby && \
  sudo grubby \
  --update-kernel=ALL \
  --args=”systemd.unified_cgroup_hierarchy=1"

구성을 적용하려면 노드를 재부팅해야 한다.

cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.

cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다.

kubeadm으로 생성한 클러스터의 드라이버를 systemd로 변경하기

kubeadm으로 생성한 클러스터의 cgroup 드라이버를 systemd로 변경하려면 변경 가이드를 참고한다.

컨테이너 런타임

containerd

이 섹션에는 containerd 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다.

필수 구성 요소를 설치 및 구성한다.

cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 필요한 sysctl 파라미터를 설정하면 재부팅 후에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

# 재부팅하지 않고 sysctl 파라미터 적용
sudo sysctl --system

containerd를 설치한다.

• Linux
• Windows (PowerShell)

2. 추출과 설정

```powershell
Copy-Item -Path ".\bin\" -Destination "$Env:ProgramFiles\containerd" -Recurse -Force
cd $Env:ProgramFiles\containerd\
.\containerd.exe config default | Out-File config.toml -Encoding ascii

# 설정을 검토한다. 설정에 따라 다음을 조정할 수 있다.
# - sandbox_image (쿠버네티스 일시중지 이미지)
# - cni bin 폴더와 conf 폴더 위치
Get-Content config.toml

# (선택사항 - 그러나 적극 권장함) Windows 디펜더 검사에서 containerd 제외
Add-MpPreference -ExclusionProcess "$Env:ProgramFiles\containerd\containerd.exe"

systemd cgroup 드라이버의 사용

/etc/containerd/config.toml 의 systemd cgroup 드라이버를 runc 에서 사용하려면, 다음과 같이 설정한다.

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

이 변경 사항을 적용하는 경우 containerd를 재시작한다.

sudo systemctl restart containerd

kubeadm을 사용하는 경우, kubelet용 cgroup 드라이버를 수동으로 구성한다.

CRI-O

이 섹션은 CRI-O를 컨테이너 런타임으로 설치하는 필수적인 단계를 담고 있다.

시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다.

필수 구성 요소를 설치하고 구성한다.

# .conf 파일을 만들어 부팅 시 모듈을 로드한다
cat <<EOF | sudo tee /etc/modules-load.d/crio.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 요구되는 sysctl 파라미터 설정, 이 설정은 재부팅 간에도 유지된다.
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sudo sysctl --system

• Debian
• Ubuntu
• CentOS
• openSUSE Tumbleweed
• Fedora

cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF

curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -

sudo apt-get update
sudo apt-get install cri-o cri-o-runc

cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /
EOF
cat <<EOF | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /
EOF

curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add -
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers-cri-o.gpg add -

apt-get update
apt-get install cri-o cri-o-runc

sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
sudo curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
sudo yum install cri-o

sudo zypper install cri-o

sudo dnf module list cri-o

sudo dnf module enable cri-o:$VERSION
sudo dnf install cri-o

CRI-O를 시작한다.

sudo systemctl daemon-reload
sudo systemctl enable crio --now

자세한 사항은 CRI-O 설치 가이드를 참고한다.

cgroup 드라이버

CRI-O는 기본적으로 systemd cgroup 드라이버를 사용한다. cgroupfs cgroup 드라이버로 전환하려면, /etc/crio/crio.conf 를 수정하거나 /etc/crio/crio.conf.d/02-cgroup-manager.conf 에 드롭-인(drop-in) 구성을 배치한다. 예를 들면, 다음과 같다.

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

또한 cgroupfs 와 함께 CRI-O를 사용할 때 pod 값으로 설정해야 하는 변경된 conmon_cgroup 에 유의한다. 일반적으로 kubelet(일반적으로 kubeadm을 통해 수행됨)과 CRI-O의 cgroup 드라이버 구성을 동기화 상태로 유지해야 한다.

도커

1. 각 노드에서 도커 엔진 설치에 따라 리눅스 배포판용 도커를 설치한다. 이 의존성 파일에서 검증된 최신 버전의 도커를 찾을 수 있다.

2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다.

   sudo mkdir /etc/docker
   cat <<EOF | sudo tee /etc/docker/daemon.json
   {
     "exec-opts": ["native.cgroupdriver=systemd"],
     "log-driver": "json-file",
     "log-opts": {
       "max-size": "100m"
     },
     "storage-driver": "overlay2"
   }
   EOF
   

   참고: overlay2는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다.

3. 도커 재시작과 부팅시 실행되게 설정

   sudo systemctl enable docker
   sudo systemctl daemon-reload
   sudo systemctl restart docker
   

2.2.2 - 배포 도구로 쿠버네티스 설치하기

2.2.2.1 - kubeadm으로 클러스터 구성하기

2.2.2.1.1 - kubeadm 설치하기

이 페이지에서는 kubeadm 툴박스 설치 방법을 보여준다. 이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 kubeadm을 사용하여 클러스터 생성하기 페이지를 참고한다.

시작하기 전에

• 호환되는 리눅스 머신. 쿠버네티스 프로젝트는 데비안 기반 배포판, 레드햇 기반 배포판, 그리고 패키지 매니저를 사용하지 않는 경우에 대한 일반적인 가이드를 제공한다.
• 2 GB 이상의 램을 장착한 머신. (이 보다 작으면 사용자의 앱을 위한 공간이 거의 남지 않음)
• 2 이상의 CPU.
• 클러스터의 모든 머신에 걸친 전체 네트워크 연결. (공용 또는 사설 네트워크면 괜찮음)
• 모든 노드에 대해 고유한 호스트 이름, MAC 주소 및 product_uuid. 자세한 내용은 여기를 참고한다.
• 컴퓨터의 특정 포트들 개방. 자세한 내용은 여기를 참고한다.
• 스왑의 비활성화. kubelet이 제대로 작동하게 하려면 반드시 스왑을 사용하지 않도록 설정한다.

MAC 주소 및 product_uuid가 모든 노드에 대해 고유한지 확인

• 사용자는 ip link 또는 ifconfig -a 명령을 사용하여 네트워크 인터페이스의 MAC 주소를 확인할 수 있다.
• product_uuid는 sudo cat /sys/class/dmi/id/product_uuid 명령을 사용하여 확인할 수 있다.

일부 가상 머신은 동일한 값을 가질 수 있지만 하드웨어 장치는 고유한 주소를 가질 가능성이 높다. 쿠버네티스는 이러한 값을 사용하여 클러스터의 노드를 고유하게 식별한다. 이러한 값이 각 노드에 고유하지 않으면 설치 프로세스가 실패할 수 있다.

네트워크 어댑터 확인

네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는 경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다.

iptables가 브리지된 트래픽을 보게 하기

br_netfilter 모듈이 로드되었는지 확인한다. lsmod | grep br_netfilter 를 실행하면 된다. 명시적으로 로드하려면 sudo modprobe br_netfilter 를 실행한다.

리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, sysctl 구성에서 net.bridge.bridge-nf-call-iptables 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다.

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

자세한 내용은 네트워크 플러그인 요구 사항 페이지를 참고한다.

필수 포트 확인

필수 포트들은 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야 한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다.

telnet 127.0.0.1 6443

사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도 있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한 플러그인 문서를 참고한다.

런타임 설치

파드에서 컨테이너를 실행하기 위해, 쿠버네티스는 컨테이너 런타임을 사용한다.

• 리눅스 노드
• 다른 운영 체제

kubeadm, kubelet 및 kubectl 설치

모든 머신에 다음 패키지들을 설치한다.

• kubeadm: 클러스터를 부트스트랩하는 명령이다.

• kubelet: 클러스터의 모든 머신에서 실행되는 파드와 컨테이너 시작과 같은 작업을 수행하는 컴포넌트이다.

• kubectl: 클러스터와 통신하기 위한 커맨드 라인 유틸리티이다.

kubeadm은 kubelet 또는 kubectl 을 설치하거나 관리하지 않으므로, kubeadm이 설치하려는 쿠버네티스 컨트롤 플레인의 버전과 일치하는지 확인해야 한다. 그렇지 않으면, 예상치 못한 버그 동작으로 이어질 수 있는 버전 차이(skew)가 발생할 위험이 있다. 그러나, kubelet과 컨트롤 플레인 사이에 하나의 마이너 버전 차이가 지원되지만, kubelet 버전은 API 서버 버전 보다 높을 수 없다. 예를 들어, 1.7.0 버전의 kubelet은 1.8.0 API 서버와 완전히 호환되어야 하지만, 그 반대의 경우는 아니다.

kubectl 설치에 대한 정보는 kubectl 설치 및 설정을 참고한다.

버전 차이에 대한 자세한 내용은 다음을 참고한다.

• 쿠버네티스 버전 및 버전-차이 정책
• Kubeadm 관련 버전 차이 정책

• 데비안 기반 배포판
• 레드햇 기반 배포판
• 패키지 매니저를 사용하지 않는 경우

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF

# permissive 모드로 SELinux 설정(효과적으로 비활성화)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

sudo systemctl enable --now kubelet

CNI_VERSION="v0.8.2"
ARCH="amd64"
sudo mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz

DOWNLOAD_DIR=/usr/local/bin
sudo mkdir -p $DOWNLOAD_DIR

CRICTL_VERSION="v1.17.0"
ARCH="amd64"
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz

RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
ARCH="amd64"
cd $DOWNLOAD_DIR
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}

RELEASE_VERSION="v0.4.0"
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service
sudo mkdir -p /etc/systemd/system/kubelet.service.d
curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

systemctl enable --now kubelet

kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로 기다려야 하므로 몇 초마다 다시 시작된다.

cgroup 드라이버 구성

컨테이너 런타임과 kubelet은 "cgroup 드라이버"라는 속성을 갖고 있으며, cgroup 드라이버는 리눅스 머신의 cgroup 관리 측면에 있어서 중요하다.

문제 해결

kubeadm에 문제가 있는 경우, 문제 해결 문서를 참고한다.

다음 내용

• kubeadm을 사용하여 클러스터 생성

2.2.2.1.2 - kubeadm API로 컴포넌트 사용자 정의하기

이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에 대해서는 Cluster Configuration 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과 kube-proxy의 경우, KubeletConfiguration과 KubeProxyConfiguration을 각각 사용할 수 있다.

이 모든 옵션이 kubeadm 구성 API를 통해 가용하다. 구성의 각 필드 상세 사항은 API 참조 페이지에서 찾아볼 수 있다.

ClusterConfiguration의 플래그로 컨트롤 플레인 사용자 정의하기

kubeadm의 ClusterConfiguration 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러, Etcd와 같은 컨트롤 플레인 컴포넌트에 전달되는 기본 플래그를 사용자가 덮어쓸 수 있도록 노출한다. 이 컴포넌트는 다음 구조체를 사용하여 정의된다.

• apiServer
• controllerManager
• scheduler
• etcd

이 구조체들은 공통 필드인 extraArgs를 포함하며, 이 필드는 키: 값 쌍으로 구성된다. 컨트롤 플레인 컴포넌트를 위한 플래그를 덮어쓰려면 다음을 수행한다.

1. 사용자 구성에 적절한 extraArgs 필드를 추가한다.
2. extraArgs 필드에 플래그를 추가한다.
3. kubeadm init에 --config <CONFIG YAML 파일> 파라미터를 추가해서 실행한다.

APIServer 플래그

자세한 내용은 kube-apiserver 레퍼런스 문서를 확인한다.

사용 예시:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
  extraArgs:
    anonymous-auth: "false"
    enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
    audit-log-path: /home/johndoe/audit.log

컨트롤러매니저 플래그

자세한 내용은 kube-controller-manager 레퍼런스 문서를 확인한다.

사용 예시:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
  extraArgs:
    cluster-signing-key-file: /home/johndoe/keys/ca.key
    deployment-controller-sync-period: "50"

스케줄러 플래그

자세한 내용은 kube-scheduler 레퍼런스 문서를 확인한다.

사용 예시:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
  extraArgs:
    config: /etc/kubernetes/scheduler-config.yaml
  extraVolumes:
    - name: schedulerconfig
      hostPath: /home/johndoe/schedconfig.yaml
      mountPath: /etc/kubernetes/scheduler-config.yaml
      readOnly: true
      pathType: "File"

Etcd 플래그

자세한 사항은 etcd 서버 문서를 확인한다.

사용 예시:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
  local:
    extraArgs:
      election-timeout: 1000

패치를 통해 컨트롤 플레인 사용자 정의하기

Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 InitConfiguration과 JoinConfiguration에 전달할 수 있다. 이 패치는 컨트롤 플레인 컴포넌트 메니패스트가 디스크에 기록되기 전에 최종 사용자 정의 단계로 사용될 수 있다.

--config <YOUR CONFIG YAML>을 사용하여 이 파일을 kubeadm init에 전달할 수 있다.

apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  patches:
    directory: /home/user/somedir

--config <YOUR CONFIG YAML>을 사용하여 이 파일을 kubeadm join에 전달할 수 있다.

apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
nodeRegistration:
  patches:
    directory: /home/user/somedir

디렉토리는 target[suffix][+patchtype].extension 형태의 파일을 포함해야 한다. 예를 들면, kube-apiserver0+merge.yaml 또는 단순히 etcd.json의 형태이다.

• target은 kube-apiserver, kube-controller-manager, kube-scheduler 그리고 etcd 중 하나가 될 수 있다.
• patchtype은 strategic, merge 그리고 json 중 하나가 될 수 있으며 kubectl에서 지원하는 패치 형식을 준수해야 한다. patchtype의 기본값은 strategic이다.
• extension은 json 또는 yaml 중 하나여야 한다.
• suffix는 어떤 패치가 먼저 적용되는지를 결정하는 데 사용할 수 있는 영숫자 형태의 선택적 문자열이다.

kubelet 사용자 정의하기

kubelet을 사용자 정의하려면, KubeletConfiguration을 동일한 구성 파일 내에서 ---로 구분된 ClusterConfiguration이나 InitConfiguration 다음에 추가하면 된다. 그런 다음 kubeadm init에 해당 파일을 전달한다.

자세한 사항은 kubeadm을 통해 클러스터의 각 kubelet 구성하기에서 살펴본다.

kube-proxy 사용자 정의하기

kube-proxy를 사용자 정의하려면, KubeProxyConfiguration을 ---로 구분된 ClusterConfiguration이나 InitConfiguration 다음에 두고 kubeadm init에 전달하면 된다.

자세한 사항은 API 참조 페이지에서 살펴볼 수 있다.

2.2.2.1.3 - 고가용성 토폴로지 선택

이 페이지는 고가용성(HA) 쿠버네티스 클러스터의 토플로지를 구성하는 두 가지 선택 사항을 설명한다.

다음과 같이 HA 클러스터를 구성할 수 있다.

• etcd 노드와 컨트롤 플레인 노드를 함께 위치시키는 중첩된(stacked) 컨트롤 플레인 노드 방식
• etcd와 컨트롤 플레인이 분리된 노드에서 운영되는 외부 etcd 노드 방식

HA 클러스터를 구성하기 전에 각 토플로지의 장단점을 주의 깊게 고려해야 한다.

중첩된 etcd 토플로지

중첩된 HA 클러스터는 etcd에서 제공하는 분산 데이터 저장소 클러스터를, 컨트롤 플레인 구성 요소를 실행하는 kubeadm으로 관리되는 노드에 의해서 형성된 클러스터 상단에 중첩하는 토플로지이다.

각 컨트롤 플레인 노드는 kube-apiserver, kube-scheduler, kube-controller-manager 인스턴스를 운영한다. kube-apiserver는 로드 밸런서를 이용하여 워커 노드에 노출되어 있다.

각 컨트롤 플레인 노드는 지역 etcd 맴버를 생성하고 이 etcd 맴버는 오직 해당 노드의 kube-apiserver와 통신한다. 비슷한 방식이 지역의 kube-controller-manager와 kube-scheduler에도 적용된다.

이 토플로지는 컨트롤 플레인과 etcd 맴버가 같은 노드에 묶여 있다. 이는 외부 etcd 노드의 클러스터를 구성하는 것보다는 단순하며 복제 관리도 간단하다.

그러나 중첩된 클러스터는 커플링에 실패할 위험이 있다. 한 노드가 다운되면 etcd 맴버와 컨트롤 플레인을 모두 잃어버리고, 중복성도 손상된다. 더 많은 컨트롤 플레인 노드를 추가하여 이 위험을 완화할 수 있다.

그러므로 HA 클러스터를 위해 최소 3개인 중첩된 컨트롤 플레인 노드를 운영해야 한다.

이는 kubeadm의 기본 토플로지이다. 지역 etcd 맴버는 kubeadm init와 kubeadm join --control-plane 을 이용할 때에 컨트롤 플레인 노드에 자동으로 생성된다.

외부 etcd 토플로지

외부 etcd를 이용하는 HA 클러스터는 etcd로 제공한 분산된 데이터 스토리지 클러스터가 컨트롤 플레인 구성 요소를 운영하는 노드로 형성하는 클러스터의 외부에 있는 토플로지이다.

중첩된 etcd 토플로지와 유사하게, 외부 etcd 토플로지에 각 컨트롤 플레인 노드는 kube-apiserver, kube-scheduler, kube-controller-manager의 인스턴스를 운영한다. 그리고 kube-apiserver는 로드 밸런서를 이용하여 워커노드에 노출한다. 그러나 etcd 맴버는 분리된 호스트에서 운영되고, 각 etcd 호스트는 각 컨트롤 플레인 노드의 kube-apiserver와 통신한다.

이 토플로지는 컨트롤 플레인과 etcd 맴버를 분리한다. 이는 그러므로 컨트롤 플레인 인스턴스나 etcd 맴버를 잃는 충격이 덜하고, 클러스터 중복성에 있어 중첩된 HA 토플로지만큼 영향을 미치지 않는다.

그러나, 이 토플로지는 중첩된 토플로지에 비해 호스트 개수가 두배나 필요하다. 이 토플로지로 HA 클러스터를 구성하기 위해서는 최소한 3개의 컨트롤 플레인과 3개의 etcd 노드가 필요하다.

다음 내용

• kubeadm을 이용하여 고가용성 클러스터 구성하기

2.2.2.2 - Kops로 쿠버네티스 설치하기

이곳 빠른 시작에서는 사용자가 얼마나 쉽게 AWS에 쿠버네티스 클러스터를 설치할 수 있는지 보여준다. kops라는 이름의 툴을 이용할 것이다.

kops는 자동화된 프로비저닝 시스템인데,

• 완전 자동화된 설치
• DNS를 통해 클러스터들의 신원 확인
• 자체 복구: 모든 자원이 Auto-Scaling Groups에서 실행
• 다양한 OS 지원(Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - images.md 보기
• 고가용성 지원 - high_availability.md 보기
• 직접 프로비저닝 하거나 또는 할 수 있도록 terraform 매니페스트를 생성 - terraform.md 보기

시작하기 전에

• kubectl을 반드시 설치해야 한다.

• 반드시 64-bit (AMD64 그리고 Intel 64)디바이스 아키텍쳐 위에서 kops 를 설치 한다.

• AWS 계정이 있고 IAM 키를 생성하고 구성해야 한다. IAM 사용자는 적절한 권한이 필요하다.

클러스터 구축

(1/5) kops 설치

설치

releases page에서 kops를 다운로드한다(소스 코드로부터 빌드하는 것도 역시 편리하다).

• macOS
• 리눅스

curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest
| grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64

$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)

curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64

chmod +x kops-darwin-amd64

sudo mv kops-darwin-amd64 /usr/local/bin/kops

brew update && brew install kops

curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64

$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)

curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64

chmod +x kops-linux-amd64

sudo mv kops-linux-amd64 /usr/local/bin/kops

brew update && brew install kops

(2/5) 클러스터에 사용할 route53 domain 생성

kops는 클러스터 내부와 외부 모두에서 검색을 위해 DNS을 사용하기에 클라이언트에서 쿠버네티스 API 서버에 연결할 수 있다.

이런 클러스터 이름에 kops는 명확한 견해을 가지는데: 반드시 유효한 DNS 이름이어야 한다. 이렇게 함으로써 사용자는 클러스터를 헷갈리지 않을것이고, 동료들과 혼선없이 공유할 수 있으며, IP를 기억할 필요없이 접근할 수 있다.

그렇게 하고 있겠지만, 클러스터를 구분하기 위해 서브도메인을 활용할 수 있다. 예를 들어 useast1.dev.example.com을 이용한다면, API 서버 엔드포인트는 api.useast1.dev.example.com가 될 것이다.

Route53 hosted zone은 서브도메인도 지원한다. 여러분의 hosted zone은 useast1.dev.example.com, dev.example.com 그리고 example.com 같은 것도 될 수 있다. kops는 이것들 모두와 잘 동작하며, 사용자는 보통 조직적인 부분을 고려해 결정한다(예를 들어, 사용자가 dev.example.com하위에 레코드를 생성하는것은 허용되지만, example.com하위에는 그렇지 않을 수 있다).

dev.example.com을 hosted zone으로 사용하고 있다고 가정해보자. 보통 사용자는 일반적인 방법 에 따라 생성하거나 aws route53 create-hosted-zone --name dev.example.com --caller-reference 1 와 같은 커맨드를 이용한다.

그 후 도메인 내 레코드들을 확인할 수 있도록 상위 도메인내에 NS 레코드를 생성해야 한다. 여기서는, dev NS 레코드를 example.com에 생성한다. 만약 이것이 루트 도메인 네임이라면 이 NS 레코드들은 도메인 등록기관을 통해서 생성해야 한다(예를 들어, example.com는 example.com를 구매한 곳에서 설정 할 수 있다).

route53 도메인 설정을 확인한다(문제를 만드는 가장 큰 이유이다!). dig 툴을 실행해서 클러스터 설정이 정확한지 한번 더 확인한다.

dig NS dev.example.com

당신의 hosted zone용으로 할당된 3~4개의 NS 레코드를 Route53에서 확인할 수 있어야 한다.

(3/5) 클러스터 상태 저장용 S3 버킷 생성

kops는 설치 이후에도 클러스터를 관리할 수 있다. 이를 위해 사용자가 생성한 클러스터의 상태나 사용하는 키 정보들을 지속적으로 추적해야 한다. 이 정보가 S3에 저장된다. 이 버킷의 접근은 S3 권한으로 제어한다.

다수의 클러스터는 동일한 S3 버킷을 이용할 수 있고, 사용자는 이 S3 버킷을 같은 클러스트를 운영하는 동료에게 공유할 수 있다. 하지만 이 S3 버킷에 접근 가능한 사람은 사용자의 모든 클러스터에 관리자 접근이 가능하게 되니, 운영팀 이외로 공유되지 않도록 해야 한다.

그래서 보통 한 운영팀 당 하나의 S3 버킷을 가지도록 하기도 한다.(그리고 종종 운영팀 이름은 위에서 언급한 hosted zone과 동일하게 짓기도 한다!)

우리 예제에서는, dev.example.com를 hosted zone으로 했으니 clusters.dev.example.com를 S3 버킷 이름으로 정하자.

• AWS_PROFILE를 선언한다. (AWS CLI 동작을 위해 다른 profile을 선택해야 할 경우)

• aws s3 mb s3://clusters.dev.example.com를 이용해 S3 버킷을 생성한다.

• export KOPS_STATE_STORE=s3://clusters.dev.example.com 하면, kops는 이 위치를 기본값으로 인식할 것이다. 이 부분을 bash profile등에 넣어두는것을 권장한다.

(4/5) 클러스터 설정 구성

클러스터 설정하려면, kops create cluster 를 실행한다:

kops create cluster --zones=us-east-1c useast1.dev.example.com

kops는 클러스터에 사용될 설정을 생성할것이다. 여기서 주의할 점은 실제 클러스트 리소스가 아닌 설정 만을 생성한다는 것에 주의하자 - 이 부분은 다음 단계에서 kops update cluster 으로 구성해볼 것이다. 그 때 만들어진 설정을 점검하거나 변경할 수 있다.

더 자세한 내용을 알아보기 위한 커맨드가 출력된다.

• 클러스터 조회: kops get cluster
• 클러스트 수정: kops edit cluster useast1.dev.example.com
• 인스턴스 그룹 수정: kops edit ig --name=useast1.dev.example.com nodes
• 마스터 인스턴스 그룹 수정: kops edit ig --name=useast1.dev.example.com master-us-east-1c

만약 kops사용이 처음이라면, 얼마 걸리지 않으니 이들을 시험해 본다. 인스턴스 그룹은 쿠버네티스 노드로 등록된 인스턴스의 집합을 말한다. AWS상에서는 auto-scaling-groups를 통해 만들어진다. 사용자는 여러 개의 인스턴스 그룹을 관리할 수 있는데, 예를 들어, spot과 on-demand 인스턴스 조합 또는 GPU 와 non-GPU 인스턴스의 조합으로 구성할 수 있다.

(5/5) AWS에 클러스터 생성

kops update cluster를 실행해 AWS에 클러스터를 생성한다.

kops update cluster useast1.dev.example.com --yes

실행은 수 초 만에 되지만, 실제로 클러스터가 준비되기 전까지 수 분이 걸릴 수 있다. 언제든 kops update cluster로 클러스터 설정을 변경할 수 있다. 사용자가 변경한 클러스터 설정을 그대로 반영해 줄 것이며, 필요다하면 AWS 나 쿠버네티스를 재설정 해 줄것이다.

예를 들면, kops edit ig nodes 뒤에 kops update cluster --yes를 실행해 설정을 반영한다. 그리고 kops rolling-update cluster로 설정을 즉시 원복시킬 수 있다.

--yes를 명시하지 않으면 kops update cluster 커맨드 후 어떤 설정이 변경될지가 표시된다. 운영계 클러스터 관리할 때 사용하기 좋다!

다른 애드온 탐험

애드온 리스트 에서 쿠버네티스 클러스터용 로깅, 모니터링, 네트워크 정책, 시각화 & 제어 등을 포함한 다른 애드온을 확인해본다.

정리하기

• kops delete cluster useast1.dev.example.com --yes 로 클러스터를 삭제한다.

다음 내용

• 쿠버네티스 개념 과 kubectl에 대해 더 알아보기.
• 튜토리얼, 모범사례 및 고급 구성 옵션에 대한 kops 고급 사용법에 대해 더 자세히 알아본다.
• 슬랙(Slack)에서 kops 커뮤니티 토론을 할 수 있다: 커뮤니티 토론
• 문제를 해결하거나 이슈를 제기하여 kops 에 기여한다. 깃헙 이슈

2.2.2.3 - Kubespray로 쿠버네티스 설치하기

이 가이드는 Kubespray를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.

Kubespray는 Ansible 플레이북, 인벤토리, 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.

• 고가용성을 지닌 클러스터
• 구성할 수 있는 속성들
• 대부분의 인기있는 리눅스 배포판들에 대한 지원
  • Ubuntu 16.04, 18.04, 20.04
  • CentOS/RHEL/Oracle Linux 7, 8
  • Debian Buster, Jessie, Stretch, Wheezy
  • Fedora 31, 32
  • Fedora CoreOS
  • openSUSE Leap 15
  • Flatcar Container Linux by Kinvolk
• 지속적인 통합 (CI) 테스트

클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 kubeadm, kops와 비교한 글을 읽어보자.

클러스터 생성하기

(1/5) 아래의 요건 충족하기

언더레이(underlay) 요건을 만족하는 프로비전 한다.

• Ansible의 명령어를 실행하기 위해 Ansible v 2.9와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다
• Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다
• 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 (오프라인 환경 확인하기)
• 타겟 서버들의 IPv4 포워딩이 활성화되어야 한다
• SSH 키가 인벤토리의 모든 서버들에 복사되어야 한다
• 방화벽은 관리되지 않는다. 사용자가 예전 방식대로 고유한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
• 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 한다. 그 뒤 ansible_become 플래그나 커맨드 파라미터들, --become 또는 -b 가 명시되어야 한다

Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:

• 아래 클라우드 제공 업체를 위한 Terraform 스크립트:
  • AWS
  • OpenStack
  • Packet

(2/5) 인벤토리 파일 구성하기

서버들을 프로비저닝 한 후, Ansible의 인벤토리 파일을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " 나만의 인벤토리 만들기" 글을 확인하자.

(3/5) 클러스터 디플로이먼트 계획하기

Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의(customize)할 수 있다:

• 디플로이먼트 모드의 선택: kubeadm 또는 그 외
• CNI(네트워킹) 플러그인
• DNS 설정
• 컨트롤 플레인 선택: 네이티브/바이너리 또는 컨테이너화 된 것
• 컴포넌트 버전
• Calico 라우터 리플렉터
• 컴포넌트 런타임 옵션
  • 도커(Docker)
  • containerd
  • CRI-O
• 인증서 생성 방법

Kubespray의 변수 파일들을 사용자가 정의할 수 있다. 만약 Kubespray를 처음 접하는 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다.

(4/5) 클러스터 배포하기

다음으로, 클러스터를 배포한다.

Ansible-플레이북을 이용한 클러스터 디플로이먼트

ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
  --private-key=~/.ssh/private_key

규모가 큰 디플로이먼트는 (100개 이상의 노드) 최적의 결과를 얻기 위해 특정한 조정을 필요로 할 수도 있다.

(5/5) 디플로이먼트 검증하기

Kubespray는 Netchecker를 사용하여 파드 사이의 연결성과 DNS 해석을 검증할 방법을 제공한다. Netchecker는 netchecker-agents 파드들이 DNS 요청을 해석하고 기본(default) 네임스페이스 내부에서 서로에게 ping을 보낼 수 있도록 보장한다. 그 파드들은 나머지 워크로드의 유사한 동작을 모방하고 클러스터의 상태 표시기 역할을 한다.

클러스터 동작

Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, scale 과 upgrade 를 제공한다.

클러스터 스케일링하기

scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "노드 추가하기" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "노드 제거하기" 문서를 확인하자.

클러스터 업그레이드 하기

upgrade-cluster 플레이북을 실행해 클러스터를 업그레이드 할 수 있다. 더 자세히 알고 싶다면 "업그레이드" 문서를 확인하자.

클린업

reset 플레이북을 이용하여 노드들을 리셋하고 Kubespray로 설치된 모든 구성요소를 삭제할 수 있다.

피드백

• Slack 채널: #kubespray (이 곳에서 초대를 받을 수 있다)
• GitHub Issues

다음 내용

Kubespray의 로드맵에서 계획중인 작업을 확인해보자.

2.2.3 - 턴키 클라우드 솔루션

이 페이지는 인증된 쿠버네티스 솔루션 제공자 목록을 제공한다. 각 제공자 페이지를 통해서, 프로덕션에 준비된 클러스터를 설치 및 설정하는 방법을 학습할 수 있다.

2.2.4 - 쿠버네티스에서 윈도우

2.2.4.1 - 쿠버네티스에서 윈도우 컨테이너

윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. 윈도우 컨테이너는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다.

쿠버네티스의 윈도우 컨테이너

쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 파드에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다.

윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 쿠버네티스 노드를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, 컨테이너 런타임 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 Microsoft 문서를 참고한다.

마스터 컴포넌트를 포함한 쿠버네티스 컨트롤 플레인은 리눅스에서 계속 실행된다. 윈도우 전용 쿠버네티스 클러스터는 계획이 없다.

이 문서에서 윈도우 컨테이너에 대해 이야기할 때 프로세스 격리된 윈도우 컨테이너를 의미한다. Hyper-V 격리가 있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다.

지원되는 기능 및 제한

지원되는 기능

윈도우 OS 버전 지원

쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다.

지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 윈도우 서버 서비스 채널에서 확인할 수 있다.

모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 버전-차이(skew) 정책(노드 대 컨트롤 플레인 버전 관리)을 준수한다.

윈도우 서버 호스트 운영 체제에는 윈도우 서버 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 윈도우 컨테이너에 대한 추가 사용 조건이 적용된다.

프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, 여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다. 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다.

퍼즈(Pause) 이미지

쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다. 쿠버네티스 v1.22의 경우 권장 퍼즈 이미지는 k8s.gcr.io/pause:3.5이다. 소스 코드는 GitHub에서 찾을 수 있다.

Microsoft는 리눅스, 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 mcr.microsoft.com/oss/kubernetes/pause:3.5에서 유지보수하고 있다. 이 이미지는 쿠버네티스가 유지 관리하는 이미지와 동일한 소스코드에서 생성되었지만, 모든 윈도우 바이너리는 Microsoft에 의해 서명된 인증 코드이다. 프로덕션 환경에서 서명된 바이너리가 필요한 경우, Microsoft가 유지 관리하는 이미지를 사용하는 것을 권장한다.

컴퓨트

API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 제한 섹션에 요약된 주요 기능에는 몇 가지 눈에 띄는 차이점이 있다.

윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다.

• 파드

  파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다.

  • 프로세스 분리 및 볼륨 공유 기능을 갖춘 파드 당 하나 또는 여러 개의 컨테이너
  • 파드 상태 필드
  • 준비성(readiness) 및 활성 프로브(liveness probe)
  • postStart 및 preStop 컨테이너 라이프사이클 이벤트
  • 컨피그맵(ConfigMap), 시크릿(Secrets): 환경 변수 또는 볼륨으로
  • EmptyDir
  • 명명된 파이프 호스트 마운트
  • 리소스 제한

• 컨트롤러

  쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다.

  • 레플리카셋(ReplicaSet)
  • 레플리케이션컨트롤러(ReplicationController)
  • 디플로이먼트(Deployment)
  • 스테이트풀셋(StatefulSet)
  • 데몬셋(DaemonSet)
  • 잡(Job)
  • 크론잡(CronJob)

• 서비스

  쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 다음의 유형, 속성 및 기능을 활용할 수 있다.

  • 서비스 환경 변수
  • 노드포트(NodePort)
  • 클러스터IP(ClusterIP)
  • 로드밸런서(LoadBalancer)
  • ExternalName
  • 헤드리스 서비스(Headless services)

파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 충분하지 않다. 다음 기능에 대한 지원이 추가되었다.

• 파드와 컨테이너 메트릭
• Horizontal Pod Autoscaler 지원
• kubectl Exec
• 리소스쿼터(Resource Quotas)
• 스케쥴러 선점(preemption)

컨테이너 런타임

Docker EE

Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다.

CRI-ContainerD

ContainerD 1.4.0+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다.

윈도우에 ContainerD 설치 방법을 확인한다.

퍼시스턴트 스토리지(Persistent Storage)

쿠버네티스 볼륨을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 플러그인의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다.

인-트리(In-tree) 볼륨 플러그인

인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다.

• awsElasticBlockStore
• azureDisk
• azureFile
• gcePersistentDisk
• vsphereVolume

FlexVolume 플러그인

FlexVolume 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume 플러그인은 윈도우 노드를 지원한다.

• SMB
• iSCSI

CSI 플러그인

CSI 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다.

CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 다양한 특권이 필요한(privileged) 작업을 수행해야 한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, 각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 csi-proxy를 사용하여 지원된다. 자세한 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다.

윈도우 노드에서 CSI 노드 플러그인은 일반적으로 로컬 스토리지 작업을 처리하는 커뮤니티에서 관리하는 csi-proxy에 의해 노출된 API를 호출한다.

설치에 대한 자세한 내용은 윈도우 CSI 플러그인을 배포할 환경의 배포 가이드를 참고한다. 또한 다음 설치 단계를 참고할 수도 있다.

네트워킹

윈도우 컨테이너용 네트워킹은 CNI 플러그인을 통해 노출된다. 윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다.

• 가상 네트워크(vSwitch 생성 포함)
• 엔드포인트 / vNIC
• 네임스페이스
• 정책(패킷 캡슐화, 로드 밸런싱 규칙, ACL, NAT 규칙 등)

다음의 서비스 사양 유형이 지원된다.

• NodePort
• ClusterIP
• LoadBalancer
• ExternalName

네트워크 모드

윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다.

위에서 설명한대로 플란넬(Flannel) CNI 메타 플러그인은 VXLAN 네트워크 백엔드 (alpha 지원, win-overlay에 위임) 및 host-gateway network backend (안정적인 지원, win-bridge에 위임)를 통해 윈도우에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다.

노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다.

• 파드 -> 파드(IP)
• 파드 -> 파드(Name)
• 파드 -> 서비스(Cluster IP)
• 파드 -> 서비스(PQDN, 단 "."이 없는 경우에만)
• 파드 -> 서비스(FQDN)
• 파드 -> External(IP)
• 파드 -> External(DNS)
• 노드 -> 파드
• 파드 -> 노드

IP 주소 관리(IPAM)

윈도우에서는 다음 IPAM 옵션이 지원된다.

• 호스트-로컬
• HNS IPAM(Inbox 플랫폼 IPAM, 이것은 IPAM이 설정되지 않은 경우 폴백(fallback)이다)
• Azure-vnet-ipam(azure-cni 전용)

로드 밸런싱과 서비스

윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 구성할 수 있다.

IPv4/IPv6 이중 스택

IPv6DualStack 기능 게이트를 사용하여 l2bridge 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 IPv4/IPv6 이중 스택 활성화를 참조한다.

윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다.

윈도우의 오버레이(VXLAN) 네트워크는 현재 이중 스택 네트워킹을 지원하지 않는다.

제한

윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다.

자원 관리

리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다.

자원 예약

메모리 예약

윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족(out of memory, OOM) 종료를 겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다.

kubelet 파라미터 --kubelet-reserve 를 사용하여 메모리 사용량을 합리적인 범위 내로 유지할 수 있으며, --system-reserve 를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 노드 할당(NodeAllocatable)은 줄어든다.

워크로드를 배포할 때, 컨테이너에 리소스 제한을 걸어라(제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable에서 차감되며, 메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다.

오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 kubelet을 설정하는 것이다.

CPU 예약

윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU 사용량을 모니터링하여 워크로드 요구사항을 충족하는 값을 선택해야 한다.

kubelet 파라미터 --kubelet-reserve 를 사용하여 CPU 사용량을 합리적인 범위 내로 유지할 수 있으며, --system-reserve 를 사용하여 노드 (컨테이너 외부) 의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 노드 할당(NodeAllocatable)은 줄어든다.

기능 제한

• TerminationGracePeriod: 구현되지 않음
• 단일 파일 매핑: CRI-ContainerD로 구현 예정
• 종료 메시지: CRI-ContainerD로 구현 예정
• 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음
• HugePages: 현재 윈도우 컨테이너에서 지원되지 않음
• 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다.
• 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조).

각 플래그의 리눅스와의 차이점

윈도우 노드에서의 kubelet 플래그의 동작은 아래에 설명된 대로 다르게 동작한다.

• --kubelet-reserve, --system-reserve, --eviction-hard 플래그는 Node Allocatable 업데이트

• --enforce-node-allocable을 사용한 축출(Eviction)은 구현되지 않았다.

• --eviction-hard와 --eviction-soft를 사용한 축출은 구현되지 않았다.

• MemoryPressure 조건은 구현되지 않았다.

• kubelet이 취한 OOM 축출 조치가 없다.

• 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. --kubelet-reserve와 --system-reserve는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다.

• kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 --windows-priorityclass라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 윈도우 우선순위 클래스에서 확인할 수 있다. kubelet이 항상 충분한 CPU주기를 갖도록 하려면 이 플래그를 ABOVE_NORMAL_PRIORITY_CLASS 이상으로 설정하는 것이 좋다.

스토리지

윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다.

• 도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉터리만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다.

• 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다.

• 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다.

• 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다.

결과적으로, 다음 스토리지 기능은 윈도우 노드에서 지원되지 않는다.

• 볼륨 하위 경로(subpath) 마운트. 전체 볼륨만 윈도우 컨테이너에 마운트할 수 있다.
• 시크릿에 대한 하위 경로 볼륨 마운트
• 호스트 마운트 프로젝션
• DefaultMode(UID/GID 종속성에 기인함)
• 읽기 전용 루트 파일시스템. 매핑된 볼륨은 여전히 ​​읽기 전용을 지원한다.
• 블록 디바이스 매핑
• 저장 매체로서의 메모리
• uui/guid, 사용자별 리눅스 파일시스템 권한과 같은 파일시스템 기능
• NFS 기반 스토리지/볼륨 지원
• 마운트된 볼륨 확장(resizefs)

네트워킹

윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. 윈도우 컨테이너 네트워킹에 대한 Microsoft 문서에는 추가 세부 정보와 배경이 포함되어 있다.

윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다.

다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다.

• 윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다.

• 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서는 가능)

• 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다.

• 한 서비스는 최대 64개의 백엔드 파드 또는 고유한 목적지 IP를 지원할 수 있다.

• kube-proxy의 오버레이 네트워킹 지원은 베타 기능이다. 또한 윈도우 서버 2019에 KB4482887을 설치해야 한다.

• 비-DSR 모드의 로컬 트래픽 정책

• 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다.

• win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인 (VFP)은 ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다.

  • 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 ICMP 패킷은 예상대로 제한 없이 작동한다.

  • TCP/UDP 패킷은 예상대로 제한 없이 작동한다.

  • 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 소스로 다시 라우팅되지 않는다.

  • TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에 ping <destination>을 curl <destination>으로 대체하여 외부와의 연결을 디버깅할 수 있다.

해당 기능은 쿠버네티스 v1.15에 추가되었다.

• kubectl port-forward

CNI 플러그인

• 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 현재 "CHECK" 구현 누락으로 인해 CNI 사양 v0.4.0을 구현하지 않는다.

• Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다.

  1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 있는 로컬 파드에서만 가능하다.

  2. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 Flannel VXLAN 백엔드 문서를 참고한다.

DNS

• ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다.

• 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 연결된 DNS 접미사인 DNS 접미사 1개만 있다. 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS 접미사 default.svc.cluster.local이 있다. 윈도우 파드에서는 kubernetes.default.svc.cluster.local 및 kubernetes를 모두 확인할 수 있지만 kubernetes.default 또는 kubernetes.default.svc와 같은 중간 항목은 확인할 수 없다.

• 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 Resolve-DNSName 유틸리티를 사용하는 것이 좋다.

IPv6

윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 IPv4/IPv6 이중 스택 네트워킹을 참고한다.

세션 어피니티(affinity)

service.spec.sessionAffinityConfig.clientIP.timeoutSeconds를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다.

보안

시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다.

1. 파일 ACL을 사용하여 시크릿 파일 위치를 보호한다.
2. BitLocker를 사용한 볼륨-레벨 암호화를 사용한다.

RunAsUsername은 컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 컨테이너에 지정할 수 있다. 이것은 RunAsUser와 거의 동일하다.

SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다.

또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 않는다.

API

대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. 중요한 차이점은 OS와 컨테이너 런타임의 차이로 귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 설계되었다.

높은 수준에서 이러한 OS 개념은 다르다.

• ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 /etc/groups 또는 /etc/passwd의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다.

• 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다.

• 파일 경로 - 윈도우의 규칙은 / 대신 \를 사용하는 것이다. Go IO 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 \가 필요할 수 있다.

• 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다.

  • UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다.

  • 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다.

  • 서비스는 SERVICE_CONTROL_STOP 제어 코드를 수용할 수 있는 Service Control Handler 함수를 등록한다.

종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. 특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다.

V1.Container

• V1.Container.ResourceRequirements.limits.cpu 및 V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 스케일된다. 참고: kuberuntime/helpers_windows.go, 참고: Microsoft 문서 내 리소스 제어

  • Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 사용자 권한(privilege) 어설트가 필요하다.

• V1.Container.ResourceRequirements.requests.cpu 및 V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 모범 사례로 모든 컨테이너에 적용해야 한다.

• V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 불가능하며, 어떤 기능도 연결되지 않는다.

• V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 구현되지 않는다.

• V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 지원하지 않는다.

• V1.Container.SecurityContext.procMount - 윈도우에는 /proc 파일시스템이 없다.

• V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 필요하다.

• V1.Container.SecurityContext.runAsGroup - 윈도우에서는 불가능하며, GID 지원이 없다.

• V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 ContainerAdministrator이다.

• V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID 지원이 없다.

• V1.Container.SecurityContext.seLinuxOptions - 윈도우에서는 불가능하며, SELinux가 없다.

• V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 작동한다.

V1.Pod

• V1.Pod.hostIPC, v1.pod.hostpid - 윈도우에서 호스트 네임스페이스 공유가 불가능하다.

• V1.Pod.hostNetwork - 호스트 네트워크를 공유하기 위한 윈도우 OS 지원이 없다.

• V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 지원되지 않는다.

• V1.Pod.podSecurityContext - 아래 V1.PodSecurityContext 내용을 참고한다.

• V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다.

• V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 완전히 구현되지 않았다. 참조의 내용을 참고한다. 현재 동작은 ENTRYPOINT 프로세스가 CTRL_SHUTDOWN_EVENT로 전송된 다음, 윈도우가 기본적으로 5초를 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다. 5초 기본값은 실제로 컨테이너 내부 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다.

• V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다.

• V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 TestGrid에 테스트가 있다.

  • V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다.

• V1.VolumeMount.mountPropagation - 마운트 전파(propagation)는 윈도우에서 지원되지 않는다.

V1.PodSecurityContext

PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 나열한다.

• V1.PodSecurityContext.SELinuxOptions - SELinux는 윈도우에서 사용할 수 없다.

• V1.PodSecurityContext.RunAsUser - 윈도우에서는 사용할 수 없는 UID를 제공한다.

• V1.PodSecurityContext.RunAsGroup - 윈도우에서는 사용할 수 없는 GID를 제공한다.

• V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티인 ContainerAdministrator이다.

• V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다.

• V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다.

운영 체제 버전 제한

윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다.

도움 받기 및 트러블슈팅

쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 섹션에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows 로그 수집에 대한 기여 가이드의 지침을 따른다.

• start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가?

  kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 한다.

• 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가?

  Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 자동으로 다시 시작하여 복원력(resiliency)을 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 두 가지 옵션이 있다.

  • 네이티브 윈도우 서비스

    Kubelet와 kube-proxy는 sc.exe를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다.

    # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성
    sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>"
    
    # 인자에 공백이 포함된 경우 이스케이프 되어야 한다.
    sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>"
    
    # 서비스 시작
    Start-Service kubelet
    Start-Service kube-proxy
    
    # 서비스 중지
    Stop-Service kubelet (-Force)
    Stop-Service kube-proxy (-Force)
    
    # 서비스 상태 질의
    Get-Service kubelet
    Get-Service kube-proxy
    

  • nssm.exe 사용

    또한 언제든지 nssm.exe와 같은 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, kube-proxy)를 실행할 수 있다. 이 샘플 스크립트를 사용하여 백그라운드에서 윈도우 서비스로 실행하기 위해 nssm.exe를 활용하여 kubelet, kube-proxy, flanneld.exe를 등록할 수 있다.

    register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP <Kube-dns 서비스 IP> -LogDir <로그 위치 디렉터리>
    

    파라미터 설명은 아래와 같다.

    • NetworkMode: 네트워크 모드 l2bridge(flannel host-gw, 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan)
    • ManagementIP: 윈도우 노드에 할당된 IP 주소. ipconfig를 사용하여 찾을 수 있다.
    • ClusterCIDR: 클러스터 서브넷 범위. (기본값 10.244.0.0/16)
    • KubeDnsServiceIP: 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10)
    • LogDir: kubelet 및 kube-proxy 로그가 각각의 출력 파일로 리다이렉션되는 디렉터리(기본값 C:\k)

    위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 nssm.exe를 수동으로 구성할 수 있다.

    flanneld.exe를 등록한다.

    nssm install flanneld C:\flannel\flanneld.exe
    nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface=<ManagementIP> --ip-masq=1 --kube-subnet-mgr=1
    nssm set flanneld AppEnvironmentExtra NODE_NAME=<hostname>
    nssm set flanneld AppDirectory C:\flannel
    nssm start flanneld
    

    kubelet.exe를 등록한다.

    nssm install kubelet C:\k\kubelet.exe
    nssm set kubelet AppParameters --hostname-override=<hostname> --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns=<DNS-service-IP> --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false  --log-dir=<log directory> --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
    nssm set kubelet AppDirectory C:\k
    nssm start kubelet
    

    kube-proxy.exe를 등록한다(l2bridge / host-gw).

    nssm install kube-proxy C:\k\kube-proxy.exe
    nssm set kube-proxy AppDirectory c:\k
    nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=<hostname>--kubeconfig=c:\k\config --enable-dsr=false --log-dir=<log directory> --logtostderr=false
    nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
    nssm set kube-proxy DependOnService kubelet
    nssm start kube-proxy
    

    kube-proxy.exe를 등록한다(overlay / vxlan).

    nssm install kube-proxy C:\k\kube-proxy.exe
    nssm set kube-proxy AppDirectory c:\k
    nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override=<hostname> --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip=<source-vip> --enable-dsr=false --log-dir=<log directory> --logtostderr=false
    nssm set kube-proxy DependOnService kubelet
    nssm start kube-proxy
    

    초기 트러블슈팅을 위해 nssm.exe에서 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다.

    nssm set <Service Name> AppStdout C:\k\mysvc.log
    nssm set <Service Name> AppStderr C:\k\mysvc.log
    

    자세한 내용은 공식 nssm 사용 문서를 참고한다.

• 내 윈도우 파드에 네트워크 연결이 없다.

  가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 활성화되어 있는지 확인한다.

• 내 윈도우 파드가 외부 리소스를 ping 할 수 없다.

  윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, ping <IP>를 해당 curl <IP>명령으로 대체한다.

  여전히 문제가 발생하는 경우, cni.conf의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다.

  쿠버네티스 네트워킹 요구 사항 중 하나(쿠버네티스 모델)는 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 ExceptionList가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 cni.conf의 ExceptionList는 다음과 같아야 한다.

  "ExceptionList": [
      "10.244.0.0/16",  # 클러스터 서브넷
      "10.96.0.0/12",   # 서비스 서브넷
      "10.127.130.0/24" # 관리(호스트) 서브넷
  ]
  

• 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다.

  노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다.

• 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다.

  이 문제는 hostname-override 파라미터가 kube-proxy에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다.

  C:\k\kube-proxy.exe --hostname-override=$(hostname)
  

• 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다.

  이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다.

  Remove-Item C:\k\SourceVip.json
  Remove-Item C:\k\SourceVipRequest.json
  

• start.ps1을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다.

  이 이슈에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다.

  PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
  PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1
  

• /run/flannel/subnet.env 누락으로 인해 윈도우 파드를 시작할 수 없다.

  이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 /run/flannel/subnet.env에서 윈도우 워커 노드의 C:\run\flannel\subnet.env로 파일을 수동으로 복사할 수 있고, FLANNEL_SUBNET 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다.

  FLANNEL_NETWORK=10.244.0.0/16
  FLANNEL_SUBNET=10.244.4.1/24
  FLANNEL_MTU=1500
  FLANNEL_IPMASQ=true
  

• 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다.

  이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다.

• kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다.

  윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다.

  Get-HnsNetwork | ? Name -ieq "cbr0"
  Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
  

  호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 InterfaceName 파라미터를 수정하는 것이 좋다. 그렇지 않으면 start-kubelet.ps1 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다.

• 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.

  퍼즈 이미지가 OS 버전과 호환되는지 확인한다. 지침에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 도커 리포지터리를 참조한다. 그럼에도 불구하고, 퍼즈 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다.

• DNS 확인(resolution)이 제대로 작동하지 않는다.

  윈도우에 대한 DNS 제한을 확인한다.

• kubectl port-forward가 "unable to do port forwarding: wincat not found"로 실패한다.

  이는 쿠버네티스 1.15 및 퍼즈 인프라 컨테이너 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다. 자체 퍼즈 인프라 컨테이너를 빌드하려면 wincat을 포함해야 한다.

  윈도우에서 포트 포워딩을 지원하려면 퍼즈 인프라 컨테이너를 이용하기 위해서 wincat.exe가 필요하다. 윈도우 OS 버전과 호환되는 지원되는 이미지를 사용하고 있는지 확인해야 한다. 자신만의 퍼즈 인프라 컨테이너를 구축하려면 wincat을 포함해야 한다.

• 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다.

  프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 정의해야 한다.

  [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
  [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
  

• 퍼즈(pause) 컨테이너란 무엇인가?

  쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "퍼즈" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 퍼즈 컨테이너가 필요하다.

  퍼즈 이미지 추천 버전을 찾기 위해서는 퍼즈 이미지를 참고한다.

추가 조사

이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는데 도움을 받을 수 있다.

• 스택오버플로우 윈도우 서버 컨테이너 주제

• 쿠버네티스 공식 포럼 discuss.kubernetes.io

• 쿠버네티스 슬랙 #SIG-Windows Channel

이슈 리포팅 및 기능 요청

버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면, GitHub 이슈 트래킹 시스템을 활용한다. GitHub에서 이슈를 열고 SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 이슈에 대한 경험을 언급하고 추가 로그를 첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다.

버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 포함한다.

• 쿠버네티스 버전: kubectl version
• 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 구성, 도커 버전
• 문제를 재현하기 위한 세부 단계
• 관련 로그
• SIG-Windows 회원의 주의를 끌 수 있도록 /sig windows로 이슈에 대해 어노테이션을 달아 이슈에 sig/windows 태그를 지정한다.

다음 내용

로드맵에는 많은 기능이 있다. 요약된 높은 수준의 목록이 아래에 포함되어 있지만, 로드맵 프로젝트를 보고 기여하여 윈도우 지원을 개선하는데 도움이 주는 것이 좋다.

Hyper-V 격리(isolation)

쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 Hyper-V 격리가 필요하다.

• 추가 보안을 위해 파드 간 하이퍼바이저 기반 격리

• 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 최신 윈도우 서버 버전을 실행할 수 있다.

• 파드에 대한 특정 CPU/NUMA 설정

• 메모리 격리 및 예약

Hyper-V 격리 지원은 이후 릴리스에 추가되며 CRI-Containerd가 필요하다.

kubeadm 및 클러스터 API를 사용한 배포

Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이 되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만 여기에서 가이드를 사용할 수 있다. 또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에 투자하고 있다.

2.2.4.2 - 쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드

많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. 이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다.

목표

• 윈도우 노드에서 윈도우 컨테이너를 실행하는 예시 디플로이먼트를 구성한다.
• (선택) 그룹 매니지드 서비스 어카운트(GMSA)를 이용한 사용자 파드를 위한 액티브 디렉터리 신원(Active Directory Identity)을 구성한다.

시작하기 전에

• 컨트롤 플레인과 윈도우 서버로 운영되는 워커 노드를 포함하는 쿠버네티스 클러스터를 생성한다.
• 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. Kubectl 커맨드로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다.

시작하기: 윈도우 컨테이너 배포하기

쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. 아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. 아래 내용으로 채운 서비스 스펙을 win-webserver.yaml로 생성하자.

apiVersion: v1
kind: Service
metadata:
  name: win-webserver
  labels:
    app: win-webserver
spec:
  ports:
    # 이 서비스에서 제공하는 포트
    - port: 80
      targetPort: 80
  selector:
    app: win-webserver
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver
  name: win-webserver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: win-webserver
  template:
    metadata:
      labels:
        app: win-webserver
      name: win-webserver
    spec:
     containers:
      - name: windowswebserver
        image: mcr.microsoft.com/windows/servercore:ltsc2019
        command:
        - powershell.exe
        - -command
        - "<#code used from https://gist.github.com/19WAS85/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ;  ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='<html><body><H1>Windows Container Web Server</H1>' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='<p>IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='</body></html>' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus)  } ; "
     nodeSelector:
      kubernetes.io/os: windows

1. 모든 노드가 건강한지 확인한다.

   kubectl get nodes
   

2. 서비스를 배포하고 파드 갱신을 지켜보자.

   kubectl apply -f win-webserver.yaml
   kubectl get pods -o wide -w
   

   이 서비스가 정확히 배포되면 모든 파드는 Ready로 표기된다. 지켜보기를 중단하려면, Ctrl+C 를 누르자.

3. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.

   • 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, docker ps를 사용한다.
   • 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, kubectl get pods를 사용한다.
   • 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 curl을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
   • 파드 간 통신이 되는지 확인하려면, docker exec 나 kubectl exec를 이용해 파드 간에 핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
   • 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 curl을 가상 서비스 IP 주소(kubectl get services로 볼 수 있는)로 실행한다.
   • 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 기본 DNS 접미사와 서비스 이름으로 curl을 실행한다.
   • 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 curl을 실행한다.
   • 아웃바운드 연결이 되는지 확인하려면, kubectl exec를 이용해서 파드에서 외부 IP 주소로 curl을 실행한다.

가시성

워크로드에서 로그 캡쳐하기

로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 파악할 수 있도록 하며 문제 해결의 핵심 요소이다. 윈도우 컨테이너, 그리고 윈도우 컨테이너 내의 워크로드는 리눅스 컨테이너와는 다르게 동작하기 때문에, 사용자가 로그를 수집하기 어려웠고 이로 인해 운영 가시성이 제한되어 왔다. 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. Microsoft의 오픈 소스 도구인 LogMonitor는 윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 kubectl logs <pod> 에 의한 사용을 위해 STDOUT으로 파이프한다.

LogMonitor GitHub 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리포인트를 추가한다.

설정 가능한 컨테이너 username 사용하기

쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. 여기에서 이에 대해 추가적으로 배울 수 있다.

그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기

쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 여기에서 알아보자.

테인트(Taint)와 톨러레이션(Toleration)

오늘날 사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 할당되도록 하기 위해 테인트와 노드셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.

특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기

사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다.

• kubernetes.io/os = [windows|linux]
• kubernetes.io/arch = [amd64|arm64|...]

파드 사양에 노드 셀렉터를 "kubernetes.io/os": windows와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다.

그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다.

예를 들면, --register-with-taints='os=windows:NoSchedule'

모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면, 윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.

nodeSelector:
    kubernetes.io/os: windows
    node.kubernetes.io/windows-build: '10.0.17763'
tolerations:
    - key: "os"
      operator: "Equal"
      value: "windows"
      effect: "NoSchedule"

동일 클러스터에서 여러 윈도우 버전을 조작하는 방법

파드에서 사용하는 윈도우 서버 버전은 노드의 윈도우 서버 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우 서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야 한다.

쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 node.kubernetes.io/windows-build 를 자동으로 추가한다. 만약 이전 버전을 실행 중인 경우, 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다.

이 레이블은 호환성을 위해 일치시켜야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. 각 윈도우 서버 버전에 대해 현재 사용하고 있는 빌드 번호는 다음과 같다.

RuntimeClass로 단순화

런타임클래스(RuntimeClass)를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. 클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는 데 사용되는 RuntimeClass 오브젝트를 생성할 수 있다.

1. 이 파일을 runtimeClasses.yml 로 저장한다. 여기에는 윈도우 OS, 아키텍처 및 버전에 적합한 nodeSelector 가 포함되어 있다.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: windows-2019
handler: 'docker'
scheduling:
  nodeSelector:
    kubernetes.io/os: 'windows'
    kubernetes.io/arch: 'amd64'
    node.kubernetes.io/windows-build: '10.0.17763'
  tolerations:
  - effect: NoSchedule
    key: os
    operator: Equal
    value: "windows"

2. 클러스터 관리자로 kubectl create -f runtimeClasses.yml 를 실행해서 사용한다.
3. 파드 사양에 적합한 runtimeClassName: windows-2019 를 추가한다.

예시:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis-2019
  labels:
    app: iis-2019
spec:
  replicas: 1
  template:
    metadata:
      name: iis-2019
      labels:
        app: iis-2019
    spec:
      runtimeClassName: windows-2019
      containers:
      - name: iis
        image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        resources:
          limits:
            cpu: 1
            memory: 800Mi
          requests:
            cpu: .1
            memory: 300Mi
        ports:
          - containerPort: 80
 selector:
    matchLabels:
      app: iis-2019
---
apiVersion: v1
kind: Service
metadata:
  name: iis
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: iis-2019

2.3 - 모범 사례

2.3.1 - 대형 클러스터에 대한 고려 사항

클러스터는 컨트롤 플레인에서 관리하는 쿠버네티스 에이전트를 실행하는 노드(물리 또는 가상 머신)의 집합이다. 쿠버네티스 v1.23는 노드 5,000개까지의 클러스터를 지원한다. 보다 정확하게는, 쿠버네티스는 다음 기준을 모두 만족하는 설정을 수용하도록 설계되었다.

• 노드 당 파드 110 개 이하
• 노드 5,000개 이하
• 전체 파드 150,000개 이하
• 전체 컨테이너 300,000개 이하

노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은 클러스터 배포 방법에 따라 다르다.

클라우드 프로바이더 리소스 쿼터

여러 노드를 가지는 클러스터를 만들 때, 클라우드 프로바이더 쿼터 이슈를 피하기 위해 고려할 점은 다음과 같다.

• 다음과 같은 클라우드 리소스에 대한 쿼터 증가를 요청한다.
  • 컴퓨터 인스턴스
  • CPU
  • 스토리지 볼륨
  • 사용 중인 IP 주소
  • 패킷 필터링 규칙 세트
  • 로드밸런서 개수
  • 로그 스트림
• 일부 클라우드 프로바이더는 새로운 인스턴스 생성 속도에 상한이 있어, 클러스터 확장 작업 간 새로운 노드를 일괄적으로 배치하고, 배치 간에 일시 중지한다.

컨트롤 플레인 컴포넌트

대규모 클러스터의 경우, 충분한 컴퓨트 및 기타 리소스가 있는 컨트롤 플레인이 필요하다.

일반적으로 장애 영역 당 하나 또는 두 개의 컨트롤 플레인 인스턴스를 실행하고, 해당 인스턴스를 수직으로(vertically) 먼저 확장한 다음 (수직) 규모로 하락하는 지점에 도달한 후 수평으로(horizontally) 확장한다.

내결함성을 제공하려면 장애 영역 당 하나 이상의 인스턴스를 실행해야 한다. 쿠버네티스 노드는 동일한 장애 영역에 있는 컨트롤 플레인 엔드포인트로 트래픽을 자동으로 조정하지 않는다. 그러나, 클라우드 프로바이더는 이를 수행하기 위한 자체 메커니즘을 가지고 있을 수 있다.

예를 들어, 관리형 로드 밸런서를 사용하여 장애 영역 A 의 kubelet 및 파드에서 시작되는 트래픽을 전송하도록 로드 밸런서를 구성하고, 해당 트래픽을 A 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 컨트롤 플레인 호스트 또는 엔드포인트 장애 영역 A 이 오프라인이 되면, 영역 A 의 노드에 대한 모든 컨트롤 플레인 트래픽이 이제 영역간에 전송되고 있음을 의미한다. 각 영역에서 여러 컨트롤 플레인 호스트를 실행하면 가용성이 낮아진다.

etcd 저장소

큰 클러스터의 성능 향상을 위해, 사용자는 이벤트 오브젝트를 각각의 전용 etcd 인스턴스에 저장한다.

클러스터 생성시의 부가 스트립트이다. 클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다.

• 추가 etcd 인스턴스 시작 및 설정
• 이벤트를 저장하기 위한 API server 설정

쿠버네티스를 위한 etcd 클러스터 운영하기와 kubeadm을 이용하여 고가용성 etcd 생성하기에서 큰 클러스터를 위한 etcd를 설정하고 관리하는 방법에 대한 상세 사항을 확인한다.

애드온 리소스

쿠버네티스 리소스 제한은 파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을 최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용될 수 있는 것처럼 애드온 리소스에도 적용될 수 있다.

예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다.

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

애드온의 기본 제한은 일반적으로 중소형 쿠버네티스 클러스터에서 각 애드온을 실행한 경험에서 수집된 데이터를 기반으로 한다. 대규모 클러스터에서 실행할 때, 애드온은 종종 기본 제한보다 많은 리소스를 소비한다. 이러한 값을 조정하지 않고 대규모 클러스터를 배포하면, 애드온이 메모리 제한에 계속 도달하기 때문에 지속적으로 종료될 수 있다. 또는, 애드온이 실행될 수 있지만 CPU 시간 슬라이스 제한으로 인해 성능이 저하된다.

클러스터 애드온 리소스 문제가 발생하지 않도록, 노드가 많은 클러스터를 만들 때, 다음 사항을 고려한다.

• 일부 애드온은 수직으로 확장된다. 클러스터 또는 전체 장애 영역을 제공하는 애드온 레플리카가 하나 있다. 이러한 애드온의 경우, 클러스터를 확장할 때 요청과 제한을 늘린다.
• 많은 애드온은 수평으로 확장된다. 더 많은 파드를 실행하여 용량을 추가하지만, 매우 큰 클러스터에서는 CPU 또는 메모리 제한을 약간 높여야 할 수도 있다. VerticalPodAutoscaler는 recommender 모드에서 실행되어 요청 및 제한에 대한 제안 수치를 제공할 수 있다.
• 일부 애드온은 데몬셋(DaemonSet)에 의해 제어되는 노드 당 하나의 복사본으로 실행된다(예: 노드 수준 로그 수집기). 수평 확장 애드온의 경우와 유사하게, CPU 또는 메모리 제한을 약간 높여야 할 수도 있다.

다음 내용

VerticalPodAutoscaler 는 리소스 요청 및 파드 제한을 관리하는 데 도움이 되도록 클러스터에 배포할 수 있는 사용자 정의 리소스이다. 클러스터에 중요한 애드온을 포함하여 클러스터 컴포넌트를 확장하는 방법에 대한 자세한 내용은 Vertical Pod Autoscaler를 방문하여 배워본다.

클러스터 오토스케일러는 여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는 노드 수를 실행할 수 있도록 도와준다.

addon resizer는 클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.

2.3.2 - 여러 영역에서 실행

이 페이지에서는 여러 영역에서 쿠버네티스를 실행하는 방법을 설명한다.

배경

쿠버네티스는 단일 쿠버네티스 클러스터가 여러 장애 영역에서 실행될 수 있도록 설계되었다. 일반적으로 이러한 영역은 지역(region) 이라는 논리적 그룹 내에 적합하다. 주요 클라우드 제공자는 지역을 일관된 기능 집합을 제공하는 장애 영역 집합(가용성 영역 이라고도 함)으로 정의한다. 지역 내에서 각 영역은 동일한 API 및 서비스를 제공한다.

일반적인 클라우드 아키텍처는 한 영역의 장애가 다른 영역의 서비스도 손상시킬 가능성을 최소화하는 것을 목표로 한다.

컨트롤 플레인 동작

모든 컨트롤 플레인 컴포넌트는 컴포넌트별로 복제되는 교환 가능한 리소스 풀로 실행을 지원한다.

클러스터 컨트롤 플레인을 배포할 때, 여러 장애 영역에 컨트롤 플레인 컴포넌트의 복제본을 배치한다. 가용성이 중요한 문제인 경우, 3개 이상의 장애 영역을 선택하고 각 개별 컨트롤 플레인 컴포넌트(API 서버, 스케줄러, etcd, 클러스터 컨트롤러 관리자)를 3개 이상의 장애 영역에 복제한다. 클라우드 컨트롤러 관리자를 실행 중인 경우 선택한 모든 장애 영역에 걸쳐 이를 복제해야 한다.

노드 동작

쿠버네티스는 클러스터의 여러 노드에 걸쳐 워크로드 리소스(예: 디플로이먼트(Deployment) 또는 스테이트풀셋(StatefulSet))에 대한 파드를 자동으로 분배한다. 이러한 분배는 실패에 대한 영향을 줄이는 데 도움이 된다.

노드가 시작되면, 각 노드의 kubelet이 쿠버네티스 API에서 특정 kubelet을 나타내는 노드 오브젝트에 레이블을 자동으로 추가한다. 이러한 레이블에는 영역 정보가 포함될 수 있다.

클러스터가 여러 영역 또는 지역에 걸쳐있는 경우, 파드 토폴로지 분배 제약 조건과 함께 노드 레이블을 사용하여 파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에 분산되는 방식을 제어할 수 있다. 이러한 힌트를 통해 스케줄러는 더 나은 예상 가용성을 위해 파드를 배치할 수 있으므로, 상관 관계가 있는 오류가 전체 워크로드에 영향을 미칠 위험을 줄일 수 있다.

예를 들어, 가능할 때마다 스테이트풀셋의 3개 복제본이 모두 서로 다른 영역에서 실행되도록 제약 조건을 설정할 수 있다. 각 워크로드에 사용 중인 가용 영역을 명시적으로 정의하지 않고 이를 선언적으로 정의할 수 있다.

여러 영역에 노드 분배

쿠버네티스의 코어는 사용자를 위해 노드를 생성하지 않는다. 사용자가 직접 수행하거나, 클러스터 API와 같은 도구를 사용하여 사용자 대신 노드를 관리해야 한다.

클러스터 API와 같은 도구를 사용하면 여러 장애 도메인에서 클러스터의 워커 노드로 실행할 머신 집합과 전체 영역 서비스 중단 시 클러스터를 자동으로 복구하는 규칙을 정의할 수 있다.

파드에 대한 수동 영역 할당

생성한 파드와 디플로이먼트, 스테이트풀셋, 잡(Job)과 같은 워크로드 리소스의 파드 템플릿에 노드 셀렉터 제약 조건을 적용할 수 있다.

영역에 대한 스토리지 접근

퍼시스턴트 볼륨이 생성되면, PersistentVolumeLabel 어드미션 컨트롤러는 특정 영역에 연결된 모든 퍼시스턴트볼륨(PersistentVolume)에 영역 레이블을 자동으로 추가한다. 그런 다음 스케줄러는 NoVolumeZoneConflict 프레디케이트(predicate)를 통해 주어진 퍼시스턴트볼륨을 요구하는 파드가 해당 볼륨과 동일한 영역에만 배치되도록 한다.

해당 클래스의 스토리지가 사용할 수 있는 장애 도메인(영역)을 지정하는 퍼시스턴트볼륨클레임(PersistentVolumeClaims)에 대한 스토리지클래스(StorageClass)를 지정할 수 있다. 장애 도메인 또는 영역을 인식하는 스토리지클래스 구성에 대한 자세한 내용은 허용된 토폴로지를 참고한다.

네트워킹

쿠버네티스가 스스로 영역-인지(zone-aware) 네트워킹을 포함하지는 않는다. 네트워크 플러그인을 사용하여 클러스터 네트워킹을 구성할 수 있으며, 해당 네트워크 솔루션에는 영역별 요소가 있을 수 있다. 예를 들어, 클라우드 제공자가 type=LoadBalancer 를 사용하여 서비스를 지원하는 경우, 로드 밸런서는 지정된 연결을 처리하는 로드 밸런서 요소와 동일한 영역에서 실행 중인 파드로만 트래픽을 보낼 수 있다. 자세한 내용은 클라우드 제공자의 문서를 확인한다.

사용자 정의 또는 온-프레미스 배포의 경우, 비슷한 고려 사항이 적용된다. 다른 장애 영역 처리를 포함한 서비스와 인그레스(Ingress) 동작은 클러스터가 설정된 방식에 명확히 의존한다.

장애 복구

클러스터를 설정할 때, 한 지역의 모든 장애 영역이 동시에 오프라인 상태가 되는 경우 설정에서 서비스를 복원할 수 있는지 여부와 방법을 고려해야 할 수도 있다. 예를 들어, 영역에서 파드를 실행할 수 있는 노드가 적어도 하나 이상 있어야 하는가? 클러스터에 중요한 복구 작업이 클러스터에 적어도 하나 이상의 정상 노드에 의존하지 않는지 확인한다. 예를 들어, 모든 노드가 비정상인 경우, 하나 이상의 노드를 서비스할 수 있을 만큼 복구를 완료할 수 있도록 특별한 톨러레이션(toleration)으로 복구 작업을 실행해야 할 수 있다.

쿠버네티스는 이 문제에 대한 답을 제공하지 않는다. 그러나, 고려해야 할 사항이다.

다음 내용

스케줄러가 구성된 제약 조건을 준수하면서, 클러스터에 파드를 배치하는 방법을 알아보려면, 스케줄링과 축출(eviction)을 참고한다.

2.3.3 - 노드 구성 검증하기

노드 적합성 테스트

노드 적합성 테스트 는 노드의 시스템 검증과 기능 테스트를 제공하기 위해 컨테이너화된 테스트 프레임워크이다. 테스트는 노드가 쿠버네티스를 위한 최소 요구조건을 만족하는지를 검증한다. 그리고 테스트를 통과한 노드는 쿠버네티스 클러스터에 참 여할 자격이 주어진다.

노드 필수 구성 요소

노드 적합성 테스트를 실행하기 위해서는, 해당 노드는 표준 쿠버네티스 노드로서 동일한 전제조건을 만족해야 한다. 노드는 최소한 아래 데몬들이 설치되어 있어야 한다.

• 컨테이너 런타임 (Docker)
• Kubelet

노드 적합성 테스트 실행

노드 적합성 테스트는 다음 순서로 진행된다.

1. kubelet에 대한 --kubeconfig 옵션의 값을 계산한다. 예를 들면, 다음과 같다. --kubeconfig = / var / lib / kubelet / config.yaml. 테스트 프레임워크는 kubelet을 테스트하기 위해 로컬 컨트롤 플레인을 시작하기 때문에, http://localhost:8080 을 API 서버의 URL로 사용한다. 사용할 수 있는 kubelet 커맨드 라인 파라미터가 몇 개 있다.

• --pod-cidr: kubenet을 사용 중이라면, 임의의 CIDR을 Kubelet에 지정해주어야 한다. 예) --pod-cidr=10.180.0.0/24.
• --cloud-provider: --cloud-provider=gce를 사용 중이라면, 테스트 실행 시에는 제거해야 한다.

2. 다음 커맨드로 노드 적합성 테스트를 실행한다.

# $CONFIG_DIR는 Kublet의 파드 매니페스트 경로이다.
# $LOG_DIR는 테스트 출력 경로이다.
sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  k8s.gcr.io/node-test:0.2

다른 아키텍처에서 노드 적합성 테스트 실행

쿠버네티스는 다른 아키텍쳐용 노드 적합성 테스트 Docker 이미지도 제공한다.

선택된 테스트 실행

특정 테스트만 실행하기 위해서는 환경 변수 FOCUS에 테스트하고자 하는 테스트를 정규식으로 지정한다.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # MirrorPod 테스트만 실행
  k8s.gcr.io/node-test:0.2

특정 테스트를 건너뛰기 위해서는, 환경 변수 SKIP에 건너뛰고자 하는 테스트를 정규식으로 지정한다.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # MirrorPod 테스트만 건너뛰고 모든 적합성 테스트를 실행한다
  k8s.gcr.io/node-test:0.2

노드 적합성 테스트는 노드 e2e 테스트를 컨테이너화한 버전이다. 기본적으로, 모든 적합성 테스트를 실행한다.

이론적으로, 컨테이너와 필요한 볼륨을 적절히 설정했다면 어떤 노드 e2e 테스트도 수행할 수 있다. 하지만, 적합성 테스트가 아닌 테스트들은 훨씬 복잡한 설정이 필요하기 때문에 적합성 테스트만 실행하기를 강하게 추천한다.

주의 사항

• 테스트 후, 노드 적합성 테스트 이미지 및 기능 테스트에 사용된 이미지들을 포함하여 몇 개의 Docker 이미지들이 노드에 남는다.
• 테스트 후, 노드에 죽은 컨테이너가 남는다. 기능 테스트 도중에 생성된 컨테이너들이다.

2.3.4 - PKI 인증서 및 요구 사항

쿠버네티스는 TLS를 통한 인증을 위해서 PKI 인증서가 필요하다. 만약 kubeadm으로 쿠버네티스를 설치한다면, 클러스터에 필요한 인증서는 자동으로 생성된다. 또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다. 이를 테면, 개인키를 API 서버에 저장하지 않으므로 더 안전하게 보관할 수 있다. 이 페이지는 클러스터가 필요로 하는 인증서에 대해서 설명한다.

클러스터에서 인증서가 이용되는 방식

쿠버네티스는 다음 작업에서 PKI를 필요로 한다.

• kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
• API 서버 엔드포인트를 위한 서버 인증서
• API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
• API 서버에서 kubelet과 통신을 위한 클라이언트 인증서
• API 서버에서 etcd 간의 통신을 위한 클라이언트 인증서
• 컨트롤러 매니저와 API 서버 간의 통신을 위한 클라이언트 인증서/kubeconfig
• 스케줄러와 API 서버간 통신을 위한 클라이언트 인증서/kubeconfig
• front-proxy를 위한 클라이언트와 서버 인증서

etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다.

인증서를 저장하는 위치

만약 쿠버네티스를 kubeadm으로 설치했다면, 대부분의 인증서는 /etc/kubernetes/pki에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이나, kubeadm이 /etc/kubernetes에 저장하는 사용자 어카운트 인증서는 예외이다.

인증서 수동 설정

필요한 인증서를 kubeadm으로 생성하기 싫다면, 단일 루트 CA를 이용하거나 모든 인증서를 제공하여 생성할 수 있다. 소유한 인증기관을 이용해서 생성하는 방법에 대해서는 인증서를 살펴본다. 인증서를 관리하는 방법에 대해서는 kubeadm을 사용한 인증서 관리를 살펴본다.

단일 루트 CA

관리자에 의해 제어되는 단일 루트 CA를 만들 수 있다. 이 루트 CA는 여러 중간 CA를 생성할 수 있고, 모든 추가 생성에 관해서도 쿠버네티스 자체에 위임할 수 있다.

필요 CA:

위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 sa.key 와 sa.pub 을 얻는 것이 필요하다. 다음은 이전 표에 나온 CA 키와 인증서 파일을 보여준다.

/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-ca.key

모든 인증서

이런 개인키를 API 서버에 복사하기 원치 않는다면, 모든 인증서를 스스로 생성할 수 있다.

필요한 인증서:

[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름(kubeadm이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local)

kind는 하나 이상의 x509 키 사용 종류를 가진다.

인증서 파일 경로

인증서는 권고하는 파일 경로에 존재해야 한다(kubeadm에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정해야 한다.

서비스 계정 키 쌍에도 동일한 고려 사항이 적용된다.

다음은 키와 인증서를 모두 생성할 때에 제공해야 하는 이전 표에 있는 파일의 경로를 보여준다.

/etc/kubernetes/pki/etcd/ca.key
/etc/kubernetes/pki/etcd/ca.crt
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/ca.key
/etc/kubernetes/pki/ca.crt
/etc/kubernetes/pki/apiserver.key
/etc/kubernetes/pki/apiserver.crt
/etc/kubernetes/pki/apiserver-kubelet-client.key
/etc/kubernetes/pki/apiserver-kubelet-client.crt
/etc/kubernetes/pki/front-proxy-ca.key
/etc/kubernetes/pki/front-proxy-ca.crt
/etc/kubernetes/pki/front-proxy-client.key
/etc/kubernetes/pki/front-proxy-client.crt
/etc/kubernetes/pki/etcd/server.key
/etc/kubernetes/pki/etcd/server.crt
/etc/kubernetes/pki/etcd/peer.key
/etc/kubernetes/pki/etcd/peer.crt
/etc/kubernetes/pki/etcd/healthcheck-client.key
/etc/kubernetes/pki/etcd/healthcheck-client.crt
/etc/kubernetes/pki/sa.key
/etc/kubernetes/pki/sa.pub

각 사용자 계정을 위한 인증서 설정하기

반드시 이런 관리자 계정과 서비스 계정을 설정해야 한다.

1. 각 환경 설정에 대해 주어진 CN과 O를 이용하여 x509 인증서와 키쌍을 생성한다.

2. 각 환경 설정에 대해 다음과 같이 kubectl를 실행한다.

KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system

이 파일들은 다음과 같이 사용된다.

다음의 파일은 이전 표에 나열된 파일의 전체 경로를 보여준다.

/etc/kubernetes/admin.conf
/etc/kubernetes/kubelet.conf
/etc/kubernetes/controller-manager.conf
/etc/kubernetes/scheduler.conf

3 - 개념

개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 클러스터를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다.

3.1 - 개요

3.1.1 - 쿠버네티스란 무엇인가?

이 페이지에서는 쿠버네티스 개요를 설명한다.

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.

여정 돌아보기

시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자.

전통적인 배포 시대: 초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다.

가상화된 배포 시대: 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.

가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.

각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.

컨테이너 개발 시대: 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.

컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.

• 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
• 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
• 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
• 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
• 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
• 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
• 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
• 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
• 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
• 자원 사용량: 리소스 사용량: 고효율 고집적.

쿠버네티스가 왜 필요하고 무엇을 할 수 있나

컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?

그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.

쿠버네티스는 다음을 제공한다.

• 서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
• 자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
• 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
• 자동화된 복구(self-healing) 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
• 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

쿠버네티스가 아닌 것

쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

쿠버네티스는:

• 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
• 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
• 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
• 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
• 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
• 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
• 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

다음 내용

• 쿠버네티스 구성요소 살펴보기
• 시작하기 준비가 되었는가?

3.1.2 - 쿠버네티스 컴포넌트

쿠버네티스를 배포하면 클러스터를 얻는다.

쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다.

워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 컨트롤 플레인은 워커 노드와 클러스터 내 파드를 관리한다. 프로덕션 환경에서는 일반적으로 컨트롤 플레인이 여러 컴퓨터에 걸쳐 실행되고, 클러스터는 일반적으로 여러 노드를 실행하므로 내결함성과 고가용성이 제공된다.

이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한 다양한 컴포넌트들에 대해 요약하고 정리한다.

컨트롤 플레인 컴포넌트

컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것)를 감지하고 반응한다.

컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고, 사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서 실행되는 컨트롤 플레인 설정의 예제를 보려면 kubeadm을 사용하여 고가용성 클러스터 만들기를 확인해본다.

kube-apiserver

API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드이다.

쿠버네티스 API 서버의 주요 구현은 kube-apiserver 이다. kube-apiserver는 수평으로 확장되도록 디자인되었다. 즉, 더 많은 인스턴스를 배포해서 확장할 수 있다. 여러 kube-apiserver 인스턴스를 실행하고, 인스턴스간의 트래픽을 균형있게 조절할 수 있다.

etcd

모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.

쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, 이 데이터를 백업하는 계획은 필수이다.

etcd에 대한 자세한 정보는, 공식 문서를 참고한다.

kube-scheduler

노드가 배정되지 않은 새로 생성된 파드 를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.

스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다.

kube-controller-manager

컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.

논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

이들 컨트롤러는 다음을 포함한다.

• 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임을 가진다.
• 레플리케이션 컨트롤러: 시스템의 모든 레플리케이션 컨트롤러 오브젝트에 대해 알맞은 수의 파드들을 유지시켜 주는 책임을 가진다.
• 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채운다(즉, 서비스와 파드를 연결시킨다.)
• 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

cloud-controller-manager

cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다.

kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다.

다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다.

• 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것
• 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것
• 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것

노드 컴포넌트

노드 컴포넌트는 동작 중인 파드를 유지시키고 쿠버네티스 런타임 환경을 제공하며, 모든 노드 상에서 동작한다.

kubelet

클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다.

kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부이다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다.

kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다.

컨테이너 런타임

컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.

쿠버네티스는 여러 컨테이너 런타임을 지원한다. 도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어.

애드온

애드온은 쿠버네티스 리소스(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 기능을 구현한다. 이들은 클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 kube-system 네임스페이스에 속한다.

선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는 애드온을 참조한다.

DNS

여타 애드온들이 절대적으로 요구되지 않지만, 많은 예시에서 필요로 하기 때문에 모든 쿠버네티스 클러스터는 클러스터 DNS를 갖추어야만 한다.

클러스터 DNS는 구성환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버다.

쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함한다.

웹 UI (대시보드)

대시보드는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI다. 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 문제 해결을 할 수 있도록 해준다.

컨테이너 리소스 모니터링

컨테이너 리소스 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다.

클러스터-레벨 로깅

클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.

다음 내용

• 노드에 대해 더 배우기
• 컨트롤러에 대해 더 배우기
• kube-scheduler에 대해 더 배우기
• etcd의 공식 문서 읽기

3.1.3 - 쿠버네티스 API

쿠버네티스 컨트롤 플레인의 핵심은 API 서버이다. API 서버는 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공한다.

쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예: 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다.

대부분의 작업은 kubectl 커맨드 라인 인터페이스 또는 API를 사용하는 kubeadm과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다.

쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우 클라이언트 라이브러리 중 하나를 사용하는 것이 좋다.

OpenAPI 명세

완전한 API 상세 내용은 OpenAPI를 활용해서 문서화했다.

OpenAPI 규격은 /openapi/v2 엔드포인트에서만 제공된다. 다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다.

쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한 자세한 내용은 쿠버네티스 Protobuf 직렬화 디자인 제안과 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한 IDL(인터페이스 정의 언어) 파일을 참고한다.

지속성

쿠버네티스는 오브젝트의 직렬화된 상태를 etcd에 기록하여 저장한다.

API 그룹과 버전 규칙

필드를 쉽게 제거하거나 리소스 표현을 재구성하기 위해, 쿠버네티스는 각각 /api/v1 또는 /apis/rbac.authorization.k8s.io/v1alpha1 과 같은 서로 다른 API 경로에서 여러 API 버전을 지원한다.

버전 규칙은 리소스나 필드 수준이 아닌 API 수준에서 수행되어 API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제공하고 수명 종료 및/또는 실험적 API에 대한 접근을 제어할 수 있도록 한다.

보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는 활성화 또는 비활성화가 가능한 API 그룹을 구현한다.

API 리소스는 API 그룹, 리소스 유형, 네임스페이스 (네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 API 버전 간의 변환을 투명하게 처리한다. 서로 다른 모든 버전은 실제로 동일한 지속 데이터의 표현이다. API 서버는 여러 API 버전을 통해 동일한 기본 데이터를 제공할 수 있다.

예를 들어, 동일한 리소스에 대해 v1 과 v1beta1 이라는 두 가지 API 버전이 있다고 가정한다. 원래 API의 v1beta1 버전을 사용하여 오브젝트를 만든 경우, 나중에 v1beta1 또는 v1 API 버전을 사용하여 해당 오브젝트를 읽거나, 업데이트하거나, 삭제할 수 있다.

API 변경 사항

성공적인 시스템은 새로운 유스케이스가 등장하거나 기존 사례가 변경됨에 따라 성장하고 변화해야 한다. 따라서, 쿠버네티스는 쿠버네티스 API가 지속적으로 변경되고 성장할 수 있도록 설계했다. 쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 깨지 않고 다른 프로젝트가 적응할 기회를 가질 수 있도록 장기간 해당 호환성을 유지하는 것을 목표로 한다.

일반적으로, 새 API 리소스와 새 리소스 필드는 자주 추가될 수 있다. 리소스 또는 필드를 제거하려면 API 지원 중단 정책을 따라야 한다.

쿠버네티스는 일반적으로 API 버전 v1 에서 안정 버전(GA)에 도달하면, 공식 쿠버네티스 API에 대한 호환성 유지를 강력하게 이행한다. 또한, 쿠버네티스는 가능한 경우 베타 API 버전에서도 호환성을 유지한다. 베타 API를 채택하면 기능이 안정된 후에도 해당 API를 사용하여 클러스터와 계속 상호 작용할 수 있다.

API 버전 수준 정의에 대한 자세한 내용은 API 버전 레퍼런스를 참조한다.

API 확장

쿠버네티스 API는 다음 두 가지 방법 중 하나로 확장할 수 있다.

1. 커스텀 리소스를 사용하면 API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다.
2. 애그리게이션 레이어(aggregation layer)를 구현하여 쿠버네티스 API를 확장할 수도 있다.

다음 내용

• 자체 CustomResourceDefinition을 추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기.
• 쿠버네티스 API 접근 제어하기는 클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다.
• API 레퍼런스를 읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기.
• API 변경 사항에서 호환 가능한 변경 사항을 구성하고, API를 변경하는 방법에 대해 알아본다.

3.1.4 - 쿠버네티스 오브젝트로 작업하기

3.1.4.1 - 쿠버네티스 오브젝트 이해하기

이 페이지에서는 쿠버네티스 오브젝트가 쿠버네티스 API에서 어떻게 표현되고, 그 오브젝트를 어떻게 .yaml 형식으로 표현할 수 있는지에 대해 설명한다.

쿠버네티스 오브젝트 이해하기

쿠버네티스 오브젝트 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.

• 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
• 그 애플리케이션이 이용할 수 있는 리소스
• 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책

쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다. 오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다. 오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 의도한 상태 가 된다.

생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, 쿠버네티스 API를 이용해야 한다. 예를 들어, kubectl 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 여러분은 클라이언트 라이브러리 중 하나를 이용하여 여러분만의 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.

오브젝트 명세(spec)와 상태(status)

거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 spec 과 오브젝트 status 이다. spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에 원하는 특징(의도한 상태)에 대한 설명을 제공해서 설정한다.

status 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태 를 설명한다. 쿠버네티스 컨트롤 플레인은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다.

예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 spec과 status간의 차이에 대응한다.

오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, Kubernetes API Conventions 를 참조한다.

쿠버네티스 오브젝트 기술하기

쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 kubectl을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. 대부분의 경우 정보를 .yaml 파일로 kubectl에 제공한다. kubectl은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다.

여기 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec을 보여주는 .yaml 파일 예시가 있다.

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 kubectl 커맨드-라인 인터페이스에 인자값으로 .yaml 파일을 건네 kubectl apply 커맨드를 이용하는 것이다. 다음 예시와 같다.

kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record

그 출력 내용은 다음과 유사하다.

deployment.apps/nginx-deployment created

요구되는 필드

생성하고자 하는 쿠버네티스 오브젝트에 대한 .yaml 파일 내, 다음 필드를 위한 값들을 설정해 줘야한다.

• apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
• kind - 어떤 종류의 오브젝트를 생성하고자 하는지
• metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
• spec - 오브젝트에 대해 어떤 상태를 의도하는지

오브젝트 spec에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. 쿠버네티스 API 레퍼런스 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다.

예를 들어, API 내 파드에 대한 상세 정보는 spec 필드에 대한 레퍼런스에서, 디플로이먼트에 대한 상세 정보는 spec 필드에 대한 레퍼런스에서 확인할 수 있다. 해당 API 레퍼런스 페이지에서 PodSpec과 DeploymentSpec에 대해 언급된 내용을 볼 수 있다. 이 이름들은 쿠버네티스가 API를 구현하는데 사용한 Go 언어 코드 구현의 세부 내용이다.

다음 내용

• 파드와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다.
• 쿠버네티스의 컨트롤러에 대해 배운다.
• API 개념의 더 많은 설명은 쿠버네티스 API 사용을 본다.

3.1.4.2 - 쿠버네티스 오브젝트 관리

kubectl 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한 몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을 제공한다. Kubectl로 오브젝트 관리하기에 대한 자세한 설명은 Kubectl 서적에서 확인한다.

관리 기법

명령형 커맨드

명령형 커맨드를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로 직접 동작시킨다. 사용자는 실행할 작업을 인수 또는 플래그로 kubectl 커맨드에 지정한다.

이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한 추천 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인 영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.

예시

디플로이먼트 오브젝트를 생성하여 nginx 컨테이너의 인스턴스를 구동시킨다.

kubectl create deployment nginx --image nginx

트레이드 오프

오브젝트 구성에 비해 장점은 다음과 같다.

• 커맨드는 하나의 동작을 나타내는 단어로 표현된다.
• 커맨드는 클러스터를 수정하기 위해 단 하나의 단계만을 필요로 한다.

오브젝트 구성에 비해 단점은 다음과 같다.

• 커맨드는 변경 검토 프로세스와 통합되지 않는다.
• 커맨드는 변경에 관한 감사 추적(audit trail)을 제공하지 않는다.
• 커맨드는 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
• 커맨드는 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.

명령형 오브젝트 구성

명령형 오브젝트 구성에서는 kubectl 커맨드로 작업(생성, 교체 등), 선택적 플래그, 그리고 최소 하나의 파일 이름을 지정한다. 그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를 포함해야만 한다.

오브젝트 정의에 대한 더 자세한 내용은 API 참조를 참고한다.

예시

구성 파일에 정의된 오브젝트를 생성한다.

kubectl create -f nginx.yaml

두 개의 구성 파일에 정의된 오브젝트를 삭제한다.

kubectl delete -f nginx.yaml -f redis.yaml

활성 동작하는 구성을 덮어씀으로써 구성 파일에 정의된 오브젝트를 업데이트한다.

kubectl replace -f nginx.yaml

트레이드 오프

명령형 커맨드에 비해 장점은 다음과 같다.

• 오브젝트 구성은 Git과 같은 소스 컨트롤 시스템에 보관할 수 있다.
• 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
• 오브젝트 구성은 새로운 오브젝트 생성을 위한 템플릿을 제공한다.

명령형 커맨드에 비해 단점은 다음과 같다.

• 오브젝트 구성은 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
• 오브젝트 구성은 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.

선언형 오브젝트 구성에 비해 장점은 다음과 같다.

• 명령형 오브젝트 구성의 동작은 보다 간결하고 이해하기 쉽다.
• 쿠버네티스 버전 1.5 부터는 더 성숙한 명령형 오브젝트 구성을 제공한다.

선언형 오브젝트 구성에 비해 단점은 다음과 같다.

• 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 가장 적합하다.
• 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.

선언형 오브젝트 구성

선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할 작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은 kubectl에 의해 오브젝트마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해 다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.

예시

configs 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를 생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 diff 하고 나서 적용할 수 있다.

kubectl diff -f configs/
kubectl apply -f configs/

재귀적으로 디렉터리를 처리한다.

kubectl diff -R -f configs/
kubectl apply -R -f configs/

트레이드 오프

명령형 오브젝트 구성에 비해 장점은 다음과 같다.

• 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
• 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.

명령형 오브젝트 구성에 비해 단점은 다음과 같다.

• 선언형 오브젝트 구성은 예상치 못한 결과를 디버깅하고 이해하기가 더 어렵다.
• diff를 사용한 부분 업데이트는 복잡한 병합 및 패치 작업을 일으킨다.

다음 내용

• 명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기
• 오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)
• 오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)
• Kustomize를 사용한 쿠버네티스 오브젝트 관리하기(선언형)
• Kubectl 커맨드 참조
• Kubectl 서적
• 쿠버네티스 API 참조

3.1.4.3 - 오브젝트 이름과 ID

클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 이름 을 가지고 있다. 또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 UID 를 가지고 있다.

예를 들어, 이름이 myapp-1234인 파드는 동일한 네임스페이스 내에서 하나만 존재할 수 있지만, 이름이 myapp-1234인 파드와 디플로이먼트는 각각 존재할 수 있다.

유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 레이블과 어노테이션을 제공한다.

이름

/api/v1/pods/some-name과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열.

특정 시점에 같은 종류(kind) 내에서는 하나의 이름은 하나의 오브젝트에만 지정될 수 있다. 하지만, 오브젝트를 삭제한 경우, 삭제된 오브젝트와 같은 이름을 새로운 오브젝트에 지정 가능하다.

다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.

DNS 서브도메인 이름

대부분의 리소스 유형에는 RFC 1123에 정의된 대로 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

• 253자를 넘지 말아야 한다.
• 소문자와 영숫자 - 또는 . 만 포함한다.
• 영숫자로 시작한다.
• 영숫자로 끝난다.

RFC 1123 레이블 이름

일부 리소스 유형은 RFC 1123에 정의된 대로 DNS 레이블 표준을 따라야 한다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.

• 최대 63자이다.
• 소문자와 영숫자 또는 - 만 포함한다.
• 영숫자로 시작한다.
• 영숫자로 끝난다.

RFC 1035 레이블 이름

몇몇 리소스 타입은 자신의 이름을 RFC 1035에 정의된 DNS 레이블 표준을 따르도록 요구한다. 이것은 이름이 다음을 만족해야 한다는 의미이다.

• 최대 63개 문자를 포함
• 소문자 영숫자 또는 '-'만 포함
• 알파벳 문자로 시작
• 영숫자로 끝남

경로 세그먼트 이름

일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수 있어야 한다. 즉 이름이 "." 또는 ".."이 아닐 수 있으며 이름에는 "/" 또는 "%"가 포함될 수 없다.

아래는 파드의 이름이 nginx-demo라는 매니페스트 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

UID

오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열.

쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.

쿠버네티스 UID는 보편적으로 고유한 식별자이다(또는 UUID라고 한다). UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.

다음 내용

• 쿠버네티스의 레이블에 대해 읽기.
• 쿠버네티스의 식별자와 이름 디자인 문서 읽기.

3.1.4.4 - 네임스페이스

쿠버네티스에서, 네임스페이스 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 (예: 디플로이먼트, 서비스 등) 에만 적용 가능하며 클러스터 범위의 오브젝트 (예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등) 에는 적용 불가능하다.

여러 개의 네임스페이스를 사용하는 경우

네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는 네임스페이스를 전혀 고려할 필요가 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자.

네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.

네임스페이스는 클러스터 자원을 (리소스 쿼터를 통해) 여러 사용자 사이에서 나누는 방법이다.

동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를 구별하기 위해 레이블을 사용한다.

네임스페이스 다루기

네임스페이스의 생성과 삭제는 네임스페이스 관리자 가이드 문서에 기술되어 있다.

네임스페이스 조회

사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.

• default 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
• kube-system 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
• kube-public 이 네임스페이스는 자동으로 생성되며 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.
• kube-node-lease 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스
• kube-node-lease 이 네임스페이스는 각 노드와 연관된 리스 오브젝트를 갖는다. 노드 리스는 kubelet이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.

요청에 네임스페이스 설정하기

현재 요청에 대한 네임스페이스를 설정하기 위해서 --namespace 플래그를 사용한다.

예를 들면,

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

선호하는 네임스페이스 설정하기

이후 모든 kubectl 명령에서 사용하는 네임스페이스를 컨텍스트에 영구적으로 저장할 수 있다.

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# 확인하기
kubectl config view --minify | grep namespace:

네임스페이스와 DNS

서비스를 생성하면 해당 DNS 엔트리가 생성된다. 이 엔트리는 <서비스-이름>.<네임스페이스-이름>.svc.cluster.local의 형식을 갖는데, 이는 컨테이너가 <서비스-이름>만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다. 네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다.

모든 오브젝트가 네임스페이스에 속하지는 않음

대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. 그리고 노드나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다.

다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.

# 네임스페이스에 속하는 리소스
kubectl api-resources --namespaced=true

# 네임스페이스에 속하지 않는 리소스
kubectl api-resources --namespaced=false

자동 레이블링

쿠버네티스 컨트롤 플레인은 NamespaceDefaultLabelName 기능 게이트가 활성화된 경우 모든 네임스페이스에 변경할 수 없는(immutable) 레이블 kubernetes.io / metadata.name 을 설정한다. 레이블 값은 네임스페이스 이름이다.

다음 내용

• 신규 네임스페이스 생성에 대해 더 배우기.
• 네임스페이스 삭제에 대해 더 배우기.

3.1.4.5 - 레이블과 셀렉터

레이블 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다. 오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 어노테이션으로 기록해야 한다.

사용 동기

레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.

레이블 예시:

• "release" : "stable", "release" : "canary"
• "environment" : "dev", "environment" : "qa", "environment" : "production"
• "tier" : "frontend", "tier" : "backend", "tier" : "cache"
• "partition" : "customerA", "partition" : "customerB"
• "track" : "daily", "track" : "weekly"

이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.

구문과 캐릭터 셋

레이블 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(/)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며, 대시(-), 밑줄(_), 점(.)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(.)과 전체 253자 이하, 슬래시(/)로 구분되는 DNS 레이블이다.

접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: kube-scheduler, kube-controller-manager, kube-apiserver, kubectl 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어 있다.

유효한 레이블 값은 다음과 같다.

• 63 자 이하여야 하고 (공백일 수도 있음),
• (공백이 아니라면) 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며,
• 알파벳과 숫자, 대시(-), 밑줄(_), 점(.)을 중간에 포함할 수 있다.

다음의 예시는 파드에 environment: production 과 app: nginx 2개의 레이블이 있는 구성 파일이다.

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

레이블 셀렉터

이름과 UID와 다르게 레이블은 고유하지 않다. 일반적으로 우리는 많은 오브젝트에 같은 레이블을 가질 것으로 예상한다.

레이블 셀렉터를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. 레이블 셀렉터는 쿠버네티스 코어 그룹의 기본이다.

API는 현재 일치성 기준 과 집합성 기준 이라는 두 종류의 셀렉터를 지원한다. 레이블 셀렉터는 쉼표로 구분된 다양한 요구사항 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(&&) 연산자로 구분되는 역할을 하도록 해야 한다.

비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. 셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다.

일치성 기준 요건

일치성 기준 또는 불일치 기준 의 요구사항으로 레이블의 키와 값의 필터링을 허용한다. 일치하는 오브젝트는 추가 레이블을 가질 수 있지만, 레이블의 명시된 제약 조건을 모두 만족해야 한다. =,==,!= 이 세 가지 연산자만 허용한다. 처음 두 개의 연산자의 일치성(그리고 동의어), 나머지는 불일치 를 의미한다. 예를 들면,

environment = production
tier != frontend

전자는 environment를 키로 가지는 것과 production을 값으로 가지는 모든 리소스를 선택한다. 후자는 tier를 키로 가지고, 값을 frontend를 가지는 리소스를 제외한 모든 리소스를 선택하고, tier를 키로 가지며, 값을 공백으로 가지는 모든 리소스를 선택한다. environment=production,tier!=frontend 처럼 쉼표를 통해 한 문장으로 frontend를 제외한 production을 필터링할 수 있다.

일치성 기준 레이블 요건에 대한 하나의 이용 시나리오는 파드가 노드를 선택하는 기준을 지정하는 것이다. 예를 들어, 아래 샘플 파드는 "accelerator=nvidia-tesla-p100" 레이블을 가진 노드를 선택한다.

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

집합성 기준 요건

집합성 기준 레이블 요건에 따라 값 집합을 키로 필터링할 수 있다. in,notin과 exists(키 식별자만 해당)의 3개의 연산자를 지원한다. 예를 들면,

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

• 첫 번째 예시에서 키가 environment이고 값이 production 또는 qa인 모든 리소스를 선택한다.
• 두 번째 예시에서 키가 tier이고 값이 frontend와 backend를 가지는 리소스를 제외한 모든 리소스와 키로 tier를 가지고 값을 공백으로 가지는 모든 리소스를 선택한다.
• 세 번째 예시에서 레이블의 값에 상관없이 키가 partition을 포함하는 모든 리소스를 선택한다.
• 네 번째 예시에서 레이블의 값에 상관없이 키가 partition을 포함하지 않는 모든 리소스를 선택한다.

마찬가지로 쉼표는 AND 연산자로 작동한다. 따라서 partition,environment notin (qa)와 같이 사용하면 값과 상관없이 키가 partition인 것과 키가 environment이고 값이 qa와 다른 리소스를 필터링할 수 있다. 집합성 기준 레이블 셀렉터는 일반적으로 environment=production과 environment in (production)을 같은 것으로 본다. 유사하게는 !=과 notin을 같은 것으로 본다.

집합성 기준 요건은 일치성 기준 요건과 조합해서 사용할 수 있다. 예를 들어 partition in (customerA, customerB),environment!=qa

API

LIST와 WATCH 필터링

LIST와 WATCH 작업은 쿼리 파라미터를 사용해서 반환되는 오브젝트 집합을 필터링하기 위해 레이블 셀렉터를 지정할 수 있다. 다음의 두 가지 요건 모두 허용된다(URL 쿼리 문자열을 그대로 표기함).

• 일치성 기준 요건: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
• 집합성 기준 요건: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

두 가지 레이블 셀렉터 스타일은 모두 REST 클라이언트를 통해 선택된 리소스를 확인하거나 목록을 볼 수 있다. 예를 들어, kubectl로 apiserver를 대상으로 일치성 기준 으로 하는 셀렉터를 다음과 같이 이용할 수 있다.

kubectl get pods -l environment=production,tier=frontend

또는 집합성 기준 요건을 사용하면

kubectl get pods -l 'environment in (production),tier in (frontend)'

앞서 안내한 것처럼 집합성 기준 요건은 더 보여준다. 예시에서 다음과 같이 OR 연산자를 구현할 수 있다.

kubectl get pods -l 'environment in (production, qa)'

또는 exists 연산자에 불일치한 것으로 제한할 수 있다.

kubectl get pods -l 'environment,environment notin (frontend)'

API 오브젝트에서 참조 설정

services 와 replicationcontrollers와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 파드와 같은 다른 리소스 집합을 선택한다.

서비스와 레플리케이션 컨트롤러

services에서 지정하는 파드 집합은 레이블 셀렉터로 정의한다. 마찬가지로 replicationcontrollers가 관리하는 파드의 오브젝트 그룹도 레이블 셀렉터로 정의한다.

서비스와 레플리케이션 컨트롤러의 레이블 셀렉터는 json 또는 yaml 파일에 매핑된 일치성 기준 요구사항의 셀렉터만 지원한다.

"selector": {
    "component" : "redis",
}

or

selector:
    component: redis

json 또는 yaml 서식에서 셀렉터는 component=redis 또는 component in (redis) 모두 같은 것이다.

세트-기반 요건을 지원하는 리소스

Job, Deployment, ReplicaSet 그리고 DaemonSet 같은 새로운 리소스들은 집합성 기준 의 요건도 지원한다.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels는 {key,value}의 쌍과 매칭된다. matchLabels에 매칭된 단일 {key,value}는 matchExpressions의 요소와 같으며 key 필드는 "key"로, operator는 "In" 그리고 values에는 "value"만 나열되어 있다. matchExpressions는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. matchLabels와 matchExpressions 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.

노드 셋 선택

레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. 자세한 내용은 노드 선택 문서를 참조한다.

3.1.4.6 - 어노테이션

쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를 오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타데이터를 검색할 수 있다.

오브젝트에 메타데이터 첨부

레이블이나 어노테이션을 사용하여 쿠버네티스 오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트 컬렉션을 찾을 수 있다. 반면에, 어노테이션은 오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는 작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서 허용되지 않는 문자를 포함할 수 있다.

어노테이션은 레이블과 같이 키/값 맵이다.

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

다음은 어노테이션에 기록할 수 있는 정보의 예제이다.

• 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은 클라이언트 또는 서버가 설정한 기본 값, 자동 생성된 필드, 그리고 오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.

• 빌드, 릴리스, 또는 타임 스탬프, 릴리스 ID, git 브랜치, PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.

• 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.

• 디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보: 예를 들면, 이름, 버전, 그리고 빌드 정보.

• 다른 생태계 구성 요소의 관련 오브젝트 URL과 같은 사용자 또는 도구/시스템 출처 정보.

• 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트

• 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은 해당 정보를 찾을 수 있는 디렉터리 진입점.

• 행동을 수정하거나 비표준 기능을 수행하기 위한 최종 사용자의 지시 사항.

어노테이션을 사용하는 대신, 이 유형의 정보를 외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 공유 클라이언트 라이브러리와 도구 생성을 훨씬 더 어렵게 만들 수 있다.

문법과 캐릭터 셋

어노테이션 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름(name)이며, 슬래시(/)로 구분된다. 이름 세그먼트는 필수이며, 영문 숫자([a-z0-9A-Z])로 시작하고 끝나는 63자 이하이어야 하고, 사이에 대시(-), 밑줄(_), 점(.)이 들어갈 수 있다. 접두사는 선택적이다. 지정된 경우, 접두사는 DNS 서브도메인이어야 한다. 점(.)으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(/)가 붙는다.

접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(예 :kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, 또는 다른 써드파티 자동화)는 접두사를 지정해야 한다.

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.

다음은 imageregistry: https://hub.docker.com/ 어노테이션이 있는 파드의 구성 파일 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

다음 내용

레이블과 셀렉터에 대해 알아본다.

3.1.4.7 - 필드 셀렉터

필드 셀렉터 는 한 개 이상의 리소스 필드 값에 따라 쿠버네티스 리소스를 선택하기 위해 사용된다. 필드 셀렉터 쿼리의 예시는 다음과 같다.

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

다음의 kubectl 커맨드는 status.phase 필드의 값이 Running 인 모든 파드를 선택한다.

kubectl get pods --field-selector status.phase=Running

사용 가능한 필드

사용 가능한 필드는 쿠버네티스의 리소스 종류에 따라서 다르다. 모든 리소스 종류는 metadata.name 과 metadata.namespace 필드 셀렉터를 사용할 수 있다. 사용할 수 없는 필드 셀렉터를 사용하면 다음과 같이 에러를 출력한다.

kubectl get ingress --field-selector foo.bar=baz

Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

사용 가능한 연산자

필드 셀렉터에서 =, ==, != 연산자를 사용할 수 있다 (=와 ==는 동일한 의미이다). 예를 들면, 다음의 kubectl 커맨드는 default 네임스페이스에 속해있지 않은 모든 쿠버네티스 서비스를 선택한다.

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

연계되는 셀렉터

레이블을 비롯한 다른 셀렉터처럼, 쉼표로 구분되는 목록을 통해 필드 셀렉터를 연계해서 사용할 수 있다. 다음의 kubectl 커맨드는 status.phase 필드가 Running 이 아니고, spec.restartPolicy 필드가 Always 인 모든 파드를 선택한다.

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

여러 개의 리소스 종류

필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 kubectl 커맨드는 default 네임스페이스에 속해있지 않은 모든 스테이트풀셋(StatefulSet)과 서비스를 선택한다.

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

3.1.4.8 - 권장 레이블

kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝트를 시각화 하고 관리할 수 있다. 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고 도구들이 상호 운용적으로 작동할 수 있도록 한다.

권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다.

메타데이터는 애플리케이션 의 개념을 중심으로 정리된다. 쿠버네티스는 플랫폼 서비스(PaaS)가 아니며 애플리케이션에 대해 공식적인 개념이 없거나 강요하지 않는다. 대신 애플리케이션은 비공식적이며 메타데이터로 설명된다. 애플리케이션에 포함된 정의는 유연하다.

공유 레이블과 주석에는 공통 접두사인 app.kubernetes.io 가 있다. 접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다. 공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다.

레이블

레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다.

위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/created-by: controller-manager

애플리케이션과 애플리케이션 인스턴스

애플리케이션은 동일한 쿠버네티스 클러스터에, 심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에 WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다.

애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. 예를 들어 WordPress는 애플리케이션 이름으로 app.kubernetes.io/name 이라는 레이블에 wordpress 라는 값을 가지며, 애플리케이션 인스턴스 이름으로는 app.kubernetes.io/instance 라는 레이블에 wordpress-abcxzy 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다.

예시

위 레이블을 사용하는 다른 방식에 대한 예시는 다양한 복잡성이 있다.

단순한 스테이트리스 서비스

Deployment 와 Service 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다.

Deployment 는 애플리케이션을 실행하는 파드를 감시하는 데 사용한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

Service는 애플리케이션을 노출하기 위해 사용한다.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

데이터베이스가 있는 웹 애플리케이션

Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. 다음 식별자는 이 애플리케이션을 배포하는 데 사용하는 오브젝트의 시작을 보여준다.

WordPress를 배포하는 데 다음과 같이 Deployment 로 시작한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

Service 는 애플리케이션을 노출하기 위해 사용한다.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

MySQL은 StatefulSet 에 MySQL의 소속과 상위 애플리케이션에 대한 메타데이터가 포함되어 노출된다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

Service 는 WordPress의 일부로 MySQL을 노출하는 데 이용한다.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

MySQL StatefulSet 과 Service 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다.

3.2 - 클러스터 아키텍처

3.2.1 - 노드

쿠버네티스는 컨테이너를 파드내에 배치하고 노드 에서 실행함으로 워크로드를 구동한다. 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는 컨트롤 플레인에 의해 관리되며 파드를 실행하는 데 필요한 서비스를 포함한다.

일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는 환경에서는 하나만 있을 수도 있다.

노드의 컴포넌트에는 kubelet, 컨테이너 런타임 그리고 kube-proxy가 포함된다.

관리

API 서버에 노드를 추가하는 두가지 주요 방법이 있다.

1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
2. 사용자(또는 다른 사용자)가 노드 오브젝트를 수동으로 추가

노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는 kubelet이 노드의 metadata.name 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다. 노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다. 그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에 대해 무시된다.

노드 오브젝트의 이름은 유효한 DNS 서브도메인 이름이어야 한다.

노드 이름 고유성

이름은 노드를 식별한다. 두 노드는 동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가 동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한 상태(예: 네트워크 설정, 루트 디스크 내용)와 노드 레이블과 같은 동일한 속성(attribute)을 갖는다고 암시적으로 가정한다. 인스턴스가 이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나 업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고 업데이트 후 다시 추가해야 한다.

노드에 대한 자체-등록(self-registration)

kubelet 플래그 --register-node가 참(기본값)일 경우, kubelet은 API 서버에 스스로 등록을 시도할 것이다. 이는 선호되는 패턴이며, 대부분의 배포판에서 사용된다.

자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.

• --kubeconfig - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.

• --cloud-provider - 자신에 대한 메터데이터를 읽기 위해 어떻게 클라우드 제공자와 소통할지에 대한 방법.

• --register-node - 자동으로 API 서버에 등록.

• --register-with-taints - 주어진 테인트(taint) 리스트(콤마로 분리된 <key>=<value>:<effect>)를 가진 노드 등록.

  register-node가 거짓이면 동작 안 함.

• --node-ip - 노드의 IP 주소.

• --node-labels - 클러스터에 노드를 등록할 때 추가 할 레이블(NodeRestriction admission plugin에 의해 적용되는 레이블 제한 사항 참고).

• --node-status-update-frequency - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.

Node authorization mode와 NodeRestriction admission plugin이 활성화 되면, 각 kubelet은 자신이 속한 노드의 리소스에 대해서만 생성/수정할 권한을 가진다.

수동 노드 관리

kubectl을 사용해서 노드 오브젝트를 생성하고 수정할 수 있다.

노드 오브젝트를 수동으로 생성하려면 kubelet 플래그를 --register-node=false 로 설정한다.

--register-node 설정과 관계 없이 노드 오브젝트를 수정할 수 있다. 예를 들어 기존 노드에 레이블을 설정하거나, 스케줄 불가로 표시할 수 있다.

파드의 노드 셀렉터와 함께 노드의 레이블을 사용해서 스케줄링을 제어할 수 있다. 예를 들어, 사용 가능한 노드의 하위 집합에서만 실행되도록 파드를 제한할 수 있다.

노드를 스케줄 불가로 표시하면 스케줄러가 해당 노드에 새 파드를 배치할 수 없지만, 노드에 있는 기존 파드에는 영향을 미치지 않는다. 이는 노드 재부팅 또는 기타 유지보수 준비 단계에서 유용하다.

노드를 스케줄 불가로 표시하려면 다음을 실행한다.

kubectl cordon $NODENAME

보다 자세한 내용은 안전하게 노드를 드레인(drain)하기 를 참고한다.

노드 상태

노드의 상태는 다음의 정보를 포함한다.

• 주소
• 컨디션
• 용량과 할당가능
• 정보

kubectl 을 사용해서 노드 상태와 기타 세부 정보를 볼수 있다.

kubectl describe node <insert-node-name-here>

출력되는 각 섹션은 아래에 설명되어 있다.

주소

이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다.

• HostName: 노드의 커널에 의해 알려진 호스트명이다. --hostname-override 파라미터를 통해 치환될 수 있다.
• ExternalIP: 일반적으로 노드의 IP 주소는 외부로 라우트 가능 (클러스터 외부에서 이용 가능) 하다 .
• InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.

컨디션

conditions 필드는 모든 Running 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다.

쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 .status 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다.

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

ready 컨디션의 status가 pod-eviction-timeout (kube-controller-manager에 전달된 인수)보다 더 길게 Unknown 또는 False로 유지되는 경우, 노드 컨트롤러가 해당 노드에 할당된 전체 파드에 대해 API를 이용한 축출 을 트리거한다. 기본 축출 타임아웃 기간은 5분 이다. 노드에 접근이 불가할 때와 같은 경우, API 서버는 노드 상의 kubelet과 통신이 불가하다. API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.

노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. 파드가 Terminating 또는 Unknown 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작 중인 모든 파드 오브젝트가 API 서버로부터 삭제되며 파드가 사용하던 이름을 다시 사용할 수 있게 된다.

노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는 테인트(taints)를 생성한다. 스케줄러는 파드를 노드에 할당할 때 노드의 테인트를 고려한다. 또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 톨러레이션(toleration)을 가질 수 있다.

자세한 내용은 컨디션별 노드 테인트하기를 참조한다.

용량과 할당가능

노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.

용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다. 할당가능 블록은 일반 파드에서 사용할 수 있는 노드의 리소스 양을 나타낸다.

노드에서 컴퓨팅 리소스 예약하는 방법을 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자.

정보

커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체제가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다. 이 정보는 Kubelet이 노드에서 수집하여 쿠버네티스 API로 전송한다.

하트비트

쿠버네티스 노드가 보내는 하트비트는 클러스터가 개별 노드가 가용한지를 판단할 수 있도록 도움을 주고, 장애가 발견된 경우 조치를 할 수 있게한다.

노드에는 두 가지 형태의 하트비트가 있다.

• 노드의 .status에 대한 업데이트
• kube-node-lease 네임스페이스 내의 리스(Lease) 오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다.

노드의 .status에 비하면, 리스는 경량의 리소스이다. 큰 규모의 클러스터에서는 리스를 하트비트에 사용하여 업데이트로 인한 성능 영향을 줄일 수 있다.

kubelet은 노드의 .status 생성과 업데이트 및 관련된 리스의 업데이트를 담당한다.

• kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 .status를 업데이트한다. 노드의 .status 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다.
• kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다. 리스 업데이트는 노드의 .status 업데이트와는 독립적이다. 만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.

노드 컨트롤러

노드 컨트롤러는 노드의 다양한 측면을 관리하는 쿠버네티스 컨트롤 플레인 컴포넌트이다.

노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에 (CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.

두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.

세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는 다음을 담당한다.

• 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 .status 내에 있는 NodeReady 컨디션을 업데이트한다. 이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 ConditionUnknown으로 설정한다.
• 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서 API를 이용한 축출을 트리거한다. 기본적으로, 노드 컨트롤러는 노드를 ConditionUnknown으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다.

노드 컨트롤러는 매 --node-monitor-period 초 마다 각 노드의 상태를 체크한다.

축출 빈도 한계

대부분의 경우, 노드 컨트롤러는 초당 --node-eviction-rate(기본값 0.1)로 축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다.

노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다).

• 상태가 불량한 노드의 비율이 최소 --unhealthy-zone-threshold (기본값 0.55)가 되면 축출 속도가 감소한다.
• 클러스터가 작으면 (즉 --large-cluster-size-threshold 노드 이하면 - 기본값 50) 축출이 중지된다.
• 이외의 경우, 축출 속도는 초당 --secondary-node-eviction-rate(기본값 0.01)로 감소된다.

이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않는 이상, 축출 매커니즘은 영역 별 가용성을 고려하지 않는다.

노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 --node-eviction-rate 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다. 이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.)

또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 NoExecute 테인트 상태의 노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다. 추가로, 노드 컨틀로러는 연결할 수 없거나, 준비되지 않은 노드와 같은 노드 문제에 상응하는 테인트를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.

리소스 용량 추적

노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의 양과 CPU의 수를 추적한다. 노드의 자체 등록은 등록하는 중에 용량을 보고한다. 수동으로 노드를 추가하는 경우 추가할 때 노드의 용량 정보를 설정해야 한다.

쿠버네티스 스케줄러는 노드 상에 모든 노드에 대해 충분한 리소스가 존재하도록 보장한다. 스케줄러는 노드 상에 컨테이너에 대한 요청의 합이 노드 용량보다 더 크지 않도록 체크한다. 요청의 합은 kubelet에서 관리하는 모든 컨테이너를 포함하지만, 컨테이너 런타임에 의해 직접적으로 시작된 컨 테이너는 제외되고 kubelet의 컨트롤 범위 밖에서 실행되는 모든 프로세스도 제외된다.

노드 토폴로지

TopologyManager 기능 게이트(feature gate)를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. 자세한 내용은 노드의 컨트롤 토폴로지 관리 정책을 본다.

그레이스풀(Graceful) 노드 셧다운

kubelet은 노드 시스템 셧다운을 감지하고 노드에서 실행 중인 파드를 종료하려고 시도한다.

Kubelet은 노드가 종료되는 동안 파드가 일반 파드 종료 프로세스를 따르도록 한다.

그레이스풀 노드 셧다운 기능은 systemd inhibitor locks를 사용하여 주어진 기간 동안 노드 종료를 지연시키므로 systemd에 의존한다.

그레이스풀 노드 셧다운은 1.21에서 기본적으로 활성화된 GracefulNodeShutdown 기능 게이트로 제어된다.

기본적으로, 아래 설명된 두 구성 옵션, ShutdownGracePeriod 및 ShutdownGracePeriodCriticalPods 는 모두 0으로 설정되어 있으므로, 그레이스풀 노드 셧다운 기능이 활성화되지 않는다. 기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다.

그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.

1. 노드에서 실행 중인 일반 파드를 종료시킨다.
2. 노드에서 실행 중인 중요(critical) 파드를 종료시킨다.

그레이스풀 노드 셧다운 기능은 두 개의 KubeletConfiguration 옵션으로 구성된다.

• ShutdownGracePeriod:
  • 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 중요 파드의 파드 종료에 필요한 총 유예 기간에 해당한다.
• ShutdownGracePeriodCriticalPods:
  • 노드 종료 중에 중요 파드를 종료하는 데 사용되는 기간을 지정한다. 이 값은 ShutdownGracePeriod 보다 작아야 한다.

예를 들어, ShutdownGracePeriod=30s, ShutdownGracePeriodCriticalPods=10s 인 경우, kubelet은 노드 종료를 30초까지 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 유예 종료에 할당되고, 마지막 10초는 중요 파드의 종료에 할당된다.

Status:         Failed
Reason:         Shutdown
Message:        Node is shutting, evicting pods

스왑(swap) 메모리 관리

쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고 kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다. 1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다.

노드에서 스왑을 활성화하려면, NodeSwap 기능 게이트가 kubelet에서 활성화되어야 하며, 명령줄 플래그 --fail-swap-on 또는 구성 설정에서 failSwapOn가 false로 지정되어야 한다.

사용자는 또한 선택적으로 memorySwap.swapBehavior를 구성할 수 있으며, 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,

memorySwap:
  swapBehavior: LimitedSwap

swapBehavior에 가용한 구성 옵션은 다음과 같다.

• LimitedSwap: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로 제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다.
• UnlimitedSwap: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며, 시스템의 최대치까지 사용 가능하다.

만약 memorySwap 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면, kubelet은 LimitedSwap 설정과 같은 행동을 기본적으로 적용한다.

LimitedSwap 설정에 대한 행동은 노드가 ("cgroups"으로 알려진) 제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다.

• cgroupsv1: 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다. 파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다.
• cgroupsv2: 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다.

테스트를 지원하고 피드벡을 제공하기 위한 정보는 KEP-2400 및 디자인 제안에서 찾을 수 있다.

다음 내용

• 노드를 구성하는 컴포넌트에 대해 알아본다.
• 노드에 대한 API 정의를 읽어본다.
• 아키텍처 디자인 문서의 노드 섹션을 읽어본다.
• 테인트와 톨러레이션을 읽어본다.

3.2.2 - 컨트롤 플레인-노드 간 통신

이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.

노드에서 컨트롤 플레인으로의 통신

쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 인증 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.

특히 익명의 요청 또는 서비스 어카운트 토큰이 허용되는 경우, 하나 이상의 권한 부여 형식을 사용해야 한다.

노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 kubelet TLS 부트스트랩을 참고한다.

API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다. kubernetes 서비스(default 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다.

컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다.

결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.

컨트롤 플레인에서 노드로의 통신

컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.

API 서버에서 kubelet으로의 통신

API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.

• 파드에 대한 로그를 가져온다.
• 실행 중인 파드에 (kubectl을 통해) 연결한다.
• kubelet의 포트-포워딩 기능을 제공한다.

이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 안전하지 않다 .

이 연결을 확인하려면, --kubelet-certificate-authority 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다.

이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 SSH 터널링을 사용한다.

마지막으로, kubelet API를 보호하려면 Kubelet 인증 및/또는 권한 부여를 활성화해야 한다.

API 서버에서 노드, 파드 및 서비스로의 통신

API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 https: 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 현재는 안전하지 않다 .

SSH 터널

쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다. 이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.

SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.

Konnectivity 서비스

SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.

Konnectivity 서비스 태스크에 따라 클러스터에서 Konnectivity 서비스를 설정한다.

3.2.3 - 컨트롤러

로보틱스와 자동화에서 컨트롤 루프 는 시스템 상태를 조절하는 종료되지 않는 루프이다.

컨트롤 루프의 예시: 실내 온도 조절기

사용자는 온도를 설정해서, 사용자가 의도한 상태 를 온도 조절기에 알려준다. 현재 상태 이다. 온도 조절기는 장비를 켜거나 꺼서 현재 상태를 의도한 상태에 가깝게 만든다.

컨트롤러 패턴

컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다. 이 오브젝트 는 의도한 상태를 표현하는 사양 필드를 가지고 있다. 해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 상태에 가깝게 만드는 역할을 한다.

컨트롤러는 스스로 작업을 수행할 수 있다. 보다 일반적으로, 쿠버네티스에서는 컨트롤러가 API 서버 로 유용한 부수적인 효과가 있는 메시지를 발송한다. 그 예시는 아래에서 볼 수 있다.

API 서버를 통한 제어

잡(Job) 컨트롤러는 쿠버네티스 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 상호 작용하며 상태를 관리한다.

잡은 단일 파드 또는 여러 파드를 실행하고, 작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다.

(일단 스케줄되면, 파드 오브젝트는 kubelet 의 의도한 상태 중 일부가 된다.)

잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 노드 집합의 kubelet이 작업을 수행하기에 적합한 수의 파드를 실행하게 한다. 잡 컨트롤러는 어떤 파드 또는 컨테이너를 스스로 실행하지 않는다. 대신, 잡 컨트롤러는 API 서버에 파드를 생성하거나 삭제하도록 지시한다. 컨트롤 플레인의 다른 컴포넌트는 신규 정보 (예약 및 실행해야 하는 새 파드가 있다는 정보)에 대응하여, 결국 해당 작업을 완료시킨다.

새 잡을 생성하고 나면, 의도한 상태는 해당 잡을 완료하는 것이 된다. 잡 컨트롤러는 현재 상태를 의도한 상태에 가깝게 만들며, 사용자가 원하는 잡을 수행하기 위해 파드를 생성해서 잡이 완료에 가까워 지도록 한다.

또한, 컨트롤러는 오브젝트의 설정을 업데이트 한다. 예시: 잡을 위한 작업이 종료된 경우, 잡 컨트롤러는 잡 오브젝트가 Finished 로 표시되도록 업데이트한다.

(이것은 지금 방 온도가 설정한 온도인 것을 표시하기 위해 실내 온도 조절기의 빛을 끄는 것과 약간 비슷하다).

직접 제어

잡과는 대조적으로, 일부 컨트롤러는 클러스터 외부의 것을 변경해야 할 필요가 있다.

예를 들어, 만약 컨트롤 루프를 사용해서 클러스터에 충분한 노드들이 있도록 만드는 경우, 해당 컨트롤러는 필요할 때 새 노드를 설정할 수 있도록 현재 클러스터 외부의 무언가를 필요로 한다.

외부 상태와 상호 작용하는 컨트롤러는 API 서버에서 의도한 상태를 찾은 다음, 외부 시스템과 직접 통신해서 현재 상태를 보다 가깝게 만든다.

(실제로 클러스터의 노드를 수평으로 확장하는 컨트롤러가 있다.)

여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고, 현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다. 다른 컨트롤 루프는 보고된 데이터를 관찰하고 자체 조치를 할 수 있다.

온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가 서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는 쿠버네티스 확장을 통해 IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 및 기타 서비스 등과 간접적으로 연동하여 이를 구현한다.

의도한 상태와 현재 상태

쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인 변화에 대응할 수 있다.

작업이 발생함에 따라 어떤 시점에서든 클러스터가 변경 될 수 있으며 컨트롤 루프가 자동으로 실패를 바로잡는다. 이는 잠재적으로, 클러스터가 안정적인 상태에 도달하지 못하는 것을 의미한다.

클러스터의 컨트롤러가 실행 중이고 유용한 변경을 수행할 수 있는 한, 전체 상태가 안정적인지 아닌지는 중요하지 않다.

디자인

디자인 원리에 따라, 쿠버네티스는 클러스터 상태의 각 특정 측면을 관리하는 많은 컨트롤러를 사용한다. 가장 일반적으로, 특정 컨트롤 루프 (컨트롤러)는 의도한 상태로서 한 종류의 리소스를 사용하고, 의도한 상태로 만들기 위해 다른 종류의 리소스를 관리한다. 예를 들어, 잡 컨트롤러는 잡 오브젝트(새 작업을 발견하기 위해)와 파드 오브젝트(잡을 실행하고, 완료된 시기를 확인하기 위해)를 추적한다. 이 경우 파드는 잡 컨트롤러가 생성하는 반면, 잡은 다른 컨트롤러가 생성한다.

컨트롤 루프들로 연결 구성된 하나의 모놀리식(monolithic) 집합보다, 간단한 컨트롤러를 여러 개 사용하는 것이 유용하다. 컨트롤러는 실패할 수 있으므로, 쿠버네티스는 이를 허용하도록 디자인되었다.

컨트롤러를 실행하는 방법

쿠버네티스에는 kube-controller-manager 내부에서 실행되는 내장된 컨트롤러 집합이 있다. 이 내장 컨트롤러는 중요한 핵심 동작을 제공한다.

디플로이먼트 컨트롤러와 잡 컨트롤러는 쿠버네티스의 자체("내장" 컨트롤러)로 제공되는 컨트롤러 예시이다. 쿠버네티스를 사용하면 복원력이 뛰어난 컨트롤 플레인을 실행할 수 있으므로, 어떤 내장 컨트롤러가 실패하더라도 다른 컨트롤 플레인의 일부가 작업을 이어서 수행한다.

컨트롤 플레인의 외부에서 실행하는 컨트롤러를 찾아서 쿠버네티스를 확장할 수 있다. 또는, 원하는 경우 새 컨트롤러를 직접 작성할 수 있다. 소유하고 있는 컨트롤러를 파드 집합으로서 실행하거나, 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에 따라 달라진다.

다음 내용

• 쿠버네티스 컨트롤 플레인에 대해 읽기
• 쿠버네티스 오브젝트의 몇 가지 기본 사항을 알아보자.
• 쿠버네티스 API에 대해 더 배워 보자.
• 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 확장 패턴을 본다.

3.2.4 - 클라우드 컨트롤러 매니저

클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다. 쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를 신뢰한다.

클라우드 컨트롤러 매니저는 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다.

쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을 분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가 주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다.

클라우드 컨트롤러 매니저는 다양한 클라우드 공급자가 자신의 플랫폼에 쿠버네티스를 통합할 수 있도록 하는 플러그인 메커니즘을 사용해서 구성된다.

디자인

클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로, 파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일 프로세스에 여러 컨트롤러를 구현한다.

클라우드 컨트롤러 매니저의 기능

클라우드 컨틀롤러 매니저의 내부 컨트롤러에는 다음 컨트롤러들이 포함된다.

노드 컨트롤러

노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 노드 오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다.

1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다.
2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다.
3. 노드의 호스트 이름과 네트워크 주소를 가져온다.
4. 노드의 상태를 확인한다. 노드가 응답하지 않는 경우, 이 컨트롤러는 사용자가 이용하는 클라우드 공급자의 API를 통해 서버가 비활성화됨 / 삭제됨 / 종료됨인지 확인한다. 노드가 클라우드에서 삭제된 경우, 컨트롤러는 사용자의 쿠버네티스 클러스터에서 노드 오브젝트를 삭제한다.

일부 클라우드 공급자의 구현에서는 이를 노드 컨트롤러와 별도의 노드 라이프사이클 컨트롤러로 분리한다.

라우트 컨트롤러

라우트 컨트롤러는 사용자의 쿠버네티스 클러스터의 다른 노드에 있는 각각의 컨테이너가 서로 통신할 수 있도록 클라우드에서 라우트를 적절히 구성해야 한다.

클라우드 공급자에 따라 라우트 컨트롤러는 파드 네트워크 IP 주소 블록을 할당할 수도 있다.

서비스 컨트롤러

서비스 는 관리형 로드 밸런서, IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같은 클라우드 인프라스트럭처 컴포넌트와 통합된다. 서비스 컨트롤러는 사용자의 클라우드 공급자 API와 상호 작용해서 필요한 서비스 리소스를 선언할 때 로드 밸런서와 기타 인프라스트럭처 컴포넌트를 설정한다.

인가

이 섹션에서는 클라우드 컨트롤러 매니저가 작업을 수행하기 위해 다양한 API 오브젝트에 필요한 접근 권한을 세분화한다.

노드 컨트롤러

노드 컨트롤러는 노드 오브젝트에서만 작동한다. 노드 오브젝트를 읽고, 수정하려면 전체 접근 권한이 필요하다.

v1/Node:

• Get
• List
• Create
• Update
• Patch
• Watch
• Delete

라우트 컨트롤러

라우트 컨트롤러가 노드 오브젝트의 생성을 수신하고 적절하게 라우트를 구성한다. 노드 오브젝트에 대한 접근 권한이 필요하다.

v1/Node:

• Get

서비스 컨트롤러

서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다.

서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다.

서비스에 대한 엔드포인트 리소스를 설정하려면 생성, 목록, 가져오기, 감시 그리고 업데이트에 대한 접근 권한이 필요하다.

v1/Service:

• List
• Get
• Watch
• Patch
• Update

그 외의 것들

클라우드 컨트롤러 매니저의 핵심 구현을 위해 이벤트 오브젝트를 생성하고, 안전한 작동을 보장하기 위해 서비스어카운트(ServiceAccounts)를 생성해야 한다.

v1/Event:

• Create
• Patch
• Update

v1/ServiceAccount:

• Create

클라우드 컨트롤러 매니저의 RBAC 클러스터롤(ClusterRole)은 다음과 같다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - get
  - list
  - watch
  - update

다음 내용

클라우드 컨트롤러 매니저 관리에는 클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다.

클라우드 컨트롤러 매니저를 사용하기 위해 HA 컨트롤 플레인을 업그레이드하려면, 클라우드 컨트롤러 매니저를 사용하기 위해 복제된 컨트롤 플레인 마이그레이션 하기를 참고한다.

자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가?

클라우드 컨트롤러 매니저는 Go 인터페이스를 사용함으로써, 어떠한 클라우드에 대한 구현체(implementation)라도 플러그인 될 수 있도록 한다. 구체적으로는, kubernetes/cloud-provider의 cloud.go에 정의된 CloudProvider 인터페이스를 사용한다.

이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 CloudProvider 인터페이스를 구현한다.

플러그인 개발에 대한 자세한 내용은 클라우드 컨트롤러 매니저 개발하기를 참조한다.

3.3 - 컨테이너

실행하는 각 컨테이너는 반복 가능하다. 의존성이 포함된 표준화는 어디에서 실행하던지 동일한 동작을 얻는다는 것을 의미한다.

컨테이너는 기본 호스트 인프라에서 애플리케이션을 분리한다. 따라서 다양한 클라우드 또는 OS 환경에서 보다 쉽게 ​​배포할 수 있다.

컨테이너 이미지

컨테이너 이미지는 애플리케이션을 실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어 있는(ready-to-run) 소프트웨어 패키지이다. 여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리, 그리고 모든 필수 설정에 대한 기본값이 포함된다.

설계 상, 컨테이너는 변경할 수 없다. 이미 실행 중인 컨테이너의 코드를 변경할 수 없다. 컨테이너화된 애플리케이션이 있고 변경하려는 경우, 변경 사항이 포함된 새 이미지를 빌드한 다음, 업데이트된 이미지에서 시작하도록 컨테이너를 다시 생성해야 한다.

컨테이너 런타임

컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다.

쿠버네티스는 여러 컨테이너 런타임을 지원한다. 도커(Docker), containerd, CRI-O 그리고 Kubernetes CRI (컨테이너 런타임 인터페이스)를 구현한 모든 소프트웨어.

다음 내용

• 컨테이너 이미지에 대해 읽어보기
• 파드에 대해 읽어보기

3.3.1 - 이미지

컨테이너 이미지는 애플리케이션과 모든 소프트웨어 의존성을 캡슐화하는 바이너리 데이터를 나타낸다. 컨테이너 이미지는 독립적으로 실행할 수 있고 런타임 환경에 대해 잘 정의된 가정을 만드는 실행 가능한 소프트웨어 번들이다.

일반적으로 파드에서 참조하기 전에 애플리케이션의 컨테이너 이미지를 생성해서 레지스트리로 푸시한다.

이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.

이미지 이름

컨테이너 이미지는 일반적으로 pause, example/mycontainer 또는 kube-apiserver 와 같은 이름을 부여한다. 이미지는 또한 레지스트리 호스트 이름을 포함할 수 있다. 예를 들면, fictional.registry.example/imagename 과 같다. 그리고 포트 번호도 포함할 수 있다. 예를 들면, fictional.registry.example:10443/imagename 과 같다.

레지스트리 호스트 이름을 지정하지 않으면, 쿠버네티스는 도커 퍼블릭 레지스트리를 의미한다고 가정한다.

이미지 이름 부분 다음에 tag 를 추가할 수 있다(docker 와 podman 등의 명령과 함께 사용). 태그를 사용하면 동일한 시리즈 이미지의 다른 버전을 식별할 수 있다.

이미지 태그는 소문자와 대문자, 숫자, 밑줄(_), 마침표(.) 및 대시(-)로 구성된다. 이미지 태그 안에서 구분 문자(_, - 그리고 .)를 배치할 수 있는 위치에 대한 추가 규칙이 있다. 태그를 지정하지 않으면, 쿠버네티스는 태그 latest 를 의미한다고 가정한다.

이미지 업데이트

디플로이먼트, 스테이트풀셋, 파드 또는 파드 템플릿은 포함하는 다른 오브젝트를 처음 만들 때 특별히 명시하지 않은 경우 기본적으로 해당 파드에 있는 모든 컨테이너의 풀(pull) 정책은 IfNotPresent로 설정된다. 이 정책은 kubelet이 이미 존재하는 이미지에 대한 풀을 생략하게 한다.

이미지 풀(pull) 정책

컨테이너에 대한 imagePullPolicy와 이미지의 태그는 kubelet이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다.

다음은 imagePullPolicy에 설정할 수 있는 값의 목록과 효과이다.

IfNotPresent

이미지가 로컬에 없는 경우에만 내려받는다.

Always

kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 다이제스트가 있는지 질의한다. 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 컨테이너를 기동할 때 사용한다.

Never

kubelet은 이미지를 가져오려고 시도하지 않는다. 이미지가 어쨌든 이미 로컬에 존재하는 경우, kubelet은 컨테이너 기동을 시도한다. 이외의 경우 기동은 실패한다. 보다 자세한 내용은 미리 내려받은 이미지를 참조한다.

이미지 제공자에 앞서 깔린 캐시의 의미 체계는 레지스트리에 안정적으로 접근할 수 있는 한, imagePullPolicy: Always인 경우 조차도 효율적이다. 컨테이너 런타임은 노드에 이미 존재하는 이미지 레이어를 알고 다시 내려받지 않는다.

파드가 항상 컨테이너 이미지의 같은 버전을 사용하는 것을 확실히 하려면, 이미지의 다이제스트를 명기할 수 있다. <image-name>:<tag>를 <image-name>@<digest>로 교체한다. (예를 들어, image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2).

이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다.

파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 서드-파티 어드미션 컨트롤러가 있다. 이는 레지스트리에서 태그가 변경되는 일이 발생해도 구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다.

기본 이미지 풀 정책

사용자(또는 컨트롤러)가 신규 파드를 API 서버에 요청할 때, 특정 조건에 부합하면 클러스터가 imagePullPolicy 필드를 설정한다.

• imagePullPolicy 필드를 생략하고 컨테이너 이미지의 태그가 :latest인 경우, imagePullPolicy는 자동으로 Always로 설정된다.
• imagePullPolicy 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, imagePullPolicy는 자동으로 Always로 설정된다.
• imagePullPolicy 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 :latest가 아니면, imagePullPolicy는 자동으로 IfNotPresent로 설정된다.

이미지 풀 강제

이미지를 내려받도록 강제하려면, 다음 중 한가지 방법을 사용한다.

• 컨테이너의 imagePullPolicy를 Always로 설정한다.
• imagePullPolicy를 생략하고 사용할 이미지 태그로 :latest를 사용한다. 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 Always로 설정한다.
• imagePullPolicy와 사용할 이미지의 태그를 생략한다. 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 Always로 설정한다.
• AlwaysPullImages 어드미션 컨트롤러를 활성화 한다.

이미지풀백오프(ImagePullBackOff)

kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, ImagePullBackOff로 인해 컨테이너가 Waiting 상태에 있을 수 있다.

ImagePullBackOff라는 상태는 (이미지 이름이 잘못됨, 또는 imagePullSecret 없이 비공개 레지스트리에서 풀링 시도 등의 이유로) 쿠버네티스가 컨테이너 이미지를 가져올 수 없기 때문에 컨테이너를 실행할 수 없음을 의미한다. BackOff라는 단어는 쿠버네티스가 백오프 딜레이를 증가시키면서 이미지 풀링을 계속 시도할 것임을 나타낸다.

쿠버네티스는 시간 간격을 늘려가면서 시도를 계속하며, 시간 간격의 상한은 쿠버네티스 코드에 300초(5분)로 정해져 있다.

이미지 인덱스가 있는 다중 아키텍처 이미지

바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 이미지 인덱스를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 이미지 매니페스트를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, pause, example/mycontainer, kube-apiserver)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다.

쿠버네티스 자체는 일반적으로 -$(ARCH) 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 pause 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 pause-amd64 라고 하는 이미지를 생성한다.

프라이빗 레지스트리 사용

프라이빗 레지스트리는 해당 레지스트리에서 이미지를 읽을 수 있는 키를 요구할 것이다. 자격 증명(credential)은 여러 가지 방법으로 제공될 수 있다.

• 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
  • 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
  • 클러스터 관리자에 의한 노드 구성 필요
• 미리 내려받은(pre-pulled) 이미지
  • 모든 파드는 노드에 캐시된 모든 이미지를 사용 가능
  • 셋업을 위해서는 모든 노드에 대해서 root 접근이 필요
• 파드에 ImagePullSecrets을 명시
  • 자신의 키를 제공하는 파드만 프라이빗 레지스트리에 접근 가능
• 공급 업체별 또는 로컬 확장
  • 사용자 정의 노드 구성을 사용하는 경우, 사용자(또는 클라우드 제공자)가 컨테이너 레지스트리에 대한 노드 인증 메커니즘을 구현할 수 있다.

이들 옵션은 아래에서 더 자세히 설명한다.

프라이빗 레지스트리에 인증하도록 노드 구성

노드에서 도커를 실행하는 경우, 프라이빗 컨테이너 레지스트리를 인증하도록 도커 컨테이너 런타임을 구성할 수 있다.

이 방법은 노드 구성을 제어할 수 있는 경우에 적합하다.

도커는 프라이빗 레지스트리를 위한 키를 $HOME/.dockercfg 또는 $HOME/.docker/config.json 파일에 저장한다. 만약 동일한 파일을 아래의 검색 경로 리스트에 넣으면, kubelet은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.

• {--root-dir:-/var/lib/kubelet}/config.json
• {cwd of kubelet}/config.json
• ${HOME}/.docker/config.json
• /.docker/config.json
• {--root-dir:-/var/lib/kubelet}/.dockercfg
• {cwd of kubelet}/.dockercfg
• ${HOME}/.dockercfg
• /.dockercfg

프라이빗 레지스트리를 사용도록 사용자의 노드를 구성하기 위해서 권장되는 단계는 다음과 같다. 이 예제의 경우, 사용자의 데스크탑/랩탑에서 아래 내용을 실행한다.

1. 사용하고 싶은 각 자격 증명 세트에 대해서 docker login [서버]를 실행한다. 이것은 여러분 PC의 $HOME/.docker/config.json를 업데이트한다.
2. 편집기에서 $HOME/.docker/config.json를 보고 사용하고 싶은 자격 증명만 포함하고 있는지 확인한다.
3. 노드의 리스트를 구한다. 예를 들면 다음과 같다.
   • 이름을 원하는 경우: nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )
   • IP를 원하는 경우: nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )
4. 로컬의 .docker/config.json를 위의 검색 경로 리스트 중 하나에 복사한다.
   • 이를 테스트하기 위한 예: for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done

프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF

pod/private-image-test-1 created

만약 모든 것이 잘 작동한다면, 잠시 후에, 다음을 실행할 수 있다.

kubectl logs private-image-test-1

그리고 커맨드 출력을 본다.

SUCCESS

명령이 실패한 것으로 의심되는 경우 다음을 실행할 수 있다.

kubectl describe pods/private-image-test-1 | grep 'Failed'

실패하는 케이스에는 출력이 다음과 유사하다.

  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found

클러스터의 모든 노드가 반드시 동일한 .docker/config.json를 가져야 한다. 그렇지 않으면, 파드가 일부 노드에서만 실행되고 다른 노드에서는 실패할 것이다. 예를 들어, 노드 오토스케일링을 사용한다면, 각 인스턴스 템플릿은 .docker/config.json을 포함하거나 그것을 포함한 드라이브를 마운트해야 한다.

프라이빗 레지스트리 키가 .docker/config.json에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다.

미리 내려받은 이미지

기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 한다. 그러나, 컨테이너의 imagePullPolicy 속성이 IfNotPresent 또는 Never으로 설정되어 있다면, 로컬 이미지가 사용된다(우선적으로 또는 배타적으로).

레지스트리 인증의 대안으로 미리 풀 된 이미지에 의존하고 싶다면, 클러스터의 모든 노드가 동일한 미리 내려받은 이미지를 가지고 있는지 확인해야 한다.

이것은 특정 이미지를 속도를 위해 미리 로드하거나 프라이빗 레지스트리에 대한 인증의 대안으로 사용될 수 있다.

모든 파드는 미리 내려받은 이미지에 대해 읽기 접근 권한을 가질 것이다.

파드에 ImagePullSecrets 명시

쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다.

도커 구성으로 시크릿 생성

대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.

kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

만약 도커 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, 자격 증명 파일을 쿠버네티스 시크릿으로 가져올 수 있다. 기존 도커 자격 증명으로 시크릿 생성에서 관련 방법을 설명하고 있다.

kubectl create secret docker-registry는 하나의 프라이빗 레지스트리에서만 작동하는 시크릿을 생성하기 때문에, 여러 프라이빗 컨테이너 레지스트리를 사용하는 경우 특히 유용하다.

파드의 imagePullSecrets 참조

이제, imagePullSecrets 섹션을 파드의 정의에 추가함으로써 해당 시크릿을 참조하는 파드를 생성할 수 있다.

예를 들면 다음과 같다.

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey
EOF

cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

이것은 프라이빗 레지스트리를 사용하는 각 파드에 대해서 수행될 필요가 있다.

그러나, 이 필드의 셋팅은 서비스 어카운트 리소스에 imagePullSecrets을 셋팅하여 자동화할 수 있다.

자세한 지침을 위해서는 서비스 어카운트에 ImagePullSecrets 추가를 확인한다.

이것은 노드 당 .docker/config.json와 함께 사용할 수 있다. 자격 증명은 병합될 것이다.

유스케이스

프라이빗 레지스트리를 구성하기 위한 많은 솔루션이 있다. 다음은 여러 가지 일반적인 유스케이스와 제안된 솔루션이다.

1. 비소유 이미지(예를 들어, 오픈소스)만 실행하는 클러스터의 경우. 이미지를 숨길 필요가 없다.
   • 도커 허브의 퍼블릭 이미지를 사용한다.
     • 설정이 필요 없다.
     • 일부 클라우드 제공자는 퍼블릭 이미지를 자동으로 캐시하거나 미러링하므로, 가용성이 향상되고 이미지를 가져오는 시간이 줄어든다.
2. 모든 클러스터 사용자에게는 보이지만, 회사 외부에는 숨겨야하는 일부 독점 이미지를 실행하는 클러스터의 경우.
   • 호스트 된 프라이빗 도커 레지스트리를 사용한다.
     • 그것은 도커 허브에 호스트 되어 있거나, 다른 곳에 되어 있을 것이다.
     • 위에 설명된 바와 같이 수동으로 .docker/config.json을 구성한다.
   • 또는, 방화벽 뒤에서 읽기 접근 권한을 가진 내부 프라이빗 레지스트리를 실행한다.
     • 쿠버네티스 구성은 필요 없다.
   • 이미지 접근을 제어하는 ​​호스팅된 컨테이너 이미지 레지스트리 서비스를 사용한다.
     • 그것은 수동 노드 구성에 비해서 클러스터 오토스케일링과 더 잘 동작할 것이다.
   • 또는, 노드의 구성 변경이 불편한 클러스터에서는, imagePullSecrets를 사용한다.
3. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.
   • AlwaysPullImages 어드미션 컨트롤러가 활성화되어 있는지 확인한다. 그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
   • 민감한 데이터는 이미지 안에 포장하는 대신, "시크릿" 리소스로 이동한다.
4. 멀티-테넌트 클러스터에서 각 테넌트가 자신의 프라이빗 레지스트리를 필요로 하는 경우.
   • AlwaysPullImages 어드미션 컨트롤러가 활성화되어 있는지 확인한다. 그렇지 않으면, 모든 파드가 잠재적으로 모든 이미지에 접근 권한을 가진다.
   • 인가가 요구되도록 프라이빗 레지스트리를 실행한다.
   • 각 테넌트에 대한 레지스트리 자격 증명을 생성하고, 시크릿에 넣고, 각 테넌트 네임스페이스에 시크릿을 채운다.
   • 테넌트는 해당 시크릿을 각 네임스페이스의 imagePullSecrets에 추가한다.

다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든 imagePullSecrets 파일을 하나의 가상 .docker/config.json 파일로 병합한다.

다음 내용

• OCI 이미지 매니페스트 명세 읽어보기.
• 컨테이너 이미지 가비지 수집(garbage collection)에 대해 배우기.

3.3.2 - 런타임클래스(RuntimeClass)

이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.

런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 구성은 파드의 컨테이너를 실행하는 데 사용된다.

동기

서로 다른 파드간에 런타임클래스를 설정하여 성능과 보안의 균형을 유지할 수 있다. 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다. 그러면 몇가지 추가적인 오버헤드는 있지만 대체 런타임을 추가 분리하는 유익이 있다.

또한 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다.

셋업

1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서).
2. 상응하는 런타임클래스 리소스 생성.

1. CRI 구현을 노드에 설정

런타임클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. 사용자의 CRI 구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다(아래).

해당 설정은 상응하는 handler 이름을 가지며, 이는 런타임클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + -와 .문자)을 가져야 한다.

2. 상응하는 런타임클래스 리소스 생성

1단계에서 셋업 한 설정은 연관된 handler 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 "" 핸들러)에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다.

현재 런타임클래스 리소스는 런타임클래스 이름(metadata.name)과 런타임 핸들러 (handler)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.

apiVersion: node.k8s.io/v1  # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음
kind: RuntimeClass
metadata:
  name: myclass  # 런타임클래스는 해당 이름을 통해서 참조됨
  # 런타임클래스는 네임스페이스가 없는 리소스임
handler: myconfiguration  # 상응하는 CRI 설정의 이름임

런타임클래스 오브젝트의 이름은 유효한 DNS 레이블 이름어이야 한다.

사용

클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 runtimeClassName를 명시한다. 예를 들면 다음과 같다.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

이것은 kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 Failed 터미널 단계로 들어간다. 에러 메시지에 상응하는 이벤트를 확인한다.

만약 명시된 runtimeClassName가 없다면, 기본 런타임 핸들러가 사용되며, 런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다.

CRI 구성

CRI 런타임 설치에 대한 자세한 내용은 CRI 설치를 확인한다.

dockershim

dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 docker로 고정한다. dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.

containerd

런타임 핸들러는 containerd의 구성 파일인 /etc/containerd/config.toml 통해 설정한다. 유효한 핸들러는 runtimes 단락 아래에서 설정한다.

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

더 자세한 containerd의 구성 문서를 살펴본다. https://github.com/containerd/cri/blob/master/docs/config.md

CRI-O

런타임 핸들러는 CRI-O의 구성파일인 /etc/crio/crio.conf을 통해 설정한다. crio.runtime 테이블 아래에 유효한 핸들러를 설정한다.

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

더 자세한 것은 CRI-O의 설정 문서를 본다.

스케줄

RuntimeClass에 scheduling 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다. scheduling이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.

파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 runtimeClass.scheduling.nodeSelector 필드에서 선택되는 공통 레이블을 가져야한다. 런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로 각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다.

지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면, tolerations를 런타임클래스에 추가할 수 있다. nodeSelector를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다.

노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 노드에 파드 할당을 참고한다.

파드 오버헤드

파드 실행과 연관되는 오버헤드 리소스를 지정할 수 있다. 오버헤드를 선언하면 클러스터(스케줄러 포함)가 파드와 리소스에 대한 결정을 내릴 때 처리를 할 수 있다. PodOverhead를 사용하려면, PodOverhead 기능 게이트 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.)

파드 오버헤드는 런타임 클래스에서 overhead 필드를 통해 정의된다. 이 필드를 사용하면, 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다.

다음 내용

• 런타임클래스 설계
• 런타임클래스 스케줄링 설계
• 파드 오버헤드 개념에 대해 읽기
• 파드 오버헤드 기능 설계

3.3.3 - 컨테이너 환경 변수

이 페이지는 컨테이너 환경에서 컨테이너에 가용한 리소스에 대해 설명한다.

컨테이너 환경

쿠버네티스 컨테이너 환경은 컨테이너에 몇 가지 중요한 리소스를 제공한다.

• 하나의 이미지와 하나 이상의 볼륨이 결합된 파일 시스템.
• 컨테이너 자신에 대한 정보.
• 클러스터 내의 다른 오브젝트에 대한 정보.

컨테이너 정보

컨테이너의 호스트네임 은 컨테이너가 동작 중인 파드의 이름과 같다. 그것은 hostname 커맨드 또는 libc의 gethostname 함수 호출을 통해서 구할 수 있다.

파드 이름과 네임스페이스는 다운워드(Downward) API를 통해 환경 변수로 구할 수 있다.

Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로, 파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.

클러스터 정보

컨테이너가 생성될 때 실행 중이던 모든 서비스의 목록은 환경 변수로 해당 컨테이너에서 사용할 수 있다. 이 목록은 새로운 컨테이너의 파드 및 쿠버네티스 컨트롤 플레인 서비스와 동일한 네임스페이스 내에 있는 서비스로 한정된다. 이러한 환경 변수는 Docker 링크 구문과 일치한다.

bar 라는 이름의 컨테이너에 매핑되는 foo 라는 이름의 서비스에 대해서는, 다음의 형태로 변수가 정의된다.

FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>

서비스에 지정된 IP 주소가 있고 DNS 애드온이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.

다음 내용

• 컨테이너 라이프사이클 훅(hooks)에 대해 더 배워 보기.
• 컨테이너 라이프사이클 이벤트에 핸들러 부착 실제 경험 얻기.

3.3.4 - 컨테이너 라이프사이클 훅(Hook)

이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서 컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다.

개요

Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게, 쿠버네티스도 컨테이너에 라이프사이클 훅을 제공한다. 훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는 라이프사이클 훅이 실행될 때 핸들러에 구현된 코드를 실행할 수 있게 한다.

컨테이너 훅

컨테이너에 노출되는 훅은 두 가지가 있다.

PostStart

이 훅은 컨테이너가 생성된 직후에 실행된다. 그러나, 훅이 컨테이너 엔트리포인트에 앞서서 실행된다는 보장은 없다. 파라미터는 핸들러에 전달되지 않는다.

PreStop

이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 PreStop 훅 요청이 실패하며, 훅은 컨테이너를 중지하기 위한 TERM 신호가 보내지기 이전에 완료되어야 한다. 파드의 그레이스 종료 기간(termination grace period)의 초읽기는 PreStop 훅이 실행되기 전에 시작되어, 핸들러의 결과에 상관없이 컨테이너가 파드의 그레이스 종료 기간 내에 결국 종료되도록 한다. 어떠한 파라미터도 핸들러에게 전달되지 않는다.

종료 동작에 더 자세한 대한 설명은 파드의 종료에서 찾을 수 있다.

훅 핸들러 구현

컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다. 구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.

• Exec - 컨테이너의 cgroups와 네임스페이스 안에서, pre-stop.sh와 같은, 특정 커맨드를 실행. 커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
• HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.

훅 핸들러 실행

컨테이너 라이프사이클 관리 훅이 호출되면, 쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고, httpGet 와 tcpSocket 은 kubelet 프로세스에 의해 실행되고, exec 은 컨테이너에서 실행된다.

훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다. 이것은 PostStart 훅에 대해서, 훅이 컨테이너 엔트리포인트와는 비동기적으로 동작함을 의미한다. 그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면, 컨테이너는 running 상태에 이르지 못한다.

PreStop 훅은 컨테이너 중지 신호에서 비동기적으로 실행되지 않는다. 훅은 TERM 신호를 보내기 전에 실행을 완료해야 한다. 실행 중에 PreStop 훅이 중단되면, 파드의 단계는 Terminating 이며 terminationGracePeriodSeconds 가 만료된 후 파드가 종료될 때까지 남아 있다. 이 유예 기간은 PreStop 훅이 실행되고 컨테이너가 정상적으로 중지되는 데 걸리는 총 시간에 적용된다. 예를 들어, terminationGracePeriodSeconds 가 60이고, 훅이 완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후 정상적으로 중지하는 데 10초가 걸리면, terminationGracePeriodSeconds 이후 컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데 걸리는 총 시간(55+10)보다 적다.

만약 PostStart 또는 PreStop 훅이 실패하면, 그것은 컨테이너를 종료시킨다.

사용자는 훅 핸들러를 가능한 한 가볍게 만들어야 한다. 그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이, 오래 동작하는 커맨드가 의미 있는 경우도 있다.

훅 전달 보장

훅 전달은 한 번 이상 으로 의도되어 있는데, 이는 PostStart 또는 PreStop와 같은 특정 이벤트에 대해서, 훅이 여러 번 호출될 수 있다는 것을 의미한다. 이것을 올바르게 처리하는 것은 훅의 구현에 달려 있다.

일반적으로, 전달은 단 한 번만 이루어진다. 예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도, 재전송을 시도하지 않는다. 그러나, 드문 경우로, 이중 전달이 발생할 수 있다. 예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면, Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.

디버깅 훅 핸들러

훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다. 만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다. PostStart의 경우, 이것은 FailedPostStartHook 이벤트이며, PreStop의 경우, 이것은 FailedPreStopHook 이벤트이다. 이 이벤트는 kubectl describe pod <파드_이름>를 실행하면 볼 수 있다. 다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.

Events:
  FirstSeen  LastSeen  Count  From                                                   SubObjectPath          Type      Reason               Message
  ---------  --------  -----  ----                                                   -------------          --------  ------               -------
  1m         1m        1      {default-scheduler }                                                          Normal    Scheduled            Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulling              pulling image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Created              Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulled               Successfully pulled image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Started              Started container with docker id 5c6a256a2567
  38s        38s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
  37s        37s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
  38s        37s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                         Warning   FailedSync           Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
  1m         22s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Warning   FailedPostStartHook

다음 내용

• 컨테이너 환경에 대해 더 배우기.
• 컨테이너 라이프사이클 이벤트에 핸들러 부착 실습 경험하기.

3.4 - 워크로드

워크로드는 쿠버네티스에서 구동되는 애플리케이션이다. 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행한다. 쿠버네티스에서 Pod 는 클러스터에서 실행 중인 컨테이너 집합을 나타낸다.

쿠버네티스 파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고 나서 해당 파드가 동작 중인 노드에 심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 Pod 를 새로 생성해야 한다.

그러나, 작업이 훨씬 쉽도록, 각 Pod 를 직접 관리할 필요는 없도록 만들었다. 대신, 사용자를 대신하여 파드 집합을 관리하는 워크로드 리소스 를 사용할 수 있다. 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 컨트롤러를 구성한다.

쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다.

• Deployment 및 ReplicaSet (레거시 리소스 레플리케이션컨트롤러(ReplicationController)를 대체). Deployment 는 Deployment 의 모든 Pod 가 필요 시 교체 또는 상호 교체 가능한 경우, 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다.
• StatefulSet는 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가 데이터를 지속적으로 기록하는 경우, 사용자는 Pod 와 PersistentVolume을 연계하는 StatefulSet 을 실행할 수 있다. 전체적인 회복력 향상을 위해서, StatefulSet 의 Pods 에서 동작 중인 코드는 동일한 StatefulSet 의 다른 Pods 로 데이터를 복제할 수 있다.
• DaemonSet은 노드-로컬 기능(node-local facilities)을 제공하는 Pods 를 정의한다. 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다. 예를 들면, 네트워킹 지원 도구 또는 add-on 등이 있다. DaemonSet 의 명세에 맞는 노드를 클러스터에 추가할 때마다, 컨트롤 플레인은 해당 신규 노드에 DaemonSet 을 위한 Pod 를 스케줄한다.
• Job 및 CronJob은 실행 완료 후 중단되는 작업을 정의한다. CronJobs 이 스케줄에 따라 반복되는 반면, 잡은 단 한 번의 작업을 나타낸다.

더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드 리소스도 찾을 수 있다. 커스텀 리소스 데피니션을 사용하면, 쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를 추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 Pods 의 그룹을 실행하되 모든 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은), 사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다.

다음 내용

각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.

• Deployment 를 사용하여 스테이트리스(stateless) 애플리케이션 실행
• 스테이트풀(stateful) 애플리케이션을 단일 인스턴스 또는 복제된 세트로 실행
• CronJob 을 사용하여 자동화된 작업 실행

코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는, 구성을 참고하길 바란다.

다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는 두 가지 개념이다.

• 가비지(Garbage) 수집은 소유하는 리소스 가 제거된 후 클러스터에서 오브젝트를 정리한다.
• time-to-live after finished 컨트롤러는 잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다.

일단 애플리케이션이 실행되면, 인터넷에서 서비스로 사용하거나, 웹 애플리케이션의 경우에만 인그레스(Ingress)를 이용하여 사용할 수 있다.

3.4.1 - 파드

파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.

파드 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의 컨테이너의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄되며, 공유 콘텍스트에서 실행된다. 파드는 애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너가 포함된다. 클라우드가 아닌 콘텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.

애플리케이션 컨테이너와 마찬가지로, 파드에는 파드 시작 중에 실행되는 초기화 컨테이너가 포함될 수 있다. 클러스터가 제공하는 경우, 디버깅을 위해 임시 컨테이너를 삽입할 수도 있다.

파드란 무엇인가?

파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들이다. 파드의 콘텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용된다.

도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 도커 컨테이너 그룹과 비슷하다.

파드의 사용

다음은 nginx:1.14.2 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다.

pods/simple-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

위에서 설명한 파드를 생성하려면, 다음 명령을 실행한다.

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

일반적으로 파드는 직접 생성하지는 않으며, 대신 워크로드 리소스를 사용하여 생성한다. 파드 작업 섹션에서 파드와 워크로드 리소스의 관계에 대한 더 많은 정보를 확인한다.

Workload resources for managing pods

일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, 디플로이먼트(Deployment) 또는 잡(Job)과 같은 워크로드 리소스를 사용하여 생성한다. 파드가 상태를 추적해야 한다면, 스테이트풀셋(StatefulSet) 리소스를 고려한다.

쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용된다.

• 단일 컨테이너를 실행하는 파드. "파드 당 하나의 컨테이너" 모델은 가장 일반적인 쿠버네티스 유스케이스이다. 이 경우, 파드를 단일 컨테이너를 둘러싼 래퍼(wrapper)로 생각할 수 있다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 파드를 관리한다.

• 함께 작동해야 하는 여러 컨테이너를 실행하는 파드. 파드는 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있다. 이런 함께 배치된 컨테이너는 하나의 결합된 서비스 단위를 형성한다. 예를 들어, 하나의 컨테이너는 공유 볼륨에 저장된 데이터를 퍼블릭에 제공하는 반면, 별도의 사이드카 컨테이너는 해당 파일을 새로 고치거나 업데이트한다. 파드는 이러한 컨테이너, 스토리지 리소스, 임시 네트워크 ID를 단일 단위로 함께 래핑한다.

  참고: 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은 비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된 특정 인스턴스에서만 사용해야 한다.

각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것이다. 더 많은 인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을 수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 한다. 쿠버네티스에서는 이를 일반적으로 레플리케이션 이라고 한다. 복제된 파드는 일반적으로 워크로드 리소스와 해당 컨트롤러에 의해 그룹으로 생성되고 관리된다.

쿠버네티스가 워크로드 리소스와 해당 컨트롤러를 사용하여 애플리케이션 스케일링과 자동 복구를 구현하는 방법에 대한 자세한 내용은 파드와 컨트롤러를 참고한다.

파드가 여러 컨테이너를 관리하는 방법

파드는 응집력있는 서비스 단위를 형성하는 여러 협력 프로세스(컨테이너)를 지원하도록 설계되었다. 파드의 컨테이너는 클러스터의 동일한 물리 또는 가상 머신에서 자동으로 같은 위치에 배치되고 함께 스케줄된다. 컨테이너는 리소스와 의존성을 공유하고, 서로 통신하고, 종료 시기와 방법을 조정할 수 있다.

예를 들어, 다음 다이어그램에서와 같이 공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는 별도의 "사이드카" 컨테이너가 있을 수 있다.

일부 파드에는 앱 컨테이너 뿐만 아니라 초기화 컨테이너를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.

파드는 기본적으로 파드에 속한 컨테이너에 네트워킹과 스토리지라는 두 가지 종류의 공유 ​​리소스를 제공한다.

파드 작업

사용자가 쿠버네티스에서 직접 개별 파드를 만드는 경우는 거의 없다. 싱글톤 파드도 마찬가지이다. 이는 파드가 상대적으로 일시적인, 일회용 엔티티로 설계되었기 때문이다. 파드가 생성될 때(사용자가 직접 또는 컨트롤러가 간접적으로), 새 파드는 클러스터의 노드에서 실행되도록 스케줄된다. 파드는 파드 실행이 완료되거나, 파드 오브젝트가 삭제되거나, 리소스 부족으로 인해 파드가 축출 되거나, 노드가 실패할 때까지 해당 노드에 남아있다.

파드 오브젝트에 대한 매니페스트를 만들 때, 지정된 이름이 유효한 DNS 서브도메인 이름인지 확인한다.

파드와 컨트롤러

워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있다. 리소스에 대한 컨트롤러는 파드 장애 시 복제 및 롤아웃과 자동 복구를 처리한다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중지했음을 인식하고 대체 파드를 생성한다. 스케줄러는 대체 파드를 정상 노드에 배치한다.

다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 몇 가지 예시이다.

• 디플로이먼트
• 스테이트풀셋
• 데몬셋(DaemonSet)

파드 템플릿

워크로드 리소스에 대한 컨트롤러는 파드 템플릿 에서 파드를 생성하고 사용자 대신 해당 파드를 관리한다.

파드템플릿(PodTemplate)은 파드를 생성하기 위한 명세이며, 디플로이먼트, 잡 및 데몬셋과 같은 워크로드 리소스에 포함된다.

워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 PodTemplate 을 사용하여 실제 파드를 생성한다. PodTemplate 은 앱을 실행하는 데 사용되는 워크로드 리소스가 무엇이든지 원하는 상태의 일부이다.

아래 샘플은 하나의 컨테이너를 시작하는 template 이 있는 간단한 잡의 매니페스트이다. 해당 파드의 컨테이너는 메시지를 출력한 다음 일시 중지한다.

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # 여기서부터 파드 템플릿이다
    spec:
      containers:
      - name: hello
        image: busybox
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 여기까지 파드 템플릿이다

파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는 파드에는 직접적인 영향을 주지 않는다. 워크로드 리소스의 파드 템플릿을 변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 한다.

예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재 파드 템플릿과 일치하는지 확인한다. 스테이트풀셋을 수정하여 파드 템플릿을 변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작한다. 결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료된다.

각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현한다. 스테이트풀셋에 대해 자세히 알아 보려면, 스테이트풀셋 기본 튜토리얼에서 업데이트 전략을 읽어본다.

노드에서 kubelet은 파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않는다. 이러한 상세 내용은 추상화된다. 이러한 추상화와 관심사 분리(separation of concerns)는 시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을 확장할 수 있게 한다.

파드 갱신 및 교체

이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드 템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신 갱신된 템플릿을 기반으로 신규 파드를 생성한다.

쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다. 동작 중인 파드의 필드를 갱신하는 것도 가능하다. 그러나, patch 및 replace와 같은 파드 갱신 작업에는 다음과 같은 제약이 있다.

• 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는 namespace, name, uid, 또는 creationTimestamp 필드를 변경할 수 없다. 그리고 generation 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는 갱신만 허용한다.

• metadata.deletionTimestamp 가 설정된 경우, metadata.finalizers 리스트에 새로운 항목이 추가될 수 없다.

• 파드 갱신은 spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds, 또는 spec.tolerations 이외의 필드는 변경하지 않을 것이다. spec.tolerations 에 대해서만 새로운 항목을 추가할 수 있다.

• spec.activeDeadlineSeconds 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만 허용한다.

  1. 지정되지 않은 필드를 양수로 설정;
  2. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신.

리소스 공유와 통신

파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을 지원한다.

파드 스토리지

파드는 공유 스토리지 볼륨의 집합을 지정할 수 있다. 파드의 모든 컨테이너는 공유 볼륨에 접근할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수 있다. 또한 볼륨은 내부 컨테이너 중 하나를 다시 시작해야 하는 경우 파드의 영구 데이터를 유지하도록 허용한다. 쿠버네티스가 공유 스토리지를 구현하고 파드에서 사용할 수 있도록 하는 방법에 대한 자세한 내용은 스토리지를 참고한다.

파드 네트워킹

각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의 모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를 공유한다. 파드 내부(그때 만 해당)에서, 파드에 속한 컨테이너는 localhost 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가 파드 외부의 엔티티와 통신할 때, 공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. 파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, localhost 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다. 다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 IPC로 통신할 수 없다. 다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다.

파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된 name 과 동일한 것으로 간주한다. 네트워킹 섹션에 이에 대한 자세한 내용이 있다.

컨테이너에 대한 특권 모드

리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 보안 컨텍스트에 있는 privileged (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.

클러스터가 WindowsHostProcessContainers 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 windowsOptions.hostProcess 에 의해 윈도우 HostProcess 파드를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. 파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.

정적 파드

정적 파드 는 API 서버가 관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접 관리된다. 대부분의 파드는 컨트롤 플레인(예를 들어, 디플로이먼트)에 의해 관리되고, 정적 파드의 경우, kubelet이 각 정적 파드를 직접 감독한다(실패하면 다시 시작한다).

정적 파드는 항상 특정 노드의 Kubelet 하나에 바인딩된다. 정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것이다. 즉, kubelet을 사용하여 개별 컨트롤 플레인 컴포넌트를 감독한다.

kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 미러 파드를 생성하려고 한다. 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, 여기에서 제어할 수는 없다는 의미이다.

컨테이너 프로브

_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.

• ExecAction (컨테이너 런타임의 도움을 받아 수행)
• TCPSocketAction (kubelet에 의해 직접 검사)
• HTTPGetAction (kubelet에 의해 직접 검사)

프로브에 대한 자세한 내용은 파드 라이프사이클 문서를 참고한다.

다음 내용

• 파드의 라이프사이클에 대해 알아본다.
• 런타임클래스(RuntimeClass)와 이를 사용하여 다양한 컨테이너 런타임 구성으로 다양한 파드를 설정하는 방법에 대해 알아본다.
• 파드 토폴로지 분배 제약 조건에 대해 읽어본다.
• PodDisruptionBudget과 이를 사용하여 서비스 중단 중에 애플리케이션 가용성을 관리하는 방법에 대해 읽어본다.
• 파드는 쿠버네티스 REST API의 최상위 리소스이다. 오브젝트 정의는 오브젝트를 상세히 설명한다.
• 분산 시스템 툴킷: 컴포지트 컨테이너에 대한 패턴은 둘 이상의 컨테이너가 있는 파드의 일반적인 레이아웃을 설명한다.

쿠버네티스가 다른 리소스(스테이트풀셋이나 디플로이먼트와 같은)에서 공통 파드 API를 래핑하는 이유에 대한 콘텍스트를 이해하기 위해서, 다음과 같은 선행 기술에 대해 읽어볼 수 있다.

• Aurora
• Borg
• Marathon
• Omega
• Tupperware.

3.4.1.1 - 파드 라이프사이클

이 페이지에서는 파드의 라이프사이클을 설명한다. 파드는 정의된 라이프사이클을 따른다. Pending 단계에서 시작해서, 기본 컨테이너 중 적어도 하나 이상이 OK로 시작하면 Running 단계를 통과하고, 그런 다음 파드의 컨테이너가 실패로 종료되었는지 여부에 따라 Succeeded 또는 Failed 단계로 이동한다.

파드가 실행되는 동안, kubelet은 일종의 오류를 처리하기 위해 컨테이너를 다시 시작할 수 있다. 파드 내에서, 쿠버네티스는 다양한 컨테이너 상태를 추적하고 파드를 다시 정상 상태로 만들기 위해 취할 조치를 결정한다.

쿠버네티스 API에서 파드는 명세와 실제 상태를 모두 가진다. 파드 오브젝트의 상태는 일련의 파드 조건으로 구성된다. 사용자의 애플리케이션에 유용한 경우, 파드의 조건 데이터에 사용자 정의 준비성 정보를 삽입할 수도 있다.

파드는 파드의 수명 중 한 번만 스케줄된다. 파드가 노드에 스케줄(할당)되면, 파드는 중지되거나 종료될 때까지 해당 노드에서 실행된다.

파드의 수명

개별 애플리케이션 컨테이너와 마찬가지로, 파드는 비교적 임시(계속 이어지는 것이 아닌) 엔티티로 간주된다. 파드가 생성되고, 고유 ID(UID)가 할당되고, 종료(재시작 정책에 따라) 또는 삭제될 때까지 남아있는 노드에 스케줄된다. 만약 노드가 종료되면, 해당 노드에 스케줄된 파드는 타임아웃 기간 후에 삭제되도록 스케줄된다.

파드는 자체적으로 자가 치유되지 않는다. 파드가 노드에 스케줄된 후에 해당 노드가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는 리소스 부족 또는 노드 유지 관리 작업으로 인한 축출에서 살아남지 못한다. 쿠버네티스는 컨트롤러라 부르는 하이-레벨 추상화를 사용하여 상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다.

UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되지 않는다. 대신, 해당 파드는 사용자가 원한다면 이름은 같지만, UID가 다른, 거의 동일한 새 파드로 대체될 수 있다.

볼륨과 같은 어떤 것이 파드와 동일한 수명을 갖는다는 것은, 특정 파드(정확한 UID 포함)가 존재하는 한 그것이 존재함을 의미한다. 어떤 이유로든 해당 파드가 삭제되고, 동일한 대체 파드가 생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고 새로 생성된다.

컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와 파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.

파드의 단계

파드의 status 필드는 phase 필드를 포함하는 PodStatus 오브젝트로 정의된다.

파드의 phase는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 고수준의 요약이다. Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았다.

파드 phase 값에서 숫자와 의미는 엄격하게 지켜진다. 여기에 문서화된 내용 이외에는, 파드와 파드에 주어진 phase 값에 대해서 어떤 사항도 가정되어서는 안 된다.

phase에 가능한 값은 다음과 같다.

노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는 손실된 노드의 모든 파드의 phase 를 Failed로 설정하는 정책을 적용한다.

컨테이너 상태

전체 파드의 단계뿐 아니라, 쿠버네티스는 파드 내부의 각 컨테이너 상태를 추적한다. 컨테이너 라이프사이클 훅(hook)을 사용하여 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있다.

일단 스케줄러가 노드에 파드를 할당하면, kubelet은 컨테이너 런타임을 사용하여 해당 파드에 대한 컨테이너 생성을 시작한다. 표시될 수 있는 세 가지 컨테이너 상태는 Waiting, Running 그리고 Terminated 이다.

파드의 컨테이너 상태를 확인하려면, kubectl describe pod <name-of-pod> 를 사용할 수 있다. 출력 결과는 해당 파드 내의 각 컨테이너 상태가 표시된다.

각 상태에는 특정한 의미가 있다.

Waiting

만약 컨테이너가 Running 또는 Terminated 상태가 아니면, Waiting 상태이다. Waiting 상태의 컨테이너는 시작을 완료하는 데 필요한 작업(예를 들어, 컨테이너 이미지 레지스트리에서 컨테이너 이미지 가져오거나, 시크릿(Secret) 데이터를 적용하는 작업)을 계속 실행하고 있는 중이다. kubectl 을 사용하여 컨테이너가 Waiting 인 파드를 쿼리하면, 컨테이너가 해당 상태에 있는 이유를 요약하는 Reason 필드도 표시된다.

Running

Running 상태는 컨테이너가 문제없이 실행되고 있음을 나타낸다. postStart 훅이 구성되어 있었다면, 이미 실행되고 완료되었다. kubectl 을 사용하여 컨테이너가 Running 인 파드를 쿼리하면, 컨테이너가 Running 상태에 진입한 시기에 대한 정보도 볼 수 있다.

Terminated

Terminated 상태의 컨테이너는 실행을 시작한 다음 완료될 때까지 실행되었거나 어떤 이유로 실패했다. kubectl 을 사용하여 컨테이너가 Terminated 인 파드를 쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과 종료 시간이 표시된다.