6.3. MCO 관련 사용자 지정 리소스 구성

MachineConfig 개체를 관리하는 것 외에도 MCO는KubeletConfig 및 ContainerRuntimeConfig의 두 가지 사용자 지정 리소스 (CR)를 관리합니다. 이러한 CR을 사용하면 Kubelet 및 CRI-O 컨테이너 런타임 서비스의 작동 방식에 영향을 주는 노드 수준 설정을 변경할 수 있습니다.

6.3.1. KubeletConfig CRD를 생성하여 kubelet 매개변수 편집

kubelet 구성은 현재 Ignition 구성으로 직렬화되어 있으므로 직접 편집할 수 있습니다. 하지만 MCC(Machine Config Controller)에 새 kubelet-config-controller도 추가되어 있습니다. 이를 통해 KubeletConfig CR(사용자 정의 리소스)을 사용하여 kubelet 매개변수를 편집할 수 있습니다.

참고

kubeletConfig 오브젝트의 필드가 Kubernetes 업스트림에서 kubelet으로 직접 전달되므로 kubelet은 해당 값을 직접 검증합니다. kubeletConfig 오브젝트의 값이 유효하지 않으면 클러스터 노드를 사용할 수 없게 될 수 있습니다. 유효한 값은 Kubernetes 설명서를 참조하십시오.

다음 지침 사항을 고려하십시오.

  • 해당 풀에 필요한 모든 구성 변경 사항을 사용하여 각 머신 구성 풀에 대해 하나의 KubeletConfig CR을 생성합니다. 모든 풀에 동일한 콘텐츠를 적용하는 경우 모든 풀에 대해 하나의 KubeletConfig CR만 필요합니다.
  • 기존 KubeletConfig CR을 편집하여 각 변경 사항에 대한 CR을 생성하는 대신 기존 설정을 수정하거나 새 설정을 추가합니다. 변경 사항을 되돌릴 수 있도록 다른 머신 구성 풀을 수정하거나 임시로 변경하려는 변경 사항만 수정하기 위해 CR을 생성하는 것이 좋습니다.
  • 필요에 따라 클러스터당 10개로 제한되는 여러 KubeletConfig CR을 생성합니다. 첫 번째 KubeletConfig CR의 경우 MCO(Machine Config Operator)는 kubelet에 추가된 머신 구성을 생성합니다. 이후 각 CR을 통해 컨트롤러는 숫자 접미사가 있는 다른 kubelet 머신 구성을 생성합니다. 예를 들어, -2 접미사가 있는 kubelet 머신 구성이 있는 경우 다음 kubelet 머신 구성에 -3이 추가됩니다.

머신 구성을 삭제하려면 제한을 초과하지 않도록 해당 구성을 역순으로 삭제합니다. 예를 들어 kubelet-2 머신 구성을 삭제하기 전에 kubelet-3 머신 구성을 삭제합니다.

참고

kubelet-9 접미사가 있는 머신 구성이 있고 다른 KubeletConfig CR을 생성하는 경우 kubelet 머신 구성이 10개 미만인 경우에도 새 머신 구성이 생성되지 않습니다.

KubeletConfig CR 예

$ oc get kubeletconfig

NAME                AGE
set-max-pods        15m

KubeletConfig 머신 구성 표시 예

$ oc get mc | grep kubelet

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...

다음 프로세스는 작업자 노드의 각 노드에 대한 최대 Pod 수를 구성하는 방법을 보여줍니다.

사전 요구 사항

  1. 구성하려는 노드 유형의 정적 MachineConfigPool CR와 연관된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.

    1. Machine config pool을 표시합니다. 

      $ oc describe machineconfigpool <name>

      예를 들면 다음과 같습니다. 

      $ oc describe machineconfigpool worker

      출력 예

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods 1

      1
      라벨이 추가되면 labels 아래에 표시됩니다.

    2. 라벨이 없으면 키/값 쌍을 추가합니다. 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

절차

  1. 이 명령은 선택할 수 있는 사용 가능한 머신 구성 오브젝트를 표시합니다. 

    $ oc get machineconfig

    기본적으로 두 개의 kubelet 관련 구성은 01-master-kubelet 및 01-worker-kubelet입니다.

  2. 노드당 최대 Pod의 현재 값을 확인하려면 다음을 실행합니다. 

    $ oc describe node <node_name>

    예를 들면 다음과 같습니다. 

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

    Allocatable 스탠자에서 value: pods: <value>를 찾습니다.

    출력 예

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250

  3. 작업자 노드에서 노드당 최대 Pod 수를 설정하려면 kubelet 구성이 포함된 사용자 정의 리소스 파일을 생성합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods 1
  kubeletConfig:
    maxPods: 500 2
    1
    머신 구성 풀에서 레이블을 입력합니다.
    2
    kubelet 구성을 추가합니다. 이 예에서는 maxPods를 사용하여 노드당 최대 Pod를 설정합니다.
    참고

    kubelet이 API 서버와 통신하는 속도는 QPS(초당 쿼리) 및 버스트 값에 따라 달라집니다. 노드마다 실행되는 Pod 수가 제한된 경우 기본 값인 50(kubeAPIQPS인 경우) 및 100(kubeAPIBurst인 경우)이면 충분합니다. 노드에 CPU 및 메모리 리소스가 충분한 경우 kubelet QPS 및 버스트 속도를 업데이트하는 것이 좋습니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
  kubeletConfig:
    maxPods: <pod_count>
    kubeAPIBurst: <burst_rate>
    kubeAPIQPS: <QPS>

    1. 라벨을 사용하여 작업자의 머신 구성 풀을 업데이트합니다. 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

    2. KubeletConfig 오브젝트를 생성합니다. 

      $ oc create -f change-maxPods-cr.yaml

    3. KubeletConfig 오브젝트가 생성되었는지 확인합니다. 

      $ oc get kubeletconfig

      출력 예

      NAME                AGE
set-max-pods        15m

      클러스터의 작업자 노드 수에 따라 작업자 노드가 하나씩 재부팅될 때까지 기다립니다. 작업자 노드가 3개인 클러스터의 경우 약 10~15분이 걸릴 수 있습니다.

  4. 변경 사항이 노드에 적용되었는지 확인합니다.

    1. 작업자 노드에서 maxPods 값이 변경되었는지 확인합니다. 

      $ oc describe node <node_name>

    2. Allocatable 스탠자를 찾습니다. 

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500 1
 ...
      1
      이 예에서 pods 매개변수는 KubeletConfig 오브젝트에 설정한 값을 보고해야 합니다.

  5. KubeletConfig 오브젝트에서 변경 사항을 확인합니다. 

    $ oc get kubeletconfigs set-max-pods -o yaml

    다음 예와 같이 True 및 type:Success 상태가 표시되어야 합니다. 

    spec:
  kubeletConfig:
    maxPods: 500
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
status:
  conditions:
  - lastTransitionTime: "2021-06-30T17:04:07Z"
    message: Success
    status: "True"
    type: Success

6.3.2. CRI-O 매개 변수를 편집하기 위한 ContainerRuntimeConfig CR 작성

특정 MCP(MCP)와 연결된 노드의 OpenShift Container Platform CRI-O 런타임과 관련된 설정을 변경할 수 있습니다. ContainerRuntimeConfig 사용자 지정 리소스(CR)를 사용하여 구성 값을 설정하고 MCP와 일치하도록 레이블을 추가합니다. 그런 다음 MCO는 업데이트된 값으로 연결된 노드에서 crio.conf 및 storage.conf 구성 파일을 다시 빌드합니다.

참고

ContainerRuntimeConfig CR을 사용하여 구현된 변경 사항을 되돌리려면 CR을 삭제해야 합니다. 머신 구성 풀에서 레이블을 제거해도 변경 사항은 복구되지 않습니다.

ContainerRuntimeConfig CR을 사용하여 다음 설정을 수정할 수 있습니다.

  • PIDs limit: ContainerRuntimeConfig 에서 PIDs 제한을 설정하면 더 이상 사용되지 않을 것으로 예상됩니다. PIDs 제한이 필요한 경우 KubeletConfig CR에서 podPidsLimit 필드를 사용하는 것이 좋습니다. podPidsLimit 필드의 기본값은 4096 입니다.

    참고

    CRI-O 플래그는 컨테이너 cgroup에 적용되며 Kubelet 플래그는 Pod의 cgroup에 설정됩니다. 그에 따라 PID 제한을 조정하십시오.

  • Log level: logLevel 매개변수는 로그 메시지의 상세 수준인 CRI-O log_level 매개변수를 설정합니다. 기본값은 info (log_level = info)입니다. 기타 다른 옵션에는 fatal, panic, error, warn, debug, trace가 포함됩니다.
  • Overlay size: overlaySize 매개변수는 컨테이너 이미지의 최대 크기인 CRI-O Overlay 스토리지 드라이버 size 매개 변수를 설정합니다.
  • Maximum log size: ContainerRuntimeConfig 에서 최대 로그 크기를 설정하면 더 이상 사용되지 않을 것으로 예상됩니다. 최대 로그 크기가 필요한 경우 KubeletConfig CR에서 containerLogMaxSize 필드를 사용하는 것이 좋습니다.
  • container runtime: defaultRuntime 매개변수는 컨테이너 런타임을 runc 또는 crun 로 설정합니다. 기본값은 runc 입니다.

각 머신 구성 풀에 대해 해당 풀에 필요한 모든 구성 변경 사항이 포함된 하나의 ContainerRuntimeConfig CR이 있어야 합니다. 모든 풀에 동일한 콘텐츠를 적용하는 경우 모든 풀에 대해 하나의 ContainerRuntimeConfig CR만 있으면 됩니다.

기존 ContainerRuntimeConfig CR을 편집하여 새 CR을 생성하는 대신 기존 설정을 편집하거나 새 설정을 추가할 수도 있습니다. 새 ContainerRuntimeConfig CR을 생성하여 다른 머신 구성 풀을 수정하거나 임시로 변경하려는 경우에만 변경 사항을 되돌릴 수 있도록 하는 것이 좋습니다.

필요에 따라 여러 ContainerRuntimeConfig CR을 생성할 수 있습니다 (클러스터당 10 개 제한). 첫 번째 ContainerRuntimeConfig CR의 경우 MCO는 containerruntime으로 추가된 머신 구성을 생성합니다. 이후 각 CR을 통해 컨트롤러는 숫자 접미사가 포함된 새 containerruntime 머신 구성을 생성합니다. 예를 들어, -2 접미사가 있는 containerruntime 머신 구성이 있는 경우 다음 containerruntime 머신 구성에 -3이 추가됩니다.

머신 구성을 삭제하려면 제한을 초과하지 않도록 해당 구성을 역순으로 삭제해야 합니다. 예를 들어 containerruntime-2 머신 구성을 삭제하기 전에 containerruntime-3 머신 구성을 삭제해야 합니다.

참고

containerruntime-9 접미사가 있는 머신 구성이 있는 경우, 다음 머신 구성에 ContainerRuntimeConfig CR이 추가되고, containerruntime 머신 구성이 10 개 미만이어도 제한을 초과하여 실패합니다.

여러 ContainerRuntimeConfig CR 표시 예

$ oc get ctrcfg

출력 예

NAME         AGE
ctr-pid      24m
ctr-overlay  15m
ctr-level    5m45s

여러 containerruntime 머신 구성의 예

$ oc get mc | grep container

출력 예

...
01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
...

다음 예제에서는 pids_limit를 2048로, log_level을 debug로 설정하고, overlay 크기를 8GB 로 설정하고, log_size_max를 무제한으로 설정합니다.

ContainerRuntimeConfig CR 예

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig:
   pidsLimit: 2048 2
   logLevel: debug 3
   overlaySize: 8G 4
   logSizeMax: "-1" 5
   defaultRuntime: "crun" 6

1
머신 구성 풀 레이블을 지정합니다.
2
선택 사항: 컨테이너에 허용되는 최대 프로세스 수를 설정합니다.
3
선택 사항: 로그 메시지의 상세 수준을 설정합니다.
4
선택 사항: 컨테이너 이미지의 최대 크기를 지정합니다.
5
선택 사항: 컨테이너 로그 파일에 허용되는 최대 크기를 설정합니다. 양수로 설정하는 경우 최소 8192 여야 합니다.
6
선택 사항: 새 컨테이너에 배포할 컨테이너 런타임을 지정합니다. 기본값은 runc 입니다.

사전 요구 사항

  • crun을 활성화하려면 TechPreviewNoUpgrade 기능 세트를 활성화해야 합니다.

    참고

    TechPreviewNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 이러한 기능 세트는 프로덕션 클러스터에서는 권장되지 않습니다.

절차

ContainerRuntimeConfig CR을 사용하여 CRI-O 설정을 변경합니다.

  1. ContainerRuntimeConfig CR의 YAML 파일을 생성합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig: 2
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G
   logSizeMax: "-1"
    1
    수정할 머신 구성 풀의 레이블을 지정합니다.
    2
    필요에 따라 매개변수를 설정합니다.

  2. ContainerRuntimeConfig CR을 생성합니다. 

    $ oc create -f <file_name>.yaml

  3. CR이 생성되었는지 확인합니다. 

    $ oc get ContainerRuntimeConfig

    출력 예

    NAME           AGE
overlay-size   3m19s

  4. 새 containerruntime 머신 구성이 생성되었는지 확인합니다. 

    $ oc get machineconfigs | grep containerrun

    출력 예

    99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

  5. 모두 준비 상태로 표시될 때까지 머신 구성 풀을 모니터링합니다. 

    $ oc get mcp worker

    출력 예

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

  6. 설정이 CRI-O에 적용되었는지 확인하려면 다음을 실행합니다.

    1. 머신 구성 풀의 노드에 oc debug 세션을 열고 chroot /host를 실행합니다. 

      $ oc debug node/<node_name>
      sh-4.4# chroot /host

    2. crio.conf 파일의 변경 사항을 확인합니다. 

      sh-4.4# crio config | egrep 'log_level|pids_limit|log_size_max'

      출력 예

      pids_limit = 2048
log_size_max = -1
log_level = "debug"

    3. 'storage.conf' 파일의 변경 사항을 확인합니다. 

      sh-4.4# head -n 7 /etc/containers/storage.conf

      출력 예

      [storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

6.3.3. CRI-O를 사용하여 오버레이에 대한 기본 최대 컨테이너 루트 파티션 크기 설정

각 컨테이너의 루트 파티션에는 기본 호스트의 사용 가능한 디스크 공간이 모두 표시됩니다. 다음 지침에 따라 모든 컨테이너의 루트 디스크에 대한 최대 파티션 크기를 설정합니다.

최대 오버레이 크기와 로그 수준 및 PID 제한과 같은 기타 CRI-O 옵션을 구성하려면 다음 ContainerRuntimeConfig CRD(사용자 정의 리소스 정의)를 생성할 수 있습니다. 

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G

절차

  1. 구성 오브젝트를 생성합니다. 

    $ oc apply -f overlaysize.yml

  2. 새 CRI-O 구성을 작업자 노드에 적용하려면 작업자 머신 구성 풀을 편집합니다. 

    $ oc edit machineconfigpool worker

  3. ContainerRuntimeConfig CRD에서 설정한 matchLabels 이름을 기반으로 custom-crio 레이블을 추가합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2020-07-09T15:46:34Z"
  generation: 3
  labels:
    custom-crio: overlay-size
    machineconfiguration.openshift.io/mco-built-in: ""

  4. 변경 사항을 저장한 다음 머신 구성을 확인합니다. 

    $ oc get machineconfigs

    새로운 99-worker-generated-containerruntime 및 rendered-worker-xyz 오브젝트가 생성됩니다.

    출력 예

    99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

  5. 해당 오브젝트가 생성된 후 적용할 변경 사항이 있는지 머신 구성 풀을 모니터링합니다. 

    $ oc get mcp worker

    작업자 노드는 UPDATING을 True로 표시하고 머신 수, 업데이트된 수 및 기타 세부 정보를 표시합니다.

    출력 예

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

    완료 후 작업자 노드는 UPDATING에서 다시 False로 변환되고 UPDATEDMACHINECOUNT의 수는 MACHINECOUNT의 ​​수와 일치합니다.

    출력 예

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

    작업자 머신을 보면 새로운 8GB 최대 크기 구성이 모든 작업자에 적용되는 것을 확인할 수 있습니다.

    출력 예

    head -n 7 /etc/containers/storage.conf
[storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

    컨테이너 내부를 보면 루트 파티션이 이제 8GB가 됩니다.

    출력 예

    ~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                   8.0G      8.0K      8.0G   0% /