1 개요[ | ]
- Customizing components with the kubeadm API
- kubeadm API로 컴포넌트 커스터마이징
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/control-plane-flags/
이 페이지는 kubeadm이 배포하는 컴포넌트를 커스터마이징하는 방법을 다룹니다. 컨트롤 플레인 컴포넌트의 경우 ClusterConfiguration
구조에서 플래그를 사용하거나 노드별 패치를 사용할 수 있습니다. kubelet 및 kube-proxy의 경우 KubeletConfiguration
과 KubeProxyConfiguration
을 각각 사용할 수 있습니다.
이 모든 옵션은 kubeadm 설정 API를 통해 가능합니다. 설정의 각 필드에 대한 자세한 내용은 API 참조 페이지를 참조하십시오.
Note
현재 kubeadm의 CoreDNS 배포를 커스터마이징하는 것은 지원되지 않습니다.
kube-system/coredns
ConfigMap을 수동으로 패치하고 나서 CoreDNS 파드를 다시 생성해야 합니다. 또는, 기본 CoreDNS 배포를 건너뛰고 사용자의 변형판을 배포할 수 있습니다. 이에 대한 자세한 내용은 kubeadm을 사용한 초기화 단계를 참조하십시오.
Note
이미 생성된 클러스터를 재설정하려면 kubeadm 클러스터 재설정을 참조하십시오.
2 ClusterConfiguration
에 플래그로 컨트롤 플레인 커스터마이징[ | ]
kubeadm의 ClusterConfiguration
객체는 APIServer, ControllerManager, Scheduler, Etcd와 같은 컨트롤 플레인 컴포넌트에 전달되는 기본 플래그를 재정의할 수 있는 방법을 제공합니다. 컴포넌트는 다음과 같은 구조로 정의됩니다:
apiServer
controllerManager
scheduler
etcd
이 구조는 공통된 extraArgs
필드를 포함하며, 이는 key: value
쌍으로 구성됩니다. 컨트롤 플레인 컴포넌트에 대한 플래그를 재정의하려면:
- 1. 적절한
extraArgs
를 설정에 추가합니다. - 2.
extraArgs
필드에 플래그를 추가합니다. - 3.
kubeadm init
에--config <YOUR CONFIG YAML>
를 추가하여 실행합니다.
Note
기본값을 가진
ClusterConfiguration
객체를 생성하려면kubeadm config print init-defaults
명령어를 실행하고, 출력을 원하는 파일에 저장하십시오.
Note
ClusterConfiguration
객체는 현재 kubeadm 클러스터에서 전역적입니다. 즉, 추가한 플래그는 다른 노드의 동일한 컴포넌트의 모든 인스턴스에 적용됩니다. 다른 노드에서 개별 컴포넌트에 대해 개별 설정을 적용하려면 패치를 사용할 수 있습니다.
Note
중복 플래그(키) 또는 같은 플래그
--foo
를 여러 번 전달하는 것은 현재 지원되지 않습니다. 이를 해결(workaround)하려면 패치를 사용해야 합니다.
2.1 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
2.2 ControllerManager 플래그[ | ]
자세한 내용은 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"
2.3 Scheduler 플래그[ | ]
자세한 내용은 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"
2.4 Etcd 플래그[ | ]
자세한 내용은 etcd 서버 문서를 참조하십시오.
사용 예시:
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
etcd:
local:
extraArgs:
election-timeout: 1000
3 패치로 커스터마이징[ | ]
기능 상태: Kubernetes v1.22 [베타]
Kubeadm은 개별 노드에서 InitConfiguration
와 JoinConfiguration
에 패치 파일이 있는 디렉토리를 전달할 수 있게 해줍니다. 이 패치는 컴포넌트 설정이 디스크에 기록되기 전 마지막 커스터마이징 단계로 사용될 수 있습니다.
이 파일을 kubeadm init
에 --config <YOUR CONFIG YAML>
플래그를 사용하여 전달할 수 있습니다:
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
patches:
directory: /home/user/somedir
Note
kubeadm init
에서는ClusterConfiguration
과InitConfiguration
을 포함하는 파일을---
로 구분하여 전달할 수 있습니다.
이 파일을 kubeadm join
에 --config <YOUR CONFIG YAML>
플래그를 사용하여 전달할 수 있습니다:
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
중 하나일 수 있습니다.suffix
는 패치가 알파벳 순서로 먼저 적용되는 것을 결정할 수 있는 선택적 문자열입니다.patchtype
는strategic
,merge
,json
중 하나일 수 있으며, 이는 kubectl이 지원하는 패치 형식과 일치해야 합니다. 기본patchtype
은strategic
입니다.extension
:json
또는yaml
이어야 합니다.
Note
kubeadm upgrade
를 사용하여 kubeadm 노드를 업그레이드하는 경우, 동일한 패치를 다시 제공해야 커스터마이징이 업그레이드 후에도 유지됩니다. 이를 위해--patches
플래그를 사용하여 동일한 디렉토리를 가리켜야 합니다.kubeadm upgrade
는 현재 동일한 목적을 위해 사용될 수 있는 설정 API 구조를 지원하지 않습니다.