10.4. 마운트 네임스페이스 캡슐화를 사용하여 CPU 사용량 최적화


마운트 네임스페이스 캡슐화를 사용하여 kubelet 및 CRI-O 프로세스의 프라이빗 네임스페이스를 제공하여 OpenShift Container Platform 클러스터에서 CPU 사용량을 최적화할 수 있습니다. 이렇게 하면 기능 차이가 없이 systemd에서 사용하는 클러스터 CPU 리소스가 줄어듭니다.

중요

마운트 네임스페이스 캡슐화는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

10.4.1. 마운트 네임스페이스 캡슐화

마운트 네임스페이스는 다른 네임스페이스의 프로세스에서 서로의 파일을 볼 수 없도록 마운트 지점을 분리하는 데 사용됩니다. 캡슐화는 Kubernetes 마운트 네임스페이스를 호스트 운영 체제에서 지속적으로 검사하지 않는 대체 위치로 이동하는 프로세스입니다.

호스트 운영 체제는 systemd를 사용하여 모든 마운트 네임스페이스를 지속적으로 검사합니다. 표준 Linux 마운트와 Kubernetes가 작동하는 데 사용하는 수많은 마운트 모두입니다. kubelet 및 CRI-O의 현재 구현은 모든 컨테이너 런타임 및 kubelet 마운트 지점에 최상위 네임스페이스를 사용합니다. 그러나 프라이빗 네임스페이스에서 이러한 컨테이너별 마운트 지점을 캡슐화하면 기능 차이가 없이 systemd 오버헤드가 줄어듭니다. CRI-O 및 kubelet 모두에 별도의 마운트 네임스페이스를 사용하면 systemd 또는 기타 호스트 운영 체제 상호 작용의 컨테이너별 마운트를 캡슐화할 수 있습니다.

이제 모든 OpenShift Container Platform 관리자가 주요 CPU 최적화를 수행할 수 있는 이 기능을 사용할 수 있습니다. Encapsulation은 권한이 없는 사용자가 검사한 위치에서 Kubernetes별 마운트 지점을 저장하여 보안을 개선할 수도 있습니다.

다음 다이어그램은 캡슐화 전후의 Kubernetes 설치를 보여줍니다. 두 시나리오 모두 양방향, host-to-container 및 none의 마운트 전파 설정이 있는 예제 컨테이너를 표시합니다.

캡슐화 전

여기에서는 단일 마운트 네임스페이스를 공유하는 systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임을 참조하십시오.

  • systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임은 각각 모든 마운트 지점에 대한 액세스 및 가시성을 갖습니다.
  • 양방향 마운트 전파로 구성된 컨테이너 1은 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다. /run/a 와 같은 컨테이너 1에 있는 마운트는 systemd, 호스트 운영 체제 프로세스, kubelet, 컨테이너 런타임 및 호스트-컨테이너 또는 양방향 마운트 전파가 구성된 기타 컨테이너에 표시됩니다(컨테이너 2에서와 같이).
  • 컨테이너 2는 host-to-container 마운트 전파로 구성되며 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다. /run/b 와 같은 컨테이너 2에서 시작된 마운트는 다른 컨텍스트에 표시되지 않습니다.
  • 마운트 전파 없이 구성된 컨테이너 3은 외부 마운트 지점을 확인할 수 없습니다. /run/c 와 같은 컨테이너 3에서 시작되는 마운트는 다른 컨텍스트에 표시되지 않습니다.

다음 다이어그램은 캡슐화 후 시스템 상태를 보여줍니다.

캡슐화 후
  • 기본 systemd 프로세스는 더 이상 Kubernetes별 마운트 지점의 불필요한 검색에 영향을 미치지 않습니다. systemd 관련 및 호스트 마운트 지점만 모니터링합니다.
  • 호스트 운영 체제 프로세스는 systemd 및 호스트 마운트 지점에만 액세스할 수 있습니다.
  • CRI-O 및 kubelet 모두에 별도의 마운트 네임스페이스를 사용하면 모든 컨테이너별 마운트를 systemd 또는 기타 호스트 운영 체제 상호 작용과 완전히 분리합니다.
  • /run/a 와 같이 생성되는 마운트는 더 이상 systemd 또는 호스트 운영 체제 프로세스에 표시되지 않는 경우를 제외하고 컨테이너 1의 동작은 변경되지 않습니다. kubelet, CRI-O 및 host-to-container 또는 양방향 마운트 전파가 구성된 기타 컨테이너(예: 컨테이너 2)에 계속 표시됩니다.
  • 컨테이너 2 및 컨테이너 3의 동작은 변경되지 않습니다.

10.4.2. 마운트 네임스페이스 캡슐화 구성

클러스터가 리소스 오버헤드로 실행되도록 마운트 네임스페이스 캡슐화를 구성할 수 있습니다.

참고

마운트 네임스페이스 캡슐화는 기술 프리뷰 기능이며 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 수동으로 기능을 활성화해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 다음 YAML을 사용하여 mount_namespace_config.yaml 이라는 파일을 생성합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-kubens-master
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: kubens.service
    ---
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 99-kubens-worker
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: kubens.service
  2. 다음 명령을 실행하여 마운트 네임스페이스 MachineConfig CR을 적용합니다.

    $ oc apply -f mount_namespace_config.yaml

    출력 예

    machineconfig.machineconfiguration.openshift.io/99-kubens-master created
    machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

  3. MachineConfig CR은 클러스터에 적용되는 데 최대 30분이 걸릴 수 있습니다. 다음 명령을 실행하여 MachineConfig CR의 상태를 확인할 수 있습니다.

    $ oc get mcp

    출력 예

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master   rendered-master-03d4bc4befb0f4ed3566a2c8f7636751   False     True       False      3              0                   0                     0                      45m
    worker   rendered-worker-10577f6ab0117ed1825f8af2ac687ddf   False     True       False      3              1                   1

  4. 다음 명령을 실행한 후 MachineConfig CR이 모든 컨트롤 플레인 및 작업자 노드에 성공적으로 적용될 때까지 기다립니다.

    $ oc wait --for=condition=Updated mcp --all --timeout=30m

    출력 예

    machineconfigpool.machineconfiguration.openshift.io/master condition met
    machineconfigpool.machineconfiguration.openshift.io/worker condition met

검증

클러스터 호스트의 캡슐화를 확인하려면 다음 명령을 실행합니다.

  1. 클러스터 호스트에 대한 디버그 쉘을 엽니다.

    $ oc debug node/<node_name>
  2. chroot 세션을 엽니다.

    sh-4.4# chroot /host
  3. systemd 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/1/ns/mnt

    출력 예

    mnt:[4026531953]

  4. kubelet 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt

    출력 예

    mnt:[4026531840]

  5. CRI-O 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt

    출력 예

    mnt:[4026531840]

이러한 명령은 systemd, kubelet 및 컨테이너 런타임과 관련된 마운트 네임스페이스를 반환합니다. OpenShift Container Platform에서 컨테이너 런타임은 CRI-O입니다.

위 예제와 같이 systemd가 kubelet 및 CRI-O에 다른 마운트 네임스페이스에 있는 경우 Encapsulation이 적용됩니다. 3개의 프로세스가 모두 동일한 마운트 네임스페이스에 있는 경우 캡슐화는 적용되지 않습니다.

10.4.3. 캡슐화된 네임스페이스 검사

RHCOS(Red Hat Enterprise Linux CoreOS)에서 사용할 수 있는 kubensenter 스크립트를 사용하여 디버깅 또는 감사 목적으로 클러스터 호스트 운영 체제의 Kubernetes별 마운트 지점을 검사할 수 있습니다.

클러스터 호스트에 대한 SSH 쉘 세션은 기본 네임스페이스에 있습니다. SSH 쉘 프롬프트에서 Kubernetes별 마운트 지점을 검사하려면 kubensenter 스크립트를 root로 실행해야 합니다. kubensenter 스크립트는 마운트 캡슐화 상태를 알고 있으며 캡슐화가 활성화되지 않은 경우에도 실행하는 것이 안전합니다.

참고

oc debug 원격 쉘 세션은 기본적으로 Kubernetes 네임스페이스 내에서 시작됩니다. oc debug 를 사용할 때 마운트 지점을 검사하기 위해 kubensenter 를 실행할 필요가 없습니다.

캡슐화 기능이 활성화되지 않은 경우 kubensenter findmntfindmnt 명령은 oc debug 세션 또는 SSH 쉘 프롬프트에서 실행되는지 여부에 관계없이 동일한 출력을 반환합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 클러스터 호스트에 대한 SSH 액세스를 구성했습니다.

프로세스

  1. 클러스터 호스트에 대한 원격 SSH 쉘을 엽니다. 예를 들면 다음과 같습니다.

    $ ssh core@<node_name>
  2. 제공된 kubensenter 스크립트를 root 사용자로 사용하여 명령을 실행합니다. Kubernetes 네임스페이스 내에서 단일 명령을 실행하려면 명령과 kubensenter 스크립트에 인수를 제공합니다. 예를 들어 Kubernetes 네임스페이스 내에서 findmnt 명령을 실행하려면 다음 명령을 실행합니다.

    [core@control-plane-1 ~]$ sudo kubensenter findmnt

    출력 예

    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
    TARGET                                SOURCE                 FSTYPE     OPTIONS
    /                                     /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0]
    |                                                            xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota
                                          shm                    tmpfs
    ...

  3. Kubernetes 네임스페이스 내에서 새 대화형 쉘을 시작하려면 인수 없이 kubensenter 스크립트를 실행합니다.

    [core@control-plane-1 ~]$ sudo kubensenter

    출력 예

    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt

10.4.4. 캡슐화된 네임스페이스에서 추가 서비스 실행

호스트 운영 체제에서 실행하는 기능을 사용하고 kubelet, CRI-O 또는 컨테이너 자체에서 생성한 마운트 지점을 확인할 수 있는 모니터링 툴은 이러한 마운트 지점을 확인하기 위해 컨테이너 마운트 네임스페이스를 입력해야 합니다. OpenShift Container Platform과 함께 제공되는 kubensenter 스크립트는 Kubernetes 마운트 지점 내에서 다른 명령을 실행하고 기존 툴을 조정하는 데 사용할 수 있습니다.

kubensenter 스크립트는 마운트 캡슐화 기능 상태를 알고 있으며 캡슐화가 활성화되지 않은 경우에도 실행하는 것이 안전합니다. 이 경우 스크립트는 기본 마운트 네임스페이스에서 제공된 명령을 실행합니다.

예를 들어 systemd 서비스를 새 Kubernetes 마운트 네임스페이스 내에서 실행해야 하는 경우 서비스 파일을 편집하고 kubensenter 와 함께 ExecStart= 명령줄을 사용합니다.

[Unit]
Description=Example service
[Service]
ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2

10.4.5. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.