레퍼런스

• 1: 용어집
• 2: API 개요
• 2.1: 클라이언트 라이브러리
• 2.2: 쿠버네티스 API 헬스(health) 엔드포인트
• 3: API 접근 제어
• 3.1: 서비스 어카운트 관리하기
• 3.2: 인가 개요
• 4: 쿠버네티스 이슈와 보안
• 4.1: 쿠버네티스 이슈 트래커
• 4.2: 쿠버네티스 보안과 공개 정보
• 5: 설치 도구
• 5.1: Kubeadm
• 5.1.1: Kubeadm Generated
• 6: kubectl
• 6.1: kubectl 개요
• 6.2: JSONPath 지원
• 6.3: kubectl
• 6.4: kubectl 사용 규칙
• 6.5: kubectl 치트 시트
• 6.6: 도커 사용자를 위한 kubectl
• 7: 컴포넌트 도구
• 7.1: 기능 게이트
• 7.2: kube-proxy
• 7.3: Kubelet 인증/인가
• 8: 스케줄링
• 8.1: 스케줄링 정책
• 8.2: 스케줄러 구성
• 9: 도구

1 - 용어집

2 - API 개요

이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다.

REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 API 오브젝트로 취급되고, API에 상응하는 항목이 있다.

쿠버네티스 API 참조는 쿠버네티스 버전 v1.20에 대한 API가 나열되어 있다.

일반적인 배경 정보를 보려면, 쿠버네티스 API를 참고한다. 쿠버네티스 API에 대한 접근 제어는 클라이언트가 쿠버네티스 API 서버에 인증하는 방법과 요청이 승인되는 방법을 설명한다.

API 버전 규칙

JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.

API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. API와 릴리스 버전 부여에 관한 제안에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.

API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. API 변경 문서에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다.

아래는 각 수준의 기준에 대한 요약이다.

• 알파(Alpha):

  • 버전 이름에 alpha가 포함된다(예: v1alpha1).
  • 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. 기본적으로 비활성화되어 있다.
  • 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다.
  • 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다.
  • 버그에 대한 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다.

• 베타(Beta):

  • 버전 이름에 beta가 포함된다(예: v2beta3).

  • 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. 기본적으로 활성화되어 있다.

  • 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다.

  • 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다.

  • 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다.

  참고: 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 실질적으로 더 많은 변경이 어렵다.

• 안정화(Stable):

  • 버전 이름이 vX이고 X 는 정수다.
  • 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다.

API 그룹

API 그룹은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 오브젝트의 apiVersion 필드에 명시된다.

쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다.

• 핵심 (또는 레거시 라고 불리는) 그룹은 REST 경로 /api/v1에 있다. 핵심 그룹은 apiVersion 필드의 일부로 명시되지 않는다. 예를 들어, apiVersion: v1 과 같다.
• 이름이 있는 그룹은 REST 경로 /apis/$GROUP_NAME/$VERSION에 있으며 apiVersion: $GROUP_NAME/$VERSION을 사용한다(예를 들어, apiVersion: batch/v1). 지원되는 API 그룹 전체의 목록은 쿠버네티스 API 참조 문서에서 확인할 수 있다.

API 그룹 활성화 또는 비활성화

특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 --runtime-config 를 설정하여 활성화 또는 비활성화할 수 있다. --runtime-config 플래그는 API 서버의 런타임 구성을 설명하는 쉼표로 구분된 <key>=<value> 쌍을 허용한다. 만약 =<value> 부분을 생략하면, =true 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다.

• batch/v1 을 비활성화하려면, --runtime-config=batch/v1=false 로 설정
• batch/v2alpha1 을 활성화하려면, --runtime-config=batch/v2alpha1 으로 설정

참고: 그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 --runtime-config 변경을 반영해야 한다.

지속성

쿠버네티스는 etcd에 기록하여 API 리소스 측면에서 직렬화된 상태를 저장한다.

다음 내용

• API 규칙에 대해 자세히 알아보기
• 애그리게이터(aggregator)에 대한 디자인 문서 읽기

2.1 - 클라이언트 라이브러리

이 페이지는 다양한 프로그래밍 언어에서 쿠버네티스 API를 사용하기 위한 클라이언트 라이브러리에 대한 개요를 포함하고 있다.

쿠버네티스 REST API를 사용해 애플리케이션을 작성하기 위해 API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다.

클라이언트 라이브러리는 대체로 인증과 같은 공통의 태스크를 처리한다. 대부분의 클라이언트 라이브러리들은 API 클라이언트가 쿠버네티스 클러스터 내부에서 동작하는 경우 인증 또는 kubeconfig 파일 포맷을 통해 자격증명과 API 서버 주소를 읽을 수 있게 쿠버네티스 서비스 어카운트를 발견하고 사용할 수 있다.

공식적으로 지원되는 쿠버네티스 클라이언트 라이브러리

다음의 클라이언트 라이브러리들은 쿠버네티스 SIG API Machinery에서 공식적으로 관리된다.

커뮤니티에 의해 관리되는 클라이언트 라이브러리

주의: 이 섹션은 쿠버네티스에 필요한 기능을 제공하는 써드파티 프로젝트와 관련이 있다. 쿠버네티스 프로젝트 작성자는 써드파티 프로젝트에 책임이 없다. 이 페이지는 CNCF 웹사이트 가이드라인에 따라 프로젝트를 알파벳 순으로 나열한다. 이 목록에 프로젝트를 추가하려면 변경사항을 제출하기 전에 콘텐츠 가이드를 읽어본다.

다음의 쿠버네티스 API 클라이언트 라이브러리들은 쿠버네티스 팀이 아닌 각각의 저자들이 제공하고 관리한다.

2.2 - 쿠버네티스 API 헬스(health) 엔드포인트

쿠버네티스 API 서버는 현재 상태를 나타내는 API 엔드포인트를 제공한다. 이 페이지에서는 API 엔드포인트들에 대해 설명하고 이를 사용하는 방법을 다룬다.

헬스를 위한 API 엔드포인트

쿠버네티스 API 서버는 현재 상태를 나타내는 세 가지 API 엔드포인트(healthz, livez 와 readyz)를 제공한다. healthz 엔드포인트는 사용 중단(deprecated)됐으며 (쿠버네티스 v1.16 버전 이후), 대신 보다 구체적인 livez 와 readyz 엔드포인트를 사용해야 한다. livez 엔드포인트는 --livez-grace-period 플래그 옵션을 사용하여 시작 대기 시간을 지정할 수 있다. /readyz 엔드포인트는 --shutdown-delay-duration 플래그 옵션을 사용하여 정상적(graceful)으로 셧다운할 수 있다. API 서버의 health/livez/readyz 를 사용하는 머신은 HTTP 상태 코드에 의존해야 한다. 상태 코드 200은 호출된 엔드포인트에 따라 API 서버의 healthy/live/ready 상태를 나타낸다. 아래 표시된 더 자세한 옵션은 운영자가 클러스터나 특정 API 서버의 상태를 디버깅하는데 사용할 수 있다.

다음의 예시는 헬스 API 엔드포인트와 상호 작용할 수 있는 방법을 보여준다.

모든 엔드포인트는 verbose 파라미터를 사용하여 검사 항목과 상태를 출력할 수 있다. 이는 운영자가 머신 사용을 위한 것이 아닌, API 서버의 현재 상태를 디버깅하는데 유용하다.

curl -k https://localhost:6443/livez?verbose

인증을 사용하는 원격 호스트에서 사용할 경우에는 다음과 같이 수행한다.

kubectl get --raw='/readyz?verbose'

출력은 다음과 같다.

[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
healthz check passed

또한 쿠버네티스 API 서버는 특정 체크를 제외할 수 있다. 쿼리 파라미터는 다음 예와 같이 조합될 수 있다.

curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'

출력에서 etcd 체크가 제외된 것을 보여준다.

[+]ping ok
[+]log ok
[+]etcd excluded: ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]shutdown ok
healthz check passed

개별 헬스 체크

각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다. 개별 체크를 위한 스키마는 /livez/<healthcheck-name> 이고, 여기서 livez 와 readyz 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. <healthcheck-name> 경로 위에서 설명한 verbose 플래그를 사용해서 찾을 수 있고, [+] 와 ok 사이의 경로를 사용한다. 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.

curl -k https://localhost:6443/livez/etcd

3 - API 접근 제어

쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 쿠버네티스 API에 대한 접근 제어를 참고한다.

참조 문헌

• 인증
  • 부트스트랩 토큰 인증
• 승인 컨트롤러
  • 동적 승인 제어
• 인가
  • 역할 기반 접근 제어
  • 속성 기반 접근 제어
  • 노드 인가
  • 웹훅 인가
• 인증서 서명 요청
  • CSR 승인과 인증서 서명을 포함함
• 서비스 어카운트
  • 개발자 가이드
  • 관리

3.1 - 서비스 어카운트 관리하기

이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다. 독자는 쿠버네티스 서비스 어카운트 설정에 익숙하다고 가정한다.

인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다. 가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.

사용자 어카운트와 서비스 어카운트 비교

쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다.

• 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 위한 것이다.
• 사용자 어카운트는 전역을 대상으로 고려된다. 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다.
• 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. 서비스 어카운트 생성은 클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 보다 가볍게 만들어졌다.
• 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
• 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. 서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에 이러한 설정은 이식성이 좋다.

서비스 어카운트 자동화

서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.

• ServiceAccount 어드미션 컨트롤러
• 토큰 컨트롤러
• ServiceAccount 컨트롤러

서비스어카운트(ServiceAccount) 어드미션 컨트롤러

파드 수정은 어드미션 컨트롤러라는 플러그인을 통해 구현된다. 이것은 API 서버의 일부이다. 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다. 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.

1. 파드에 ServiceAccount 가 없다면, ServiceAccount 를 default 로 설정한다.
2. 파드에 참조되는 ServiceAccount 가 있도록 하고, 그렇지 않으면 이를 거부한다.
3. 파드에 ImagePullSecrets 이 없는 경우, ServiceAccount 의 ImagePullSecrets 이 파드에 추가된다.
4. 파드에 API 접근을 위한 토큰이 포함된 volume 을 추가한다.
5. /var/run/secrets/kubernetes.io/serviceaccount 에 마운트된 파드의 각 컨테이너에 volumeSource 를 추가한다.

바인딩된 서비스 어카운트 토큰 볼륨

BoundServiceAccountTokenVolume 기능 게이트가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가 시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. 프로젝티드 볼륨에 대한 자세한 내용을 참고한다.

이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 RootCAConfigMap 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.

1. 파드에 serviceAccountName가 없다면, serviceAccountName를 default로 설정한다.
2. 파드에 참조되는 serviceAccountName가 있도록 하고, 그렇지 않으면 이를 거부한다.
3. 파드에 imagePullSecrets이 없는 경우, 서비스어카운트의 imagePullSecrets이 파드에 추가된다.
4. 서비스어카운트 automountServiceAccountToken 또는 파드의 automountServiceAccountToken 이 false 로 설정되지 않은 경우 파드에 API 접근 토큰이 포함된 volume을 추가한다.
5. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우, /var/run/secrets/kubernetes.io/serviceaccount에 마운트된 파드의 각 컨테이너에 volumeSource를 추가한다.

BoundServiceAccountTokenVolume 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다. 서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다. 프로젝티드 볼륨에 대한 자세한 내용을 참조한다.

토큰 컨트롤러

토큰컨트롤러는 kube-controller-manager 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,

• 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당 서비스어카운트 토큰 시크릿을 생성한다.
• 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트 토큰 시크릿을 삭제한다.
• 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가 존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다.
• 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서 참조를 제거한다.

서비스 어카운트 개인키 파일은 --service-account-private-key-file 플래그를 사용하여 kube-controller-manager 의 토큰 컨트롤러에 전달해야 한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. 마찬가지로 --service-account-key-file 플래그를 사용하여 해당 공개키를 kube-apiserver 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.

추가적인 API 토큰 생성

컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다. 서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해 서비스어카운트를 참조하는 어노테이션과 함께 kubernetes.io/service-account-token 유형의 시크릿을 생성하면 컨트롤러가 새로 생성된 토큰으로 갱신한다.

다음은 시크릿에 대한 샘플 구성이다.

apiVersion: v1
kind: Secret
metadata:
  name: mysecretname
  annotations:
    kubernetes.io/service-account.name: myserviceaccount
type: kubernetes.io/service-account-token

kubectl create -f ./secret.yaml
kubectl describe secret mysecretname

서비스 어카운트 토큰 시크릿 삭제/무효화

kubectl delete secret mysecretname

서비스어카운트 컨트롤러

서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고 "default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.

3.2 - 인가 개요

지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한 쿠버네티스 인가에 대해 자세히 알아보자.

쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다. 인증에 대한 자세한 내용은 쿠버네티스 API 접근 제어하기를 참고한다.

쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다. 이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 연동된다는 것을 의미한다.

요청 허용 또는 거부 결정

쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다. 모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다. 계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다. 이는 기본적으로 승인이 거부된다는 것을 의미한다.

(쿠버네티스는 API 서버를 사용하지만, 특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은 어드미션 컨트롤러에 의해 처리된다.)

여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다. 어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다. 모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다. 요청 거부는 HTTP 상태 코드 403을 반환한다.

요청 속성 검토

쿠버네티스는 다음 API 요청 속성만 검토한다.

• user - 인증 중에 제공된 user 문자열.
• group - 인증된 사용자가 속한 그룹 이름 목록.
• extra - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
• API - 요청이 API 리소스에 대한 것인지 여부.
• Request path - /api 또는 /healthz와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
• API request verb - get, list, create, update, patch, watch, delete, deletecollection과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 요청 동사 결정을 참고한다.
• HTTP request verb - get, post, put, delete처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
• Resource - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- get, update, patch, delete 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
• Subresource - 접근 중인 하위 리소스(리소스 요청만 해당).
• Namespace - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
• API group - 접근 중인 API 그룹(리소스 요청에만 해당). 빈 문자열은 핵심(core) API 그룹을 지정한다.

요청 동사 결정

리소스가 아닌 요청 /api/v1/... 또는 /apis/<group>/<version>/... 이외에 다른 엔드포인트에 대한 요청은 "리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다. 예를 들어, /api 또는 /healthz와 같은 엔드포인트에 대한 GET 요청은 get을 동사로 사용할 것이다.

리소스 요청 리소스 API 엔드포인트에 대한 요청 동사를 결정하려면 사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를 검토한다.

쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,

• 파드시큐리티폴리시(PodSecurityPolicy)
  • policy API 그룹의 podsecuritypolicies 리소스에 대한 use 동사.
• RBAC
  • rbac.authorization.k8s.io API 그룹의 roles 및 clusterroles 리소스에 대한 bind 동사.
• 인증
  • 핵심 API 그룹의 users, groups, serviceaccounts와 authentication.k8s.io API 그룹의 userextras 동사.

인가 모드

쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.

• Node - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 Node 인가을 참조한다.
• ABAC - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 ABAC 모드를 참조한다.
• RBAC - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 RBAC 모드를 참조한다.
  • 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 rbac.authorization.k8s.io API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.
  • RBAC을 활성화하려면 --authorization-mode=RBAC로 API 서버를 시작한다.
• Webhook - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 Webhook 모드를 참조한다.

API 접근 확인

kubectl은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다. 이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 SelfSubjectAccessReview API를 사용하며, 사용되는 인가 모드에 관계없이 작동한다.

kubectl auth can-i create deployments --namespace dev

다음과 유사하게 출력된다.

yes

kubectl auth can-i create deployments --namespace prod

다음과 유사하게 출력된다.

no

관리자는 이를 사용자 가장(impersonation)과 병행하여 다른 사용자가 수행할 수 있는 작업을 결정할 수 있다.

kubectl auth can-i list secrets --namespace dev --as dave

다음과 유사하게 출력된다.

no

SelfSubjectAccessReview는 authorization.k8s.io API 그룹의 일부로서 API 서버 인가를 외부 서비스에 노출시킨다. 이 그룹의 기타 리소스에는 다음이 포함된다.

• SubjectAccessReview - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다.
• LocalSubjectAccessReview - SubjectAccessReview와 비슷하지만 특정 네임스페이스로 제한된다.
• SelfSubjectRulesReview - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.

이러한 API는 반환된 오브젝트의 응답 "status" 필드가 쿼리의 결과인 일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.

kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    verb: create
    namespace: dev
EOF

생성된 SelfSubjectAccessReview 는 다음과 같다.

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
  creationTimestamp: null
spec:
  resourceAttributes:
    group: apps
    resource: deployments
    namespace: dev
    verb: create
status:
  allowed: true
  denied: false

인가 모듈에 플래그 사용

정책에 포함된 인가 모듈을 나타내기 위해 정책에 플래그를 포함시켜야 한다.

다음 플래그를 사용할 수 있다.

• --authorization-mode=ABAC 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다.
• --authorization-mode=RBAC 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다.
• --authorization-mode=Webhook WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다.
• --authorization-mode=Node 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다.
• --authorization-mode=AlwaysDeny 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다.
• --authorization-mode=AlwaysAllow 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.

하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에 우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.

파드 생성을 통한 권한 확대

네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는 해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다. 네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다. 사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나 서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.

주의: 시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다. 네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는 네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고 네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다. 이는 인가 모드에 관계없이 적용된다.

다음 내용

• 인증에 대한 자세한 내용은 쿠버네티스 API 접근 제어하기에서 인증 을 참조한다.
• 어드미션 제어에 대한 자세한 내용은 어드미션 컨트롤러 사용하기를 참조한다.

4 - 쿠버네티스 이슈와 보안

4.1 - 쿠버네티스 이슈 트래커

보안 문제를 보고하려면 쿠버네티스 보안 공개 프로세스를 따른다.

쿠버네티스 코드 작업 및 공개 이슈는 깃허브 이슈를 사용하여 추적된다.

• CVE-연관된 이슈들

보안에 관련된 공지사항은 kubernetes-security-announce@googlegroups.com 메일 리스트로 전송된다.

4.2 - 쿠버네티스 보안과 공개 정보

이 페이지는 쿠버네티스 보안 및 공개 정보를 설명한다.

보안 공지

보안 및 주요 API 공지에 대한 이메일을 위해 kubernetes-security-announce) 그룹에 가입하세요.

이 링크를 사용하여 RSS 피드를 구독할 수 있다.

취약점 보고

우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다.

보고서를 작성하려면, 쿠버네티스 버그 현상금 프로그램에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다. 또한, 보안 세부 내용과 모든 쿠버네티스 버그 보고서로 부터 예상되는 세부사항을 security@kubernetes.io로 이메일을 보낸다.

제품 보안 위원회 구성원의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다.

언제 취약점을 보고해야 하는가?

• 쿠버네티스에서 잠재적인 보안 취약점을 발견했다고 생각하는 경우
• 취약성이 쿠버네티스에 어떤 영향을 미치는지 확신할 수 없는 경우
• 쿠버네티스가 의존하는 다른 프로젝트에서 취약점을 발견한 경우
  • 자체 취약성 보고 및 공개 프로세스가 있는 프로젝트의 경우 직접 보고한다.

언제 취약점을 보고하지 말아야 하는가?

• 보안을 위해 쿠버네티스 구성요소를 조정하는데 도움이 필요한 경우
• 보안 관련 업데이트를 적용하는 데 도움이 필요한 경우
• 보안 관련 문제가 아닌 경우

보안 취약점 대응

각 보고서는 제품 보안 위원회 위원들에 의해 작업일 3일 이내에 인정되고 분석된다. 이렇게 하면 보안 릴리스 프로세스가 시작된다.

제품 보안 위원회와 공유하는 모든 취약성 정보는 쿠버네티스 프로젝트 내에 있으며, 문제를 해결할 필요가 없는 한 다른 프로젝트에 전파되지 않는다.

보안 문제가 심사에서 확인된 수정, 릴리스 계획으로 이동함에 따라 리포터를 계속 업데이트할 것이다.

공개 시기

공개 날짜는 쿠버네티스 제품 보안 위원회와 버그 제출자가 협상한다. 사용자 완화가 가능해지면 가능한 빨리 버그를 완전히 공개하는 것이 좋다. 버그 또는 픽스가 아직 완전히 이해되지 않았거나 솔루션이 제대로 테스트되지 않았거나 벤더 협력을 위해 공개를 지연시키는 것이 합리적이다. 공개 기간은 즉시(특히 이미 공개적으로 알려진 경우)부터 몇 주까지입니다. 간단한 완화 기능이 있는 취약점의 경우 보고 날짜부터 공개 날짜까지는 7일 정도 소요될 것으로 예상된다. 쿠버네티스 제품 보안 위원회는 공개 날짜를 설정할 때 최종 결정권을 갖는다.

5 - 설치 도구

5.1 - Kubeadm

Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 kubeadm init 과 kubeadm join 을 제공하도록 만들어진 도구이다.

kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다.

대신, 우리는 더 높은 수준의 맞춤형 도구가 kubeadm 위에 구축될 것으로 기대하며, 이상적으로는, 모든 배포의 기반으로 kubeadm을 사용하면 규격을 따르는 클러스터를 더 쉽게 생성할 수 있다.

설치 방법

kubeadm을 설치하려면, 설치 가이드를 참고한다.

다음 내용

• kubeadm init: 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다.
• kubeadm join: 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다.
• kubeadm upgrade: 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다.
• kubeadm config: kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, kubeadm upgrade 를 위해 사용자의 클러스터를 구성한다.
• kubeadm token: kubeadm join 을 위한 토큰을 관리한다.
• kubeadm reset: kubeadm init 또는 kubeadm join 에 의한 호스트의 모든 변경 사항을 되돌린다.
• kubeadm version: kubeadm 버전을 출력한다.
• kubeadm alpha: 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다.

5.1.1 - Kubeadm Generated

6 - kubectl

6.1 - kubectl 개요

Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. 구성을 위해, kubectl 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 --kubeconfig 플래그를 설정하여 다른 kubeconfig 파일을 지정할 수 있다.

이 개요는 kubectl 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 kubectl 참조 문서를 참고한다. 설치 방법에 대해서는 kubectl 설치를 참고한다.

구문

터미널 창에서 kubectl 명령을 실행하려면 다음의 구문을 사용한다.

kubectl [command] [TYPE] [NAME] [flags]

다음은 command, TYPE, NAME 과 flags 에 대한 설명이다.

• command: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. 예: create, get, describe, delete

• TYPE: 리소스 타입을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 단수형, 복수형 또는 약어 형식을 지정할 수 있다. 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다.

  kubectl get pod pod1
  kubectl get pods pod1
  kubectl get po pod1
  

• NAME: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: kubectl get pods

  여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다.

  • 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다.

    • 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. TYPE1 name1 name2 name<#>
      예: kubectl get pod example-pod1 example-pod2

    • 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>
      예: kubectl get pod/example-pod1 replicationcontroller/example-rc1

  • 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. -f file1 -f file2 -f file<#>

    • YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, JSON 대신 YAML을 사용한다.
      예: kubectl get -f ./pod.yaml

• flags: 선택적 플래그를 지정한다. 예를 들어, -s 또는 --server 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
  

주의: 커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다.

도움이 필요하다면, 터미널 창에서 kubectl help 를 실행한다.

명령어

다음 표에는 모든 kubectl 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.

명령 동작에 대한 자세한 내용을 배우려면 kubectl 참조 문서를 참고한다.

리소스 타입

다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다.

(이 출력은 kubectl api-resources 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.)

출력 옵션

특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 kubectl 참조 문서를 참고한다.

출력 서식화

모든 kubectl 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 kubectl 명령에 -o 또는 --output 플래그를 추가할 수 있다.

구문

kubectl [command] [TYPE] [NAME] -o <output_format>

kubectl 명령에 따라, 다음과 같은 출력 형식이 지원된다.

예제

이 예제에서, 다음의 명령은 단일 파드에 대한 세부 정보를 YAML 형식의 오브젝트로 출력한다.

kubectl get pod web-pod-13je7 -o yaml

기억하기: 각 명령이 지원하는 출력 형식에 대한 자세한 내용은 kubectl 참조 문서를 참고한다.

사용자 정의 열

사용자 정의 열을 정의하고 원하는 세부 정보만 테이블에 출력하려면, custom-columns 옵션을 사용할 수 있다. 사용자 정의 열을 인라인으로 정의하거나 템플릿 파일을 사용하도록 선택할 수 있다. -o custom-columns=<spec> 또는 -o custom-columns-file=<filename>

예제

인라인:

kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion

템플릿 파일:

kubectl get pods <pod-name> -o custom-columns-file=template.txt

template.txt 파일에 포함된 내용은 다음과 같다.

NAME          RSRC
metadata.name metadata.resourceVersion

두 명령 중 하나를 실행한 결과는 다음과 비슷하다.

NAME           RSRC
submit-queue   610995

서버측 열

kubectl 는 서버에서 오브젝트에 대한 특정 열 정보 수신을 지원한다. 이는 클라이언트가 출력할 수 있도록, 주어진 리소스에 대해 서버가 해당 리소스와 관련된 열과 행을 반환한다는 것을 의미한다. 이는 서버가 출력의 세부 사항을 캡슐화하도록 하여, 동일한 클러스터에 대해 사용된 클라이언트에서 사람이 읽을 수 있는 일관된 출력을 허용한다.

이 기능은 기본적으로 활성화되어 있다. 사용하지 않으려면, kubectl get 명령에 --server-print=false 플래그를 추가한다.

예제

파드 상태에 대한 정보를 출력하려면, 다음과 같은 명령을 사용한다.

kubectl get pods <pod-name> --server-print=false

출력 결과는 다음과 비슷하다.

NAME       AGE
pod-name   1m

오브젝트 목록 정렬

터미널 창에서 정렬된 목록으로 오브젝트를 출력하기 위해, 지원되는 kubectl 명령에 --sort-by 플래그를 추가할 수 있다. --sort-by 플래그와 함께 숫자나 문자열 필드를 지정하여 오브젝트를 정렬한다. 필드를 지정하려면, jsonpath 표현식을 사용한다.

구문

kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>

예제

이름별로 정렬된 파드 목록을 출력하려면, 다음을 실행한다.

kubectl get pods --sort-by=.metadata.name

예제: 일반적인 작업

다음 예제 세트를 사용하여 일반적으로 사용되는 kubectl 조작 실행에 익숙해진다.

kubectl apply - 파일 또는 표준입력에서 리소스를 적용하거나 업데이트한다.

# example-service.yaml의 정의를 사용하여 서비스를 생성한다.
kubectl apply -f example-service.yaml

# example-controller.yaml의 정의를 사용하여 레플리케이션 컨트롤러를 생성한다.
kubectl apply -f example-controller.yaml

# <directory> 디렉터리 내의 .yaml, .yml 또는 .json 파일에 정의된 오브젝트를 생성한다.
kubectl apply -f <directory>

kubectl get - 하나 이상의 리소스를 나열한다.

# 모든 파드를 일반 텍스트 출력 형식으로 나열한다.
kubectl get pods

# 모든 파드를 일반 텍스트 출력 형식으로 나열하고 추가 정보(예: 노드 이름)를 포함한다.
kubectl get pods -o wide

# 지정된 이름의 레플리케이션 컨트롤러를 일반 텍스트 출력 형식으로 나열한다. 팁: 'replicationcontroller' 리소스 타입을 'rc'로 짧게 바꿔쓸 수 있다.
kubectl get replicationcontroller <rc-name>

# 모든 레플리케이션 컨트롤러와 서비스를 일반 텍스트 출력 형식으로 함께 나열한다.
kubectl get rc,services

# 모든 데몬 셋을 일반 텍스트 출력 형식으로 나열한다.
kubectl get ds

# 노드 server01에서 실행 중인 모든 파드를 나열한다.
kubectl get pods --field-selector=spec.nodeName=server01

kubectl describe - 초기화되지 않은 리소스를 포함하여 하나 이상의 리소스의 기본 상태를 디폴트로 표시한다.

# 노드 이름이 <node-name>인 노드의 세부 사항을 표시한다.
kubectl describe nodes <node-name>

# 파드 이름이 <pod-name> 인 파드의 세부 정보를 표시한다.
kubectl describe pods/<pod-name>

# 이름이 <rc-name>인 레플리케이션 컨트롤러가 관리하는 모든 파드의 세부 정보를 표시한다.
# 기억하기: 레플리케이션 컨트롤러에서 생성된 모든 파드에는 레플리케이션 컨트롤러 이름이 접두사로 붙는다.
kubectl describe pods <rc-name>

# 모든 파드의 정보를 출력한다.
kubectl describe pods

참고: kubectl get 명령은 일반적으로 동일한 리소스 타입의 하나 이상의 리소스를 검색하는 데 사용된다. 예를 들어, -o 또는 --output 플래그를 사용하여 출력 형식을 사용자 정의할 수 있는 풍부한 플래그 세트가 있다. -w 또는 --watch 플래그를 지정하여 특정 오브젝트에 대한 업데이트 진행과정을 확인할 수 있다. kubectl describe 명령은 지정된 리소스의 여러 관련 측면을 설명하는 데 더 중점을 둔다. API 서버에 대한 여러 API 호출을 호출하여 사용자에 대한 뷰(view)를 빌드할 수 있다. 예를 들어, kubectl describe node 명령은 노드에 대한 정보뿐만 아니라, 노드에서 실행 중인 파드의 요약 정보, 노드에 대해 생성된 이벤트 등의 정보도 검색한다.

kubectl delete - 파일, 표준입력 또는 레이블 선택기, 이름, 리소스 선택기나 리소스를 지정하여 리소스를 삭제한다.

# pod.yaml 파일에 지정된 타입과 이름을 사용하여 파드를 삭제한다.
kubectl delete -f pod.yaml

# '<label-key>=<label-value>' 레이블이 있는 모든 파드와 서비스를 삭제한다.
kubectl delete pods,services -l <label-key>=<label-value>

# 초기화되지 않은 파드를 포함한 모든 파드를 삭제한다.
kubectl delete pods --all

kubectl exec - 파드의 컨테이너에 대해 명령을 실행한다.

# 파드 <pod-name>에서 'date'를 실행한 결과를 얻는다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec <pod-name> -- date

# 파드 <pod-name>의 <container-name> 컨테이너에서 'date'를 실행하여 출력 결과를 얻는다.
kubectl exec <pod-name> -c <container-name> -- date

# 파드 <pod-name>에서 대화식 TTY를 연결해 /bin/bash를 실행한다. 기본적으로, 첫 번째 컨테이너에서 출력된다.
kubectl exec -ti <pod-name> -- /bin/bash

kubectl logs - 파드의 컨테이너에 대한 로그를 출력한다.

# 파드 <pod-name>에서 로그의 스냅샷을 반환한다.
kubectl logs <pod-name>

# 파드 <pod-name>에서 로그 스트리밍을 시작한다. 이것은 리눅스 명령 'tail -f'와 비슷하다.
kubectl logs -f <pod-name>

kubectl diff - 제안된 클러스터 업데이트의 차이점을 본다.

# "pod.json"에 포함된 리소스의 차이점을 출력한다.
kubectl diff -f pod.json

# 표준입력에서 파일을 읽어 차이점을 출력한다.
cat service.yaml | kubectl diff -f -

예제: 플러그인 작성 및 사용

kubectl 플러그인 작성과 사용에 익숙해지려면 다음의 예제 세트를 사용한다.

# 어떤 언어로든 간단한 플러그인을 만들고 "kubectl-" 접두사로
# 시작하도록 실행 파일의 이름을 지정한다.
cat ./kubectl-hello

#!/bin/sh

# 이 플러그인은 "hello world"라는 단어를 출력한다
echo "hello world"

작성한 플러그인을 실행 가능하게 한다

chmod a+x ./kubectl-hello

# 그리고 PATH의 위치로 옮긴다
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin

# 이제 kubectl 플러그인을 만들고 "설치했다".
# kubectl에서 플러그인을 일반 명령처럼 호출하여 플러그인을 사용할 수 있다
kubectl hello

hello world

# 플러그인을 배치한 $PATH의 폴더에서 플러그인을 삭제하여,
# 플러그인을 "제거"할 수 있다
sudo rm /usr/local/bin/kubectl-hello

kubectl 에 사용할 수 있는 모든 플러그인을 보려면, kubectl plugin list 하위 명령을 사용한다.

kubectl plugin list

출력 결과는 다음과 비슷하다.

The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar

kubectl plugin list 는 또한 실행 가능하지 않거나, 다른 플러그인에 의해 차단된 플러그인에 대해 경고한다. 예를 들면 다음과 같다.

sudo chmod -x /usr/local/bin/kubectl-foo # 실행 권한 제거
kubectl plugin list

The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar

error: one plugin warning was found

플러그인은 기존 kubectl 명령 위에 보다 복잡한 기능을 구축하는 수단으로 생각할 수 있다.

cat ./kubectl-whoami

다음 몇 가지 예는 이미 kubectl-whoami 에 다음 내용이 있다고 가정한다.

#!/bin/bash

# 이 플러그인은 현재 선택된 컨텍스트를 기반으로 현재 사용자에 대한
# 정보를 출력하기 위해 'kubectl config' 명령을 사용한다.
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'

위의 플러그인을 실행하면 KUBECONFIG 파일에서 현재의 컨텍스트에 대한 사용자가 포함된 출력이 제공된다.

# 파일을 실행 가능하게 한다
sudo chmod +x ./kubectl-whoami

# 그리고 PATH로 옮긴다
sudo mv ./kubectl-whoami /usr/local/bin

kubectl whoami
Current user: plugins-user

다음 내용

• kubectl 명령을 사용하여 시작한다.

• 플러그인에 대한 자세한 내용은 cli plugin 예제를 참고한다.

6.2 - JSONPath 지원

Kubectl은 JSONPath 템플릿을 지원한다.

JSONPath 템플릿은 중괄호 {}로 둘러싸인 JSONPath 표현식으로 구성된다. Kubectl은 JSONPath 표현식을 사용하여 JSON 오브젝트의 특정 필드를 필터링하고 출력 형식을 지정한다. 원본 JSONPath 템플릿 구문 외에도 다음과 같은 기능과 구문이 유효하다.

1. 큰따옴표를 사용하여 JSONPath 표현식 내부의 텍스트를 인용한다.
2. 목록을 반복하려면 range, end 오퍼레이터를 사용한다.
3. 목록에서 뒤로 이동하려면 negative slice 인덱스를 사용한다. negative 인덱스는 목록을 "순환(wrap around)" 하지 않으며, -index + listLength >= 0 인 한 유효하다.

참고:

• 표현식은 항상 루트 오브젝트에서 시작하므로 $ 오퍼레이터는 선택 사항이다.

• 결과 오브젝트는 String() 함수로 출력된다.

JSON 입력 시 다음과 같다.

{
  "kind": "List",
  "items":[
    {
      "kind":"None",
      "metadata":{"name":"127.0.0.1"},
      "status":{
        "capacity":{"cpu":"4"},
        "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
      }
    },
    {
      "kind":"None",
      "metadata":{"name":"127.0.0.2"},
      "status":{
        "capacity":{"cpu":"8"},
        "addresses":[
          {"type": "LegacyHostIP", "address":"127.0.0.2"},
          {"type": "another", "address":"127.0.0.3"}
        ]
      }
    }
  ],
  "users":[
    {
      "name": "myself",
      "user": {}
    },
    {
      "name": "e2e",
      "user": {"username": "admin", "password": "secret"}
    }
  ]
}

kubectl 및 JSONPath 표현식을 사용하는 예는 다음과 같다.

kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'

참고:

윈도우에서 공백이 포함된 JSONPath 템플릿을 큰따옴표(위의 bash에 표시된 작은따옴표가 아님)로 묶어야 한다. 즉, 템플릿의 모든 문자 주변에 작은따옴표 또는 이스케이프된 큰따옴표를 사용해야 한다. 예를 들면, 다음과 같다.

kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"

참고:

JSONPath 정규식은 지원되지 않는다. 정규 표현식을 이용해 매치하려면 jq와 같은 도구를 사용하면 된다.

# kubectl은 JSONPath 출력에 대한 정규 표현식을 지원하지 않는다.
# 다음 커맨드는 작동하지 않는다.
kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'

# 다음 커맨드는 원하는 결과를 얻는다.
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'

6.3 - kubectl

시놉시스

kubectl은 쿠버네티스 클러스터 관리자를 제어한다.

자세한 정보는 https://kubernetes.io/docs/reference/kubectl/overview/ 에서 확인한다.

kubectl [flags]

옵션

더 보기

• kubectl annotate - 리소스에 대한 어노테이션 업데이트
• kubectl api-resources - 서버에서 지원되는 API 리소스 출력
• kubectl api-versions - "그룹/버전" 형식으로 서버에서 지원되는 API 버전을 출력
• kubectl apply - 파일명 또는 표준 입력으로 리소스에 구성 적용
• kubectl attach - 실행 중인 컨테이너에 연결
• kubectl auth - 권한 검사
• kubectl autoscale - 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 레플리케이션컨트롤러(ReplicationController) 자동 스케일링
• kubectl certificate - 인증서 리소스 수정
• kubectl cluster-info - 클러스터 정보 표시
• kubectl completion - 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드 출력
• kubectl config - kubeconfig 파일 수정
• kubectl cordon - 노드를 unschedulable로 표시
• kubectl cp - 컨테이너 간에 파일과 디렉터리 복사
• kubectl create - 파일 또는 표준 입력에서 리소스를 생성
• kubectl debug - 워크로드와 노드의 문제 해결을 위한 디버깅 세션 생성
• kubectl delete - 파일명, 표준 입력, 리소스 및 이름, 또는 리소스 및 레이블 셀렉터로 리소스 삭제
• kubectl describe - 특정 리소스 또는 리소스 그룹의 세부 정보를 표시
• kubectl diff - 적용 예정 버전과 라이브 버전 비교
• kubectl drain - 유지 보수 준비 중 노드 드레인
• kubectl edit - 서버에서 리소스 편집
• kubectl exec - 컨테이너에서 커맨드 실행
• kubectl explain - 리소스의 문서
• kubectl expose - 레플리케이션 컨트롤러, 서비스, 디플로이먼트 또는 파드를 가져와서 새로운 쿠버네티스 서비스로 노출
• kubectl get - 하나 이상의 리소스 표시
• kubectl kustomize - 디렉터리 또는 원격 URL에서 kustomization 대상을 빌드
• kubectl label - 리소스의 레이블 업데이트
• kubectl logs - 파드의 컨테이너에 대한 로그 출력
• kubectl options - 모든 커맨드에서 상속된 플래그 목록을 출력
• kubectl patch - 리소스 필드를 업데이트
• kubectl plugin - 플러그인과 상호 작용하기 위한 유틸리티를 제공
• kubectl port-forward - 하나 이상의 로컬 포트를 파드로 전달
• kubectl proxy - 쿠버네티스 API 서버에 대한 프록시 실행
• kubectl replace - 파일명 또는 표준 입력으로 리소스 교체
• kubectl rollout - 리소스 롤아웃 관리
• kubectl run - 클러스터에서 특정 이미지 실행
• kubectl scale - 디플로이먼트, 레플리카셋 또는 레플리케이션 컨트롤러의 새 크기 설정
• kubectl set - 오브젝트에 특정 기능 설정
• kubectl taint - 하나 이상의 노드에서 테인트(taint) 업데이트
• kubectl top - 리소스(CPU/메모리/스토리지) 사용량을 표시
• kubectl uncordon - 노드를 schedulable로 표시
• kubectl version - 클라이언트 및 서버 버전 정보 출력
• kubectl wait - 실험적(experimental) 기능: 하나 이상의 리소스에 대해서 특정 조건이 만족될 때까지 대기(wait)

6.4 - kubectl 사용 규칙

kubectl에 대한 권장 사용 규칙.

재사용 가능한 스크립트에서 kubectl 사용

스크립트의 안정적인 출력을 위해서

• -o name, -o json, -o yaml, -o go-template 혹은 -o jsonpath와 같은 머신 지향(machine-oriented) 출력 양식 중 하나를 요청한다.
• 예를 들어 jobs.v1.batch/myjob과 같이 전체 버전을 사용한다. 이를 통해 kubectl이 시간이 지남에 따라 변경될 수 있는 기본 버전을 사용하지 않도록 한다.
• 문맥, 설정 또는 기타 암묵적 상태에 의존하지 않는다.

모범 사례

kubectl run

kubectl run으로 infrastructure as code를 충족시키기 위해서

• 버전이 명시된 태그로 이미지를 태그하고 그 태그를 새로운 버전으로 이동하지 않는다. 예를 들어, :latest가 아닌 :v1234, v1.2.3, r03062016-1-4를 사용한다(자세한 정보는 구성 모범 사례를 참고한다).
• 많은 파라미터가 적용된 이미지를 위한 스크립트를 작성한다.
• 필요하지만 kubectl run 플래그를 통해 표현할 수 없는 기능은 구성 파일을 소스 코드 버전 관리 시스템에 넣어서 전환한다.

--dry-run 플래그를 사용하여 실제로 제출하지 않고 클러스터로 보낼 오브젝트를 미리 볼 수 있다.

참고: 모든 kubectl run의 생성기(generator)는 더 이상 사용 할 수 없다. 생성기 목록 및 사용 방법은 쿠버네티스 v1.17 문서를 참고한다.

생성기

kubectl create --dry-run -o yaml라는 kubectl 커맨드를 통해 다음과 같은 리소스를 생성할 수 있다.

• clusterrole: 클러스터롤(ClusterRole)를 생성한다.
• clusterrolebinding: 특정 클러스터롤에 대한 클러스터롤바인딩(ClusterRoleBinding)을 생성한다.
• configmap: 로컬 파일, 디렉토리 또는 문자 그대로의 값으로 컨피그맵(ConfigMap)을 생성한다.
• cronjob: 지정된 이름으로 크론잡(CronJob)을 생성한다.
• deployment: 지정된 이름으로 디플로이먼트(Deployment)를 생성한다.
• job: 지정된 이름으로 잡(Job)을 생성한다.
• namespace: 지정된 이름으로 네임스페이스(Namespace)를 생성한다.
• poddisruptionbudget: 지정된 이름으로 PodDisruptionBudget을 생성한다.
• priorityclass: 지정된 이름으로 프라이어리티클래스(PriorityClass)을 생성한다.
• quota: 지정된 이름으로 쿼터(Quota)를 생성한다.
• role: 단일 규칙으로 롤(Role)을 생성한다.
• rolebinding: 특정 롤 또는 클러스터롤에 대한 롤바인딩(RoleBinding)을 생성한다.
• secret: 지정된 하위 커맨드를 사용하여 시크릿(Secret)을 생성한다.
• service: 지정된 하위 커맨드를 사용하여 서비스(Service)를 생성한다.
• serviceaccount: 지정된 이름으로 서비스어카운트(ServiceAccount)을 생성한다.

kubectl apply

• kubectl apply를 사용해서 리소스를 생성하거나 업데이트 할 수 있다. kubectl apply를 사용하여 리소스를 업데이트하는 방법에 대한 자세한 정보는 Kubectl 책을 참고한다.

6.5 - kubectl 치트 시트

이 페이지는 일반적으로 사용하는 kubectl 커맨드와 플래그에 대한 목록을 포함한다.

Kubectl 자동 완성

BASH

source <(kubectl completion bash) # bash-completion 패키지를 먼저 설치한 후, bash의 자동 완성을 현재 셸에 설정한다
echo "source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash 셸에 영구적으로 추가한다

또한, kubectl의 의미로 사용되는 약칭을 사용할 수 있다.

alias k=kubectl
complete -F __start_kubectl k

ZSH

source <(kubectl completion zsh)  # 현재 셸에 zsh의 자동 완성 설정
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다.

Kubectl 컨텍스트와 설정

kubectl이 통신하고 설정 정보를 수정하는 쿠버네티스 클러스터를 지정한다. 설정 파일에 대한 자세한 정보는 kubeconfig를 이용한 클러스터 간 인증 문서를 참고한다.

kubectl config view # 병합된 kubeconfig 설정을 표시한다.

# 동시에 여러 kubeconfig 파일을 사용하고 병합된 구성을 확인한다
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2

kubectl config view

# e2e 사용자의 암호를 확인한다
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl config view -o jsonpath='{.users[].name}'    # 첫 번째 사용자 출력
kubectl config view -o jsonpath='{.users[*].name}'    # 사용자 리스트 조회
kubectl config get-contexts                          # 컨텍스트 리스트 출력
kubectl config current-context              # 현재 컨텍스트 출력
kubectl config use-context my-cluster-name  # my-cluster-name를 기본 컨텍스트로 설정

# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# 해당 컨텍스트에서 모든 후속 kubectl 커맨드에 대한 네임스페이스를 영구적으로 저장한다
kubectl config set-context --current --namespace=ggckad-s2

# 특정 사용자와 네임스페이스를 사용하는 컨텍스트 설정
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce

kubectl config unset users.foo                       # foo 사용자 삭제

Kubectl apply

apply는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. kubectl apply를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. Kubectl Book을 참고한다.

오브젝트 생성

쿠버네티스 매니페스트는 JSON이나 YAML로 정의된다. 파일 확장자는 .yaml , .yml, .json 이 사용된다.

kubectl apply -f ./my-manifest.yaml            # 리소스(들) 생성
kubectl apply -f ./my1.yaml -f ./my2.yaml      # 여러 파일로 부터 생성
kubectl apply -f ./dir                         # dir 내 모든 매니페스트 파일에서 리소스(들) 생성
kubectl apply -f https://git.io/vPieo          # url로부터 리소스(들) 생성
kubectl create deployment nginx --image=nginx  # nginx 단일 인스턴스를 시작

# "Hello World"를 출력하는 잡(Job) 생성
kubectl create job hello --image=busybox -- echo "Hello World"

# 매분마다 "Hello World"를 출력하는 크론잡(CronJob) 생성
kubectl create cronjob hello --image=busybox   --schedule="*/1 * * * *" -- echo "Hello World"    

kubectl explain pods                           # 파드 매니페스트 문서를 조회

# stdin으로 다수의 YAML 오브젝트 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
EOF

# 여러 개의 키로 시크릿 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

리소스 조회 및 찾기

# 기본 출력을 위한 Get 커맨드
kubectl get services                          # 네임스페이스 내 모든 서비스의 목록 조회
kubectl get pods --all-namespaces             # 모든 네임스페이스 내 모든 파드의 목록 조회
kubectl get pods -o wide                      # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회
kubectl get deployment my-dep                 # 특정 디플로이먼트의 목록 조회
kubectl get pods                              # 네임스페이스 내 모든 파드의 목록 조회
kubectl get pod my-pod -o yaml                # 파드의 YAML 조회

# 상세 출력을 위한 Describe 커맨드
kubectl describe nodes my-node
kubectl describe pods my-pod

# Name으로 정렬된 서비스의 목록 조회
kubectl get services --sort-by=.metadata.name

# 재시작 횟수로 정렬된 파드의 목록 조회
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# PersistentVolumes을 용량별로 정렬해서 조회
kubectl get pv --sort-by=.spec.capacity.storage

# app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# 예를 들어 'ca.crt'와 같이 점이 있는 키값을 검색한다
kubectl get configmap myconfig \
  -o jsonpath='{.data.ca\.crt}'

# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/master'
# 으로 명명된 라벨의 결과를 제외)
kubectl get node --selector='!node-role.kubernetes.io/master'

# 네임스페이스의 모든 실행 중인 파드를 조회
kubectl get pods --field-selector=status.phase=Running

# 모든 노드의 외부IP를 조회
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# 특정 RC에 속해있는 파드 이름의 목록 조회
# "jq" 커맨드는 jsonpath를 사용하는 매우 복잡한 변환에 유용하다. https://stedolan.github.io/jq/ 에서 확인할 수 있다.
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# 모든 파드(또는 레이블을 지원하는 다른 쿠버네티스 오브젝트)의 레이블 조회
kubectl get pods --show-labels

# 어떤 노드가 준비됐는지 확인
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# 외부 도구 없이 디코딩된 시크릿 출력
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'

# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# 모든 파드의 초기화 컨테이너(initContainer)의 컨테이너ID 목록 조회
# 초기화 컨테이너(initContainer)를 제거하지 않고 정지된 모든 컨테이너를 정리할 때 유용하다.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

# 타임스탬프로 정렬된 이벤트 목록 조회
kubectl get events --sort-by=.metadata.creationTimestamp

# 매니페스트가 적용된 경우 클러스터의 현재 상태와 클러스터의 상태를 비교한다.
kubectl diff -f ./my-manifest.yaml

# 노드에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
# 복잡한 중첩 JSON 구조 내에서 키를 찾을 때 유용하다.
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'

# 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다.
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'

리소스 업데이트

kubectl set image deployment/frontend www=image:v2               # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트
kubectl rollout history deployment/frontend                      # 현 리비전을 포함한 디플로이먼트의 이력을 체크
kubectl rollout undo deployment/frontend                         # 이전 디플로이먼트로 롤백
kubectl rollout undo deployment/frontend --to-revision=2         # 특정 리비전으로 롤백
kubectl rollout status -w deployment/frontend                    # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시
kubectl rollout restart deployment/frontend                      # "frontend" 디플로이먼트의 롤링 재시작


cat pod.json | kubectl replace -f -                              # std로 전달된 JSON을 기반으로 파드 교체

# 리소스를 강제 교체, 삭제 후 재생성함. 이것은 서비스를 중단시킴.
kubectl replace --force -f ./pod.json

# 복제된 nginx를 위한 서비스를 생성한다. 80 포트로 서비스하고, 컨테이너는 8000 포트로 연결한다.
kubectl expose rc nginx --port=80 --target-port=8000

# 단일-컨테이너 파드의 이미지 버전(태그)을 v4로 업데이트
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # 레이블 추가
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # 어노테이션 추가
kubectl autoscale deployment foo --min=2 --max=10                # 디플로이먼트 "foo" 오토스케일

리소스 패치

kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 노드를 부분적으로 업데이트

# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요.
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트.
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화.
kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# 위치 배열에 새 요소 추가
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

리소스 편집

편집기로 모든 API 리소스를 편집.

kubectl edit svc/docker-registry                      # docker-registry라는 서비스 편집
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # 다른 편집기 사용

리소스 스케일링

kubectl scale --replicas=3 rs/foo                                 # 'foo'라는 레플리카셋을 3으로 스케일
kubectl scale --replicas=3 -f foo.yaml                            # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # 여러 개의 레플리케이션 컨트롤러 스케일

리소스 삭제

kubectl delete -f ./pod.json                                              # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제
kubectl delete pod,service baz foo                                        # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel                              # name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl delete pods,services -l name=myLabel --include-uninitialized      # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제
kubectl -n my-ns delete pod,svc --all                                      # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제
# awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

실행 중인 파드와 상호 작용

kubectl logs my-pod                                 # 파드 로그 덤프 (stdout)
kubectl logs -l name=myLabel                        # name이 myLabel인 파드 로그 덤프 (stdout)
kubectl logs my-pod --previous                      # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout)
kubectl logs my-pod -c my-container                 # 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
kubectl logs -l name=myLabel -c my-container        # name이 myLabel인 파드 로그 덤프 (stdout)
kubectl logs my-pod -c my-container --previous      # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그 덤프 (stdout, 멀티-컨테이너 경우)
kubectl logs -f my-pod                              # 실시간 스트림 파드 로그(stdout)
kubectl logs -f my-pod -c my-container              # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우)
kubectl logs -f -l name=myLabel --all-containers    # name이 myLabel인 모든 파드의 로그 스트리밍 (stdout)
kubectl run -i --tty busybox --image=busybox -- sh  # 대화형 셸로 파드를 실행
kubectl run nginx --image=nginx -n
mynamespace                                         # 특정 네임스페이스에서 nginx 파드 실행
kubectl run nginx --image=nginx                     # nginx 파드를 실행하고 해당 스펙을 pod.yaml 파일에 기록
--dry-run=client -o yaml > pod.yaml

kubectl attach my-pod -i                            # 실행 중인 컨테이너에 연결
kubectl port-forward my-pod 5000:6000               # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달
kubectl exec my-pod -- ls /                         # 기존 파드에서 명령 실행(한 개 컨테이너 경우)
kubectl exec --stdin --tty my-pod -- /bin/sh        # 실행 중인 파드로 대화형 셸 액세스(1 컨테이너 경우)
kubectl exec my-pod -c my-container -- ls /         # 기존 파드에서 명령 실행(멀티-컨테이너 경우)
kubectl top pod POD_NAME --containers               # 특정 파드와 해당 컨테이너에 대한 메트릭 표시
kubectl top pod POD_NAME --sort-by=cpu              # 지정한 파드에 대한 메트릭을 표시하고 'cpu' 또는 'memory'별로 정렬

디플로이먼트, 서비스와 상호 작용

kubectl logs deploy/my-deployment                         # 디플로이먼트에 대한 파드 로그 덤프 (단일-컨테이너 경우)
kubectl logs deploy/my-deployment -c my-container         # 디플로이먼트에 대한 파드 로그 덤프 (멀티-컨테이너 경우)

kubectl port-forward svc/my-service 5000                  # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 동일한(5000번) 포트로 전달
kubectl port-forward svc/my-service 5000:my-service-port  # 로컬 머신의 5000번 포트를 리스닝하고, my-service의 <my-service-port> 라는 이름을 가진 포트로 전달

kubectl port-forward deploy/my-deployment 5000:6000       # 로컬 머신의 5000번 포트를 리스닝하고, <my-deployment> 에 의해 생성된 파드의 6000번 포트로 전달
kubectl exec deploy/my-deployment -- ls                   # <my-deployment> 에 의해 생성된 첫번째 파드의 첫번째 컨테이너에 명령어 실행 (단일- 또는 다중-컨테이너 경우)

노드, 클러스터와 상호 작용

kubectl cordon my-node                                                # my-node를 스케줄링할 수 없도록 표기
kubectl drain my-node                                                 # 유지 보수를 위해서 my-node를 준비 상태로 비움
kubectl uncordon my-node                                              # my-node를 스케줄링할 수 있도록 표기
kubectl top node my-node                                              # 주어진 노드에 대한 메트릭 표시
kubectl cluster-info                                                  # 마스터 및 서비스의 주소 표시
kubectl cluster-info dump                                             # 현재 클러스터 상태를 stdout으로 덤프
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프

# key와 effect가 있는 테인트(taint)가 이미 존재하면, 그 값이 지정된 대로 대체된다.
kubectl taint nodes foo dedicated=special-user:NoSchedule

리소스 타입

단축명, API 그룹과 함께 지원되는 모든 리소스 유형들, 그것들의 네임스페이스와 종류(Kind)를 나열:

kubectl api-resources

API 리소스를 탐색하기 위한 다른 작업:

kubectl api-resources --namespaced=true      # 네임스페이스를 가지는 모든 리소스
kubectl api-resources --namespaced=false     # 네임스페이스를 가지지 않는 모든 리소스
kubectl api-resources -o name                # 모든 리소스의 단순한 (리소스 이름만) 출력
kubectl api-resources -o wide                # 모든 리소스의 확장된 ("wide"로 알려진) 출력
kubectl api-resources --verbs=list,get       # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력
kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스

출력 형식 지정

특정 형식으로 터미널 창에 세부 사항을 출력하려면, 지원되는 kubectl 명령에 -o (또는 --output) 플래그를 추가한다.

-o=custom-columns 의 사용 예시:

# 클러스터에서 실행 중인 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'

# `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력
kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image"

# "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'

# 이름에 관계없이 메타데이터 아래의 모든 필드
kubectl get pods -A -o=custom-columns='DATA:metadata.*'

더 많은 예제는 kubectl 참조 문서를 참고한다.

Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅

Kubectl 로그 상세 레벨(verbosity)은 -v 또는--v 플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 여기에 설명되어 있다.

다음 내용

• kubectl 개요를 읽고 JsonPath에 대해 배워보자.

• kubectl 옵션을 참고한다.

• 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 kubectl 사용법을 참고한다.

• 더 많은 커뮤니티 kubectl 치트시트를 확인한다.

6.6 - 도커 사용자를 위한 kubectl

당신은 쿠버네티스 커맨드 라인 도구인 kubectl을 사용하여 API 서버와 상호 작용할 수 있다. 만약 도커 커맨드 라인 도구에 익숙하다면 kubectl을 사용하는 것은 간단하다. 다음 섹션에서는 도커의 하위 명령을 보여주고 kubectl과 같은 명령어를 설명한다.

docker run

nginx 디플로이먼트(Deployment)를 실행하고 해당 디플로이먼트를 노출시키려면, kubectl create deployment을 참고한다. docker:

docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx

55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   9 seconds ago       Up 9 seconds        0.0.0.0:80->80/tcp   nginx-app

kubectl:

# nginx 실행하는 파드를 시작한다
kubectl create deployment --image=nginx nginx-app

deployment.apps/nginx-app created

# nginx-app 에 env를 추가한다
kubectl set env deployment/nginx-app  DOMAIN=cluster

deployment.apps/nginx-app env updated

참고: kubectl 커맨드는 생성되거나 변경된 리소스의 유형과 이름을 출력하므로, 이를 후속 커맨드에 사용할 수 있다. 디플로이먼트가 생성된 후에는 새로운 서비스를 노출할 수 있다.

# 서비스를 통해 포트를 노출
kubectl expose deployment nginx-app --port=80 --name=nginx-http

service "nginx-http" exposed

kubectl을 사용하면, N개의 파드가 nginx를 실행하도록 디플로이먼트를 생성할 수 있다. 여기서 N은 스펙에 명시된 레플리카 수이며, 기본값은 1이다. 또한 파드의 레이블과 셀럭터를 사용하여 서비스를 생성할 수 있다. 자세한 내용은 클러스터 내 애플리케이션에 접근하기 위해 서비스 사용하기를 참고한다.

기본적으로 이미지는 docker run -d ... 와 비슷하게 백그라운드로 실행된다. 포그라운드로 실행하려면 kubectl run을 이용하여 파드를 생성한다.

kubectl run [-i] [--tty] --attach <name> --image=<image>

docker run ... 과 달리 --attach 를 지정하면 표준 입력(stdin), 표준 출력(stdout) 및 표준 오류(stderr)가 붙는다. 연결된(attached) 스트림을 제어할 수 없다(docker -a ...). 해당 컨테이너에서 분리(detach)하려면 이스케이프 시퀀스(escape sequence) Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.

docker ps

현재 실행 중인 목록을 보기 위해서는 kubectl get을 참고한다.

docker:

docker ps -a

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                     PORTS                NAMES
14636241935f        ubuntu:16.04        "echo test"              5 seconds ago        Exited (0) 5 seconds ago                        cocky_fermi
55c103fa1296        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute          0.0.0.0:80->80/tcp   nginx-app

kubectl:

kubectl get po

NAME                        READY     STATUS      RESTARTS   AGE
nginx-app-8df569cb7-4gd89   1/1       Running     0          3m
ubuntu                      0/1       Completed   0          20s

docker attach

이미 실행 중인 컨테이너에 연결하려면 kubectl attach를 참고한다.

docker:

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   5 minutes ago       Up 5 minutes        0.0.0.0:80->80/tcp   nginx-app

docker attach 55c103fa1296
...

kubectl:

kubectl get pods

NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m

kubectl attach -it nginx-app-5jyvm
...

컨테이너에서 분리하려면 이스케이프 시퀀스 Ctrl+P를 입력한 다음 Ctrl+Q를 입력한다.

docker exec

컨테이너에서 커맨드를 실행하려면 kubectl exec를 참고한다.

docker:

docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   6 minutes ago       Up 6 minutes        0.0.0.0:80->80/tcp   nginx-app

docker exec 55c103fa1296 cat /etc/hostname

55c103fa1296

kubectl:

kubectl get po

NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m

kubectl exec nginx-app-5jyvm -- cat /etc/hostname

nginx-app-5jyvm

대화형 커맨드를 사용한다.

docker:

docker exec -ti 55c103fa1296 /bin/sh
# exit

kubectl:

kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit

자세한 내용은 실행 중인 컨테이너의 셸 얻기를 참고한다.

docker logs

실행 중인 프로세스의 표준 입력(stdout)/표준 오류(stderr)를 수행하려면 kubectl logs를 참고한다.

docker:

docker logs -f a9e

192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"

kubectl:

kubectl logs -f nginx-app-zibvs

10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

파드와 컨테이너에는 근소한 차이가 있다. 기본적으로 파드는 프로세스가 종료되어도 종료되지 않는다. 대신 파드가 프로세스를 다시 시작한다. 이는 도커의 실행 옵션인 --restart=always와 유사하지만, 한 가지 큰 차이점이 있다. 도커에서는 프로세스의 각 호출에 대한 출력이 연결되지만, 쿠버네티스의 경우 각 호출은 별개다. 쿠버네티스에서 이전 실행의 출력 내용을 보려면 다음을 수행한다.

kubectl logs --previous nginx-app-zibvs

10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

자세한 정보는 로깅 아키텍처를 참고한다.

docker stop 과 docker rm

실행 중인 프로세스를 중지하고 삭제하려면 kubectl delete을 참고한다.

docker:

docker ps

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                         NAMES
a9ec34d98787        nginx               "nginx -g 'daemon of"  22 hours ago        Up 22 hours         0.0.0.0:80->80/tcp, 443/tcp   nginx-app

docker stop a9ec34d98787

a9ec34d98787

docker rm a9ec34d98787

a9ec34d98787

kubectl:

kubectl get deployment nginx-app

NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-app    1/1     1            1           2m

kubectl get po -l run=nginx-app

NAME                         READY     STATUS    RESTARTS   AGE
nginx-app-2883164633-aklf7   1/1       Running   0          2m

kubectl delete deployment nginx-app

deployment "nginx-app" deleted

kubectl get po -l run=nginx-app
# 아무것도 반환하지 않는다

참고: kubectl을 사용할 때는 파드를 직접 삭제하지 않는다. 먼저 파드를 소유한 디플로이먼트를 삭제해야 한다. 만약 파드를 직접 삭제하면 디플로이먼트가 파드를 재생성할 것이다.

docker login

kubectl은 docker login와 직접적인 유사점은 없다. 프라이빗 레지스트리와 함께 쿠버네티스를 사용하려면 프라이빗 레지스트리 사용을 참고한다.

docker version

클라이언트와 서버의 버전을 가져오려면 kubectl version을 참고한다.

docker:

docker version

Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

kubectl:

kubectl version

Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

docker info

환경 및 설정에 대한 자세한 정보는 kubectl cluster-info를 참고한다.

docker:

docker info

Containers: 40
Images: 168
Storage Driver: aufs
 Root Dir: /usr/local/google/docker/aufs
 Backing Filesystem: extfs
 Dirs: 248
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support

kubectl:

kubectl cluster-info

Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy

7 - 컴포넌트 도구

7.1 - 기능 게이트

이 페이지에는 관리자가 다른 쿠버네티스 컴포넌트에서 지정할 수 있는 다양한 기능 게이트에 대한 개요가 포함되어 있다.

기능의 단계(stage)에 대한 설명은 기능 단계를 참고한다.

개요

기능 게이트는 쿠버네티스 기능을 설명하는 일련의 키=값 쌍이다. 각 쿠버네티스 컴포넌트에서 --feature-gates 커맨드 라인 플래그를 사용하여 이러한 기능을 켜거나 끌 수 있다.

각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을 활성화 또는 비활성화할 수 있다. 모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 -h 플래그를 사용한다. kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 --feature-gates 플래그를 사용한다.

--feature-gates="...,DynamicKubeletConfig=true"

다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를 요약한 것이다.

• "도입" 열에는 기능이 소개되거나 릴리스 단계가 변경될 때의 쿠버네티스 릴리스가 포함된다.
• "종료" 열이 비어 있지 않으면, 여전히 기능 게이트를 사용할 수 있는 마지막 쿠버네티스 릴리스가 포함된다.
• 기능이 알파 또는 베타 상태인 경우, 알파/베타 기능 게이트 테이블에서 나열된 기능을 찾을 수 있다.
• 기능이 안정된 경우 해당 기능에 대한 모든 단계를 GA(graduated)/사용 중단(deprecated) 기능 게이트 테이블에 나열할 수 있다.
• GA/사용 중단 기능 게이트 테이블에는 사용 중단된 기능과 철회(withdrawn) 기능의 목록도 있다.

알파 또는 베타 기능을 위한 기능 게이트

GA 또는 사용 중단된 기능을 위한 기능 게이트

기능 사용

기능 단계

기능은 알파, 베타 또는 GA 단계일 수 있다. 알파 기능은 다음을 의미한다.

• 기본적으로 비활성화되어 있다.
• 버그가 있을 수 있다. 이 기능을 사용하면 버그에 노출될 수 있다.
• 기능에 대한 지원은 사전 통지없이 언제든지 중단될 수 있다.
• API는 이후 소프트웨어 릴리스에서 예고없이 호환되지 않는 방식으로 변경될 수 있다.
• 버그의 위험이 증가하고 장기 지원이 부족하여, 단기 테스트 클러스터에서만 사용하는 것이 좋다.

베타 기능은 다음을 의미한다.

• 기본적으로 활성화되어 있다.
• 이 기능은 잘 테스트되었다. 이 기능을 활성화하면 안전한 것으로 간주된다.
• 세부 내용은 변경될 수 있지만, 전체 기능에 대한 지원은 중단되지 않는다.
• 오브젝트의 스키마 및/또는 시맨틱은 후속 베타 또는 안정 릴리스에서 호환되지 않는 방식으로 변경될 수 있다. 이러한 상황이 발생하면, 다음 버전으로 마이그레이션하기 위한 지침을 제공한다. API 오브젝트를 삭제, 편집 및 재작성해야 할 수도 있다. 편집 과정에서 약간의 생각이 필요할 수 있다. 해당 기능에 의존하는 애플리케이션의 경우 다운타임이 필요할 수 있다.
• 후속 릴리스에서 호환되지 않는 변경이 발생할 수 있으므로 업무상 중요하지 않은(non-business-critical) 용도로만 권장한다. 독립적으로 업그레이드할 수 있는 여러 클러스터가 있는 경우, 이 제한을 완화할 수 있다.

참고: 베타 기능을 사용해 보고 의견을 보내주길 바란다! 베타 기간이 종료된 후에는, 더 많은 변경을 하는 것이 실용적이지 않을 수 있다.

GA(General Availability) 기능은 안정 기능이라고도 한다. 이 의미는 다음과 같다.

• 이 기능은 항상 활성화되어 있다. 비활성화할 수 없다.
• 해당 기능 게이트는 더 이상 필요하지 않다.
• 여러 후속 버전의 릴리스된 소프트웨어에 안정적인 기능의 버전이 포함된다.

기능 게이트 목록

각 기능 게이트는 특정 기능을 활성화/비활성화하도록 설계되었다.

• APIListChunking: API 클라이언트가 API 서버에서 (LIST 또는 GET) 리소스를 청크(chunks)로 검색할 수 있도록 한다.
• APIPriorityAndFairness: 각 서버의 우선 순위와 공정성을 통해 동시 요청을 관리할 수 있다. (RequestManagement 에서 이름이 변경됨)
• APIResponseCompression: LIST 또는 GET 요청에 대한 API 응답을 압축한다.
• APIServerIdentity: 클러스터의 각 API 서버에 ID를 할당한다.
• Accelerators: 도커 사용 시 Nvidia GPU 지원 활성화한다.
• AdvancedAuditing: 고급 감사 기능을 활성화한다.
• AffinityInAnnotations(사용 중단됨): 파드 어피니티 또는 안티-어피니티 설정을 활성화한다.
• AllowExtTrafficLocalEndpoints: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다.
• AllowInsecureBackendProxy: 사용자가 파드 로그 요청에서 kubelet의 TLS 확인을 건너뛸 수 있도록 한다.
• AnyVolumeDataSource: PVC의 DataSource 로 모든 사용자 정의 리소스 사용을 활성화한다.
• AppArmor: 도커를 사용할 때 리눅스 노드에서 AppArmor 기반의 필수 접근 제어를 활성화한다. 자세한 내용은 AppArmor 튜토리얼을 참고한다.
• AttachVolumeLimit: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 대한 제한을 보고하도록 한다. 자세한 내용은 동적 볼륨 제한을 참고한다.
• BalanceAttachedNodeVolumes: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 더 가까운 노드가 선호된다.
• BlockVolume: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. 자세한 내용은 원시 블록 볼륨 지원을 참고한다.
• BoundServiceAccountTokenVolume: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 마이그레이션한다. 클러스터 관리자는 serviceaccount_stale_tokens_total 메트릭을 사용하여 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 --service-account-extend-token-expiration=false 플래그로 kube-apiserver를 시작하여 확장 토큰 기능을 끈다. 자세한 내용은 바운드 서비스 계정 토큰을 확인한다.
• CPUManager: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. CPU 관리 정책을 참고한다.
• CRIContainerLogRotation: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
• CSIBlockVolume: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 csi 원시 블록 볼륨 지원 문서를 참고한다.
• CSIDriverRegistry: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 모든 로직을 활성화한다.
• CSIInlineVolume: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다.
• CSIMigration: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
• CSIMigrationAWS: shim 및 변환 로직을 통해 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에 EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로 폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다.
• CSIMigrationAWSComplete: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
• CSIMigrationAzureDisk: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
• CSIMigrationAzureDiskComplete: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
• CSIMigrationAzureFile: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
• CSIMigrationAzureFileComplete: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
• CSIMigrationGCE: shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
• CSIMigrationGCEComplete: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
• CSIMigrationOpenStack: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
• CSIMigrationOpenStackComplete: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
• CSIMigrationvSphere: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다.
• CSIMigrationvSphereComplete: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
• CSINodeInfo: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
• CSIPersistentVolume: CSI (Container Storage Interface) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 마운트할 수 있다.
• CSIServiceAccountToken : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록 CSI 드라이버를 활성화한다. 토큰 요청을 참조한다.
• CSIStorageCapacity: CSI 드라이버가 스토리지 용량 정보를 게시하고 쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다. 스토리지 용량을 참고한다. 자세한 내용은 csi 볼륨 유형 문서를 확인한다.
• CSIVolumeFSGroupPolicy: CSI드라이버가 fsGroupPolicy 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다.
• ConfigurableFSGroupPolicy: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 파드의 볼륨 권한 및 소유권 변경 정책 구성을 참고한다.
• CronJobControllerV2: 크론잡(CronJob) 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면, 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
• CustomCPUCFSQuotaPeriod: kubelet config에서 cpuCFSQuotaPeriod 를 노드가 변경할 수 있도록 한다.
• CustomPodDNS: dnsConfig 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. 자세한 내용은 파드의 DNS 설정을 확인한다.
• CustomResourceDefaulting: OpenAPI v3 유효성 검사 스키마에서 기본값에 대한 CRD 지원을 활성화한다.
• CustomResourcePublishOpenAPI: CRD OpenAPI 사양을 게시할 수 있다.
• CustomResourceSubresources: 커스텀리소스데피니션에서 생성된 리소스에서 /status 및 /scale 하위 리소스를 활성화한다.
• CustomResourceValidation: 커스텀리소스데피니션에서 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다.
• CustomResourceWebhookConversion: 커스텀리소스데피니션에서 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
• DefaultPodTopologySpread: PodTopologySpread 스케줄링 플러그인을 사용하여 기본 분배를 수행한다.
• DevicePlugins: 노드에서 장치 플러그인 기반 리소스 프로비저닝을 활성화한다.
• DisableAcceleratorUsageMetrics: kubelet이 수집한 액셀러레이터 지표 비활성화.
• DownwardAPIHugePages: 다운워드 API에서 hugepages 사용을 활성화한다.
• DryRun: 서버 측의 dry run 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
• DynamicAuditing(사용 중단됨): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
• DynamicKubeletConfig: kubelet의 동적 구성을 활성화한다. kubelet 재구성을 참고한다.
• DynamicProvisioningScheduling: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다. 이 기능은 v1.12의 VolumeScheduling 기능으로 대체되었다.
• DynamicVolumeProvisioning(사용 중단됨): 파드에 퍼시스턴트 볼륨의 동적 프로비저닝을 활성화한다.
• EfficientWatchResumption: 스토리지에서 생성된 북마크(진행 알림) 이벤트를 사용자에게 전달할 수 있다. 이것은 감시 작업에만 적용된다.
• EnableAggregatedDiscoveryTimeout (사용 중단됨): 수집된 검색 호출에서 5초 시간 초과를 활성화한다.
• EnableEquivalenceClassCache: 스케줄러가 파드를 스케줄링할 때 노드의 동등성을 캐시할 수 있게 한다.
• EndpointSlice: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 엔드포인트슬라이스(EndpointSlices)를 활성화한다. 엔드포인트슬라이스 활성화를 참고한다.
• EndpointSliceNodeName : 엔드포인트슬라이스 nodeName 필드를 활성화한다.
• EndpointSliceProxying: 활성화되면, 리눅스에서 실행되는 kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. 엔드포인트 슬라이스 활성화를 참고한다.
• EndpointSliceTerminatingCondition: 엔드포인트슬라이스 terminating 및 serving 조건 필드를 활성화한다.
• EphemeralContainers: 파드를 실행하기 위한 임시 컨테이너를 추가할 수 있다.
• EvenPodsSpread: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다. 파드 토폴로지 분배 제약 조건을 참고한다.
• ExecProbeTimeout : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다. 이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한 현재 수정된 결함에 의존하는 경우 존재한다. 준비성 프로브를 참조한다.
• ExpandCSIVolumes: CSI 볼륨 확장을 활성화한다.
• ExpandInUsePersistentVolumes: 사용 중인 PVC를 확장할 수 있다. 사용 중인 퍼시스턴트볼륨클레임 크기 조정을 참고한다.
• ExpandPersistentVolumes: 퍼시스턴트 볼륨 확장을 활성화한다. 퍼시스턴트 볼륨 클레임 확장을 참고한다.
• ExperimentalCriticalPodAnnotation: 특정 파드에 critical 로 어노테이션을 달아서 스케줄링이 보장되도록 한다. 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
• ExperimentalHostUserNamespaceDefaultingGate: 사용자 네임스페이스를 호스트로 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: MKNODE, SYS_MODULE 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다.
• GCERegionalPersistentDisk: GCE에서 지역 PD 기능을 활성화한다.
• GenericEphemeralVolume: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). 임시 볼륨을 참고한다.
• GracefulNodeShutdown : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행 중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 Graceful Node Shutdown을 참조한다.
• HPAContainerMetrics: HorizontalPodAutoscaler를 활성화하여 대상 파드의 개별 컨테이너 메트릭을 기반으로 확장한다.
• HPAScaleToZero: 사용자 정의 또는 외부 메트릭을 사용할 때 HorizontalPodAutoscaler 리소스에 대해 minReplicas 를 0으로 설정한다.
• HugePages: 사전 할당된 huge page의 할당 및 사용을 활성화한다.
• HugePageStorageMediumSize: 사전 할당된 huge page의 여러 크기를 지원한다.
• HyperVContainer: 윈도우 컨테이너를 위한 Hyper-V 격리 기능을 활성화한다.
• IPv6DualStack: IPv6에 대한 듀얼 스택 지원을 활성화한다.
• ImmutableEphemeralVolumes: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다.
• KubeletConfigFile: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다. 자세한 내용은 구성 파일을 통해 kubelet 파라미터 설정을 참고한다.
• KubeletCredentialProviders: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
• KubeletPluginsWatcher: kubelet이 CSI 볼륨 드라이버와 같은 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
• KubeletPodResources: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 장치 모니터링 지원을 참고한다.
• LegacyNodeRoleBehavior: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 NodeDisruptionExclusion 과 ServiceNodeExclusion 에 의해 제공된 기능별 레이블을 대신하여 node-role.kubernetes.io/master 레이블을 무시한다.
• LocalStorageCapacityIsolation: 로컬 임시 스토리지와 emptyDir 볼륨의 sizeLimit 속성을 사용할 수 있게 한다.
• LocalStorageCapacityIsolationFSQuotaMonitoring: 로컬 임시 스토리지에 LocalStorageCapacityIsolation 이 활성화되고 emptyDir 볼륨의 백업 파일시스템이 프로젝트 쿼터를 지원하고 활성화된 경우, 파일시스템 사용보다는 프로젝트 쿼터를 사용하여 emptyDir 볼륨 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다.
• MixedProtocolLBService: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다.
• MountContainers (사용 중단됨): 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
• MountPropagation: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. 자세한 내용은 마운트 전파(propagation)을 참고한다.
• NodeDisruptionExclusion: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 node.kubernetes.io/exclude-disruption 사용을 활성화한다.
• NodeLease: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
• NonPreemptingPriority: 프라이어리티클래스(PriorityClass)와 파드에 preemptionPolicy 필드를 활성화한다.
• PVCProtection: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 삭제되지 않도록 한다.
• PersistentLocalVolumes: 파드에서 local 볼륨 유형의 사용을 활성화한다. local 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
• PodDisruptionBudget: PodDisruptionBudget 기능을 활성화한다.
• PodOverhead: 파드 오버헤드를 판단하기 위해 파드오버헤드(PodOverhead) 기능을 활성화한다.
• PodPriority: 우선 순위를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다.
• PodReadinessGates: 파드 준비성 평가를 확장하기 위해 PodReadinessGate 필드 설정을 활성화한다. 자세한 내용은 파드의 준비성 게이트를 참고한다.
• PodShareProcessNamespace: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 공유하기 위해 파드에서 shareProcessNamespace 설정을 활성화한다. 자세한 내용은 파드의 컨테이너 간 프로세스 네임스페이스 공유에서 확인할 수 있다.
• ProcMountType: SecurityContext의 procMount 필드를 설정하여 컨테이너의 proc 타입의 마운트를 제어할 수 있다.
• QOSReserved: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다 (현재 메모리만 해당).
• RemainingItemCount: API 서버가 청크(chunking) 목록 요청에 대한 응답에서 남은 항목 수를 표시하도록 허용한다.
• RemoveSelfLink: ObjectMeta 및 ListMeta에서 selfLink 를 사용하지 않고 제거한다.
• ResourceLimitsPriorityFunction (사용 중단됨): 입력 파드의 CPU 및 메모리 한도 중 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 노드 사이의 관계를 끊는 것이다.
• ResourceQuotaScopeSelectors: 리소스 쿼터 범위 셀렉터를 활성화한다.
• RootCAConfigMap: 모든 네임스페이스에 kube-root-ca.crt라는 컨피그맵을 게시하도록 kube-controller-manager 를 구성한다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다. 자세한 내용은 바운드 서비스 계정 토큰을 참조한다.
• RotateKubeletClientCertificate: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. 자세한 내용은 kubelet 구성을 참고한다.
• RotateKubeletServerCertificate: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
• RunAsGroup: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다.
• RuntimeClass: 컨테이너 런타임 구성을 선택하기 위해 런타임클래스(RuntimeClass) 기능을 활성화한다.
• ScheduleDaemonSetPods: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다.
• SCTPSupport: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 SCTP protocol 값을 활성화한다.
• ServerSideApply: API 서버에서 SSA(Sever Side Apply) 경로를 활성화한다.
• ServiceAccountIssuerDiscovery: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 파드의 서비스 어카운트 구성을 참고한다.
• ServiceAppProtocol: 서비스와 엔드포인트에서 AppProtocol 필드를 활성화한다.
• ServiceLBNodePortControl: 서비스에서spec.allocateLoadBalancerNodePorts 필드를 활성화한다.
• ServiceLoadBalancerFinalizer: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
• ServiceNodeExclusion: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. "node.kubernetes.io/exclude-from-external-load-balancers"로 레이블이 지정된 경우 노드를 제외할 수 있다.
• ServiceTopology: 서비스가 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅할 수 있도록 한다. 자세한 내용은 서비스토폴로지(ServiceTopology)를 참고한다.
• SetHostnameAsFQDN: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. 파드의 setHostnameAsFQDN 필드를 참고한다.
• StartupProbe: kubelet에서 스타트업 프로브를 활성화한다.
• StorageObjectInUseProtection: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 사용 중인 경우 삭제를 연기한다.
• StorageVersionAPI: 스토리지 버전 API를 활성화한다.
• StorageVersionHash: API 서버가 디스커버리에서 스토리지 버전 해시를 노출하도록 허용한다.
• StreamingProxyRedirects: 스트리밍 요청을 위해 백엔드(kubelet)에서 리디렉션을 가로채서 따르도록 API 서버에 지시한다. 스트리밍 요청의 예로는 exec, attach 및 port-forward 요청이 있다.
• SupportIPVSProxyMode: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. 자세한 내용은 서비스 프록시를 참고한다.
• SupportPodPidsLimit: 파드의 PID 제한을 지원한다.
• SupportNodePidsLimit: 노드에서 PID 제한 지원을 활성화한다. --system-reserved 및 --kube-reserved 옵션의 pid=<number> 파라미터를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다.
• Sysctls: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. 자세한 내용은 sysctl을 참고한다.
• TTLAfterFinished: TTL 컨트롤러가 실행이 끝난 후 리소스를 정리하도록 허용한다.
• TaintBasedEvictions: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다. 자세한 내용은 테인트와 톨러레이션을 참고한다.
• TaintNodesByCondition: 노드 컨디션을 기반으로 자동 테인트 노드를 활성화한다.
• TokenRequest: 서비스 어카운트 리소스에서 TokenRequest 엔드포인트를 활성화한다.
• TokenRequestProjection: projected 볼륨을 통해 서비스 어카운트 토큰을 파드에 주입할 수 있다.
• TopologyManager: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. 노드의 토폴로지 관리 정책 제어를 참고한다.
• VolumePVCDataSource: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다.
• VolumeScheduling: 볼륨 토폴로지 인식 스케줄링을 활성화하고 퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한 PersistentLocalVolumes 기능 게이트와 함께 사용될 때 local 볼륨 유형을 사용할 수 있다.
• VolumeSnapshotDataSource: 볼륨 스냅샷 데이터 소스 지원을 활성화한다.
• VolumeSubpathEnvExpansion: 환경 변수를 subPath로 확장하기 위해 subPathExpr 필드를 활성화한다.
• WarningHeaders: API 응답에서 경고 헤더를 보낼 수 있다.
• WatchBookmark: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다.
• WinDSR: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
• WinOverlay: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
• WindowsGMSA: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
• WindowsRunAsUserName : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은 RunAsUserName 구성을 참고한다.
• WindowsEndpointSliceProxying: 활성화되면, 윈도우에서 실행되는 kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. 엔드포인트 슬라이스 활성화하기를 참고한다.

다음 내용

• 사용 중단 정책은 쿠버네티스에 대한 기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다.

7.2 - kube-proxy

시놉시스

쿠버네티스 네트워크 프록시는 각 노드에서 실행된다. 이는 각 노드의 쿠버네티스 API에 정의된 서비스를 반영하며 단순한 TCP, UDP 및 SCTP 스트림 포워딩 또는 라운드 로빈 TCP, UDP 및 SCTP 포워딩을 백엔드 셋에서 수행 할 수 있다. 서비스 클러스트 IP 및 포트는 현재 서비스 프록시에 의해 열린 포트를 지정하는 Docker-links-compatible 환경 변수를 통해 찾을 수 있다. 이러한 클러스터 IP에 클러스터 DNS를 제공하는 선택적 애드온이 있다. 유저는 apiserver API로 서비스를 생성하여 프록시를 구성해야 한다.

kube-proxy [flags]

옵션

7.3 - Kubelet 인증/인가

개요

kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며, 노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다.

이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다.

Kubelet 인증

기본적으로, 다른 구성의 인증 방법에 의해 거부되지 않은 kubelet의 HTTPS 엔드포인트에 대한 요청은 익명의 요청으로 처리되며, system:anonymous의 사용자 이름과 system:unauthenticated 의 그룹이 부여된다.

익명의 접근을 비활성화하고 인증되지 않은 요청에 401 Unauthorized 응답을 보내려면 아래를 참고한다.

• --anonymous-auth=false 플래그로 kubelet을 시작

kubelet의 HTTPS 엔드포인트에 대한 X509 클라이언트 인증서 인증을 활성화하려면 아래를 참고한다.

• --client-ca-file 플래그로 kubelet을 시작하면 클라이언트 인증서를 확인할 수 있는 CA 번들을 제공
• --kubelet-client-certificate 및 --kubelet-client-key 플래그로 apiserver를 시작
• 자세한 내용은 apiserver 인증 문서를 참고

API bearer 토큰(서비스 계정 토큰 포함)을 kubelet의 HTTPS 엔드포인트 인증에 사용하려면 아래를 참고한다.

• API 서버에서 authentication.k8s.io/v1beta1 API 그룹이 사용 가능한지 확인
• --authentication-token-webhook 및 --kubeconfig 플래그로 kubelet을 시작
• kubelet은 구성된 API 서버의 TokenReview API를 호출하여 bearer 토큰에서 사용자 정보를 결정

Kubelet 승인

성공적으로 인증된 모든 요청(익명 요청 포함)이 승인된다. 기본 인가 모드는 모든 요청을 허용하는 AlwaysAllow 이다.

kubelet API에 대한 접근을 세분화하는 데는 다양한 이유가 있다.

• 익명 인증을 사용할 수 있지만, 익명 사용자의 kubelet API 호출 기능은 제한되어야 함
• bearer 토큰 인증을 사용할 수 있지만, 임의의 API 사용자(API 계정)의 kubelet API 호출 기능은 제한되어야 함
• 클라이언트 인증을 사용할 수 있지만, 구성된 CA에서 서명한 일부 클라이언트 인증서만 kubelet API를 사용하도록 허용해야 함

kubelet API에 대한 접근을 세분화하려면 API 서버에 권한을 위임한다.

• authorization.k8s.io/v1beta1 API 그룹이 API 서버에서 사용 가능한지 확인
• --authorization-mode=Webhook 및 --kubeconfig 플래그로 kubelet을 시작
• kubelet은 구성된 API 서버의 SubjectAccessReview API를 호출하여 각각의 요청이 승인되었는지 여부를 확인

kubelet은 API 요청을 apiserver와 동일한 요청 속성 접근 방식을 사용하여 승인한다.

동사는 들어오는 요청의 HTTP 동사로부터 결정된다.

리소스 및 하위 리소스는 들어오는 요청의 경로로부터 결정된다.

네임스페이스와 API 그룹 속성은 항상 빈 문자열이며, 리소스 이름은 항상 kubelet의 Node API 오브젝트 이름이다.

이 모드로 실행할 때, --kubelet-client-certificate 및 --kubelet-client-key 플래그로 식별된 사용자에게 다음 속성에 대한 권한이 있는지 확인한다.

• verb=*, resource=nodes, subresource=proxy
• verb=*, resource=nodes, subresource=stats
• verb=*, resource=nodes, subresource=log
• verb=*, resource=nodes, subresource=spec
• verb=*, resource=nodes, subresource=metrics

8 - 스케줄링

8.1 - 스케줄링 정책

스케줄링 정책을 사용하여 kube-scheduler가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 단정(predicates) 및 우선순위(priorities) 를 지정할 수 있다.

kube-scheduler --policy-config-file <filename> 또는 kube-scheduler --policy-configmap <ConfigMap>을 실행하고 정책 유형을 사용하여 스케줄링 정책을 설정할 수 있다.

단정

다음의 단정 은 필터링을 구현한다.

• PodFitsHostPorts: 파드가 요청하는 파드의 포트에 대해 노드에 사용할 수 있는 포트(네트워크 프로토콜 종류)가 있는지 확인한다.

• PodFitsHost: 파드가 호스트 이름으로 특정 노드를 지정하는지 확인한다.

• PodFitsResources: 파드의 요구 사항을 충족할 만큼 노드에 사용할 수 있는 리소스(예: CPU 및 메모리)가 있는지 확인한다.

• MatchNodeSelector: 파드의 노드 셀렉터가 노드의 레이블과 일치하는지 확인한다.

• NoVolumeZoneConflict: 해당 스토리지에 대한 장애 영역 제한이 주어지면 파드가 요청하는 볼륨을 노드에서 사용할 수 있는지 평가한다.

• NoDiskConflict: 요청하는 볼륨과 이미 마운트된 볼륨으로 인해 파드가 노드에 적합한지 평가한다.

• MaxCSIVolumeCount: 연결해야 하는 CSI 볼륨의 수와 구성된 제한을 초과하는지 여부를 결정한다.

• CheckNodeMemoryPressure: 노드가 메모리 압박을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.

• CheckNodePIDPressure: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.

• CheckNodeDiskPressure: 노드가 스토리지 압박(파일시스템이 가득차거나 거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.

• CheckNodeCondition: 노드는 파일시스템이 완전히 가득찼거나, 네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다. 노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다.

• PodToleratesNodeTaints: 파드의 톨러레이션이 노드의 테인트를 용인할 수 있는지 확인한다.

• CheckVolumeBinding: 파드가 요청한 볼륨에 적합할 수 있는지 평가한다. 이는 바인딩된 PVC와 바인딩되지 않은 PVC 모두에 적용된다.

우선순위

다음의 우선순위 는 스코어링을 구현한다.

• SelectorSpreadPriority: 동일한 서비스, 스테이트풀셋(StatefulSet) 또는 레플리카셋(ReplicaSet)에 속하는 파드를 고려하여, 파드를 여러 호스트에 파드를 분산한다.

• InterPodAffinityPriority: 선호된 파드간 어피니티와 안티-어피니티를 구현한다.

• LeastRequestedPriority: 요청된 리소스가 적은 노드를 선호한다. 즉, 노드에 배치되는 파드가 많고, 해당 파드가 사용하는 리소스가 많을수록 이 정책이 부여하는 순위가 낮아진다.

• MostRequestedPriority: 요청된 리소스가 가장 많은 노드를 선호한다. 이 정책은 전체 워크로드 세트를 실행하는 데 필요한 최소 노드 수에 스케줄된 파드를 맞춘다.

• RequestedToCapacityRatioPriority: 기본 리소스 스코어링 기능을 사용하여 ResourceAllocationPriority에 기반한 requestedToCapacity를 생성한다.

• BalancedResourceAllocation: 균형 잡힌 리소스 사용의 노드를 선호한다.

• NodePreferAvoidPodsPriority: 노드 어노테이션 scheduler.alpha.kubernetes.io/preferAvoidPods에 따라 노드의 우선순위를 지정한다. 이를 사용하여 두 개의 다른 파드가 동일한 노드에서 실행되면 안된다는 힌트를 줄 수 있다.

• NodeAffinityPriority: PreferredDuringSchedulingIgnoredDuringExecution에 표시된 노드 어피니티 스케줄링 설정에 따라 노드의 우선순위를 지정한다. 이에 대한 자세한 내용은 노드에 파드 할당하기에서 확인할 수 있다.

• TaintTolerationPriority: 노드에서 용인할 수 없는 테인트 수를 기반으로, 모든 노드의 우선순위 목록을 준비한다. 이 정책은 해당 목록을 고려하여 노드의 순위를 조정한다.

• ImageLocalityPriority: 해당 파드의 컨테이너 이미지가 이미 로컬로 캐시된 노드를 선호한다.

• ServiceSpreadingPriority: 특정 서비스에 대해, 이 정책은 해당 서비스에 대한 파드가 서로 다른 노드에서 실행되는 것을 목표로 한다. 해당 서비스에 대한 파드가 이미 할당되지 않은 노드에 스케줄링하는 것을 선호한다. 전반적인 결과는 서비스가 단일 노드 장애에 대해 더 탄력적이라는 것이다.

• EqualPriority: 모든 노드에 동일한 가중치를 부여한다.

• EvenPodsSpreadPriority: 선호된 파드 토폴로지 분배 제약 조건을 구현한다.

다음 내용

• 스케줄링에 대해 배우기
• kube-scheduler 프로파일에 대해 배우기
• kube-scheduler configuration 레퍼런스 (v1beta1) 읽어보기
• kube-scheduler Policy 레퍼런스 (v1) 읽어보기

8.2 - 스케줄러 구성

구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여 kube-scheduler 의 동작을 사용자 정의할 수 있다.

스케줄링 프로파일(Profile)을 사용하면 kube-scheduler에서 여러 단계의 스케줄링을 구성할 수 있다. 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.

KubeSchedulerConfiguration (v1beta1) 구조에 맞게 파일을 작성하고, kube-scheduler --config <filename>을 실행하여 스케줄링 프로파일을 지정할 수 있다.

최소 구성은 다음과 같다.

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

프로파일

스케줄링 프로파일을 사용하면 kube-scheduler에서 여러 단계의 스케줄링을 구성할 수 있다. 각 단계는 익스텐션 포인트에 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.

kube-scheduler 의 단일 인스턴스를 구성하여 여러 프로파일을 실행할 수 있다.

익스텐션 포인트

스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서 발생한다.

1. QueueSort: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를 정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다. 사용할 수 있다.
2. PreFilter: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를 사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로 표시할 수 있다.
3. Filter: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며 파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는 구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로 표시된다.
4. PreScore: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 정보성 익스텐션 포인트이다.
5. Score: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를 제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은 노드를 선택한다.
6. Reserve: 지정된 파드에 리소스가 예약된 경우 플러그인에 알리는 정보성 익스텐션 포인트이다. 플러그인은 또한 Reserve 도중 또는 이후에 실패한 경우 호출 되는 Unreserve 호출을 구현한다.
7. Permit: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
8. PreBind: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
9. Bind: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind 플러그인은 적어도 하나 이상 필요하다.
10. PostBind: 파드가 바인드된 후 호출되는 정보성 익스텐션 포인트이다.

각 익스텐션 포인트에 대해 특정 기본 플러그인을 비활성화하거나 자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
  - plugins:
      score:
        disabled:
        - name: NodeResourcesLeastAllocated
        enabled:
        - name: MyCustomPluginA
          weight: 2
        - name: MyCustomPluginB
          weight: 1

비활성화된 배열의 이름으로 * 를 사용하여 해당 익스텐션 포인트에 대한 모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데 사용할 수도 있다.

스케줄링 플러그인

1. UnReserve: 파드가 예약된 후 거부되고 Permit 플러그인에 의해 보류된 경우 호출되는 정보성 익스텐션 포인트이다.

스케줄링 플러그인

기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 하나 이상을 구현한다.

• SelectorSpread: 서비스, 레플리카셋(ReplicaSets) 및 스테이트풀셋(StatefulSets)에 속하는 파드에 대해 노드 간 분산을 선호한다. 익스텐션 포인트: PreScore, Score.
• ImageLocality: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를 선호한다. 익스텐션 포인트: Score.
• TaintToleration: 테인트(taint)와 톨러레이션(toleration)을 구현한다. 익스텐션 포인트 구현: Filter, Prescore, Score.
• NodeName: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다. 익스텐션 포인트: Filter.
• NodePorts: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다. 익스텐션 포인트: PreFilter, Filter.
• NodePreferAvoidPods: 노드 어노테이션 scheduler.alpha.kubernetes.io/preferAvoidPods 에 따라 노드 점수를 매긴다. 익스텐션 포인트: Score.
• NodeAffinity: 노드 셀렉터와 노드 어피니티를 구현한다. 익스텐션 포인트: Filter, Score.
• PodTopologySpread: 파드 토폴로지 분배를 구현한다. 익스텐션 포인트: PreFilter, Filter, PreScore, Score.
• NodeUnschedulable: .spec.unschedulable 이 true로 설정된 노드를 필터링한다. 익스텐션 포인트: Filter.
• NodeResourcesFit: 노드에 파드가 요청하는 모든 리소스가 있는지 확인한다. 익스텐션 포인트: PreFilter, Filter.
• NodeResourcesBalancedAllocation: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을 얻을 수 있는 노드를 선호한다. 익스텐션 포인트: Score.
• NodeResourcesLeastAllocated: 리소스 할당이 적은 노드를 선호한다. 익스텐션 포인트: Score.
• VolumeBinding: 노드에 요청된 볼륨이 있는지 또는 바인딩할 수 있는지 확인한다. 익스텐션 포인트: PreFilter, Filter, Reserve, PreBind.
• VolumeRestrictions: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 제한 사항을 충족하는지 확인한다. 익스텐션 포인트: Filter.
• VolumeZone: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지 확인한다. 익스텐션 포인트: Filter.
• NodeVolumeLimits: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: Filter.
• EBSLimits: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: Filter.
• GCEPDLimits: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: Filter.
• AzureDiskLimits: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: Filter.
• InterPodAffinity: 파드 간 어피니티 및 안티-어피니티를 구현한다. 익스텐션 포인트: PreFilter, Filter, PreScore, Score.
• PrioritySort: 기본 우선 순위 기반 정렬을 제공한다. 익스텐션 포인트: QueueSort.
• DefaultBinder: 기본 바인딩 메커니즘을 제공한다. 익스텐션 포인트: Bind.
• DefaultPreemption: 기본 선점 메커니즘을 제공한다. 익스텐션 포인트: PostFilter.

기본으로 활성화되지 않는 다음의 플러그인을 컴포넌트 구성 API를 통해 활성화할 수도 있다.

• NodeResourcesMostAllocated: 리소스 할당이 많은 노드를 선호한다. 익스텐션 포인트: Score.
• RequestedToCapacityRatio: 할당된 리소스의 구성된 기능에 따라 노드를 선호한다. 익스텐션 포인트: Score.
• CinderVolume: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지 확인한다. 익스텐션 포인트: Filter.
• NodeLabel: Filters and / or scores a node according to configured label(s). 익스텐션 포인트: Filter, Score.
• ServiceAffinity: 서비스에 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에 분산하는 것을 선호한다. 익스텐션 포인트: PreFilter, Filter, Score.

여러 프로파일

둘 이상의 프로파일을 실행하도록 kube-scheduler 를 구성할 수 있다. 각 프로파일에는 연관된 스케줄러 이름이 있으며 익스텐션 포인트에 구성된 다른 플러그인 세트를 가질 수 있다.

다음의 샘플 구성을 사용하면, 스케줄러는 기본 플러그인이 있는 프로파일과 모든 스코어링 플러그인이 비활성화된 프로파일의 두 가지 프로파일로 실행된다.

apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
  - schedulerName: no-scoring-scheduler
    plugins:
      preScore:
        disabled:
        - name: '*'
      score:
        disabled:
        - name: '*'

특정 프로파일에 따라 스케줄하려는 파드는 .spec.schedulerName 에 해당 스케줄러 이름을 포함할 수 있다.

기본적으로, 스케줄러 이름 default-scheduler 를 가진 하나의 프로파일이 생성된다. 이 프로파일에는 위에서 설명한 기본 플러그인이 포함되어 있다. 둘 이상의 프로파일을 선언할 때, 각각에 대한 고유한 스케줄러 이름이 필요하다.

파드가 스케줄러 이름을 지정하지 않으면, kube-apiserver는 이를 default-scheduler 로 설정한다. 따라서, 해당 파드를 스케줄하려면 이 스케줄러 이름을 가진 프로파일이 있어야 한다.

참고: 파드의 스케줄링 이벤트에는 ReportingController로 .spec.schedulerName 이 있다. 리더 선출을 위한 이벤트는 목록에서 첫 번째 프로파일의 스케줄러 이름을 사용한다.

참고: 모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며 동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을 단 하나만 가질 수 있기 때문이다.

다음 내용

• kube-scheduler 레퍼런스 읽어보기
• 스케줄링에 대해 알아보기
• kube-scheduler configuration (v1beta1) 레퍼런스 읽어보기

9 - 도구

쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.

Kubectl

kubectl은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다.

Kubeadm

kubeadm은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태).

Minikube

minikube는 개발과 테스팅 목적으로 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 실행하는 도구이다.

대시보드

대시보드, 는 쿠버네티스의 웹기반 유저 인터페이스이며 컨테이너화된 애플리케이션을 쿠버네티스 클러스터로 배포하고 클러스터 및 클러스터 자원의 문제를 해결하며 관리할 수 있게 해준다.

Helm

쿠버네티스 Helm은 사전 구성된 쿠버네티스 리소스를 관리하기위한 도구이며 또한 Helm의 쿠버네티스 차트라고도 한다.

Helm의 용도

• 쿠버네티스 차트로 배포된 인기있는 소프트웨어를 검색하고 사용
• 쿠버네티스 차트로 나의 애플리케이션을 공유
• 쿠버네티스 애플리케이션의 반복가능한 빌드 및 생성
• 매니페스트 파일의 지능화된 관리
• Helm 패키지의 릴리스 관리

Kompose

Kompose는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다.

Kompose의 용도

• 도커 컴포즈 파일을 쿠버네티스 오브젝트로 변환
• 로컬 도커 개발 환경에서 나의 애플리케이션을 쿠버네티스를 통해 관리하도록 이전
• V1 또는 V2 도커 컴포즈 yaml 파일 또는 분산 애플리케이션 번들을 변환