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


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

중요

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

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

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

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

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

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

다음 다이어그램에서는 캡슐화 전과 후에 Kubernetes 설치를 보여줍니다. 두 시나리오 모두 양방향, 호스트 간 컨테이너, none의 마운트 전파 설정이 있는 예제 컨테이너를 보여줍니다.

캡슐화 전

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

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

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

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

9.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이 적용됩니다. 세 개의 프로세스가 모두 동일한 마운트 네임스페이스에 있는 경우 캡슐화가 적용되지 않습니다.

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

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

클러스터 호스트에 대한 SSH 쉘 세션은 default 네임스페이스에 있습니다. 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

9.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

9.4.5. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.