Information in this document may be out of date
This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Customizing components with the kubeadm API
kubeadm API로 컴포넌트 사용자 정의하기
이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에
대해서는 Cluster Configuration 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과
kube-proxy의 경우, KubeletConfiguration과 KubeProxyConfiguration을 각각 사용할 수 있다.
이 모든 옵션이 kubeadm 구성 API를 통해 가용하다. 구성의 각 필드 상세 사항은 API 참조 페이지에서 찾아볼 수 있다.
참고:
kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 않는다.kube-system/coredns 컨피그맵을 수동으로
패치하고, 그 이후에 CoreDNS 파드를 다시 생성해야 한다. 또는,
기본 CoreDNS 디플로이먼트를 생략하고 자체 변형(variant)을 배포할 수 있다.
더 자세한 사항은 kubeadm에서 초기화 단계 사용하기을 참고한다.참고:
이미 생성된 클러스터를 다시 구성하려면 kubeadm 클러스터 다시 구성하기를 참고한다.ClusterConfiguration의 플래그로 컨트롤 플레인 사용자 정의하기
kubeadm의 ClusterConfiguration 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러, Etcd와 같은 컨트롤 플레인 컴포넌트에 전달되는
기본 플래그를 사용자가 덮어쓸 수 있도록 노출한다.
이 컴포넌트는 다음 구조체를 사용하여 정의된다.
apiServercontrollerManagerscheduleretcd
이 구조체들은 공통 필드인 extraArgs를 포함하며, 이 필드는 키: 값 쌍으로 구성된다.
컨트롤 플레인 컴포넌트를 위한 플래그를 덮어쓰려면 다음을 수행한다.
- 사용자 구성에 적절한
extraArgs필드를 추가한다. extraArgs필드에 플래그를 추가한다.kubeadm init에--config <CONFIG YAML 파일>파라미터를 추가해서 실행한다.
참고:
kubeadm config print init-defaults를 실행하고 원하는 파일에 출력을
저장하여 기본값들로 구성된 ClusterConfiguration 오브젝트를 생성할 수 있다.참고:
ClusterConfiguration 오브젝트는 현재 kubeadm 클러스터에서 전역(global)으로 사용된다. 즉, 사용자가 추가하는 모든 플래그는
다른 노드에 있는 동일한 컴포넌트에도 모두 적용될 것이다. 다른 노드에서
컴포넌트별로 개별 구성을 적용하려면 패치를 사용하면 된다.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
패치를 통해 사용자 정의하기
Kubernetes v1.22 [beta]
Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 InitConfiguration과 JoinConfiguration에
전달할 수 있다. 이 패치는 컴포넌트 구성이 디스크에 기록되기 전에 최종 사용자 정의 단계로
사용될 수 있다.
--config <YOUR CONFIG YAML>을 사용하여 이 파일을 kubeadm init에 전달할 수 있다.
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
patches:
directory: /home/user/somedir
참고:
kubeadm init의 경우, ---로 구분된 ClusterConfiguration과 InitConfiguration을 모두
포함하는 파일을 전달할 수 있다.--config <YOUR CONFIG YAML>을 사용하여 이 파일을 kubeadm join에 전달할 수 있다.
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
patches:
directory: /home/user/somedir
디렉토리는 target[suffix][+patchtype].extension 형태의 파일을 포함해야 한다.
예를 들면, kube-apiserver0+merge.yaml 또는 단순히 etcd.json의 형태이다.
target은kube-apiserver,kube-controller-manager,kube-scheduler,etcd그리고kubeletconfiguration중 하나가 될 수 있다.patchtype은strategic,merge그리고json중 하나가 될 수 있으며 kubectl에서 지원하는 패치 형식을 준수해야 한다.patchtype의 기본값은strategic이다.extension은json또는yaml중 하나여야 한다.suffix는 어떤 패치가 먼저 적용되는지를 결정하는 데 사용할 수 있는 영숫자 형태의 선택적 문자열이다.
참고:
kubeadm upgrade를 사용하여 kubeadm 노드를 업그레이드하는 경우, 업그레이드 이후에도
사용자 정의를 유지하려면 동일한 패치를 다시 제공해야 한다. 이는 동일한 디렉토리로 지정된 --patches
플래그를 사용하여 처리할 수 있다. kubeadm upgrade는 동일 목적으로 재사용할 수 있는 구성
API 구조를 현재는 지원하지 않는다.kubelet 사용자 정의하기
kubelet을 사용자 정의하려면, KubeletConfiguration을
동일한 구성 파일 내에서 ---로 구분된 ClusterConfiguration이나 InitConfiguration 다음에 추가하면 된다.
그런 다음 kubeadm init에 해당 파일을 전달하면, kubeadm은 동일한 기본 KubeletConfiguration을
클러스터의 모든 노드에 적용한다.
기본 KubeletConfiguration에 더하여 인스턴스별 구성을 적용하기 위해서는
kubeletconfiguration 패치 target을 이용할 수 있다.
다른 방법으로는, kubelet 플래그를 덮어쓰기(overrides)로 사용하여,
InitConfiguration 및 JoinConfiguration 모두에서 지원되는 nodeRegistration.kubeletExtraArgs에 전달할 수 있다.
일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에
kubelet 참조 문서를 통해 상태를 확인해야 한다.
이 외 더 자세한 사항은 kubeadm을 통해 클러스터의 각 kubelet 구성하기에서 살펴본다.
kube-proxy 사용자 정의하기
kube-proxy를 사용자 정의하려면, KubeProxyConfiguration을 ---로 구분된 ClusterConfiguration이나 InitConfiguration
다음에 두고 kubeadm init에 전달하면 된다.
자세한 사항은 API 참조 페이지에서 살펴볼 수 있다.
참고:
kubeadm은 kube-proxy를 데몬셋으로 배포한다. 이것은KubeProxyConfiguration이 클러스터의 모든 kube-proxy 인스턴스에 적용된다는 것을 의미한다.