kubeadm API로 컴포넌트 커스터마이징

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 구조를 지원하지 않습니다.