17.3. 통신사 핵심 CNF 클러스터 문제 해결 및 유지 관리


17.3.1. 통신사 핵심 CNF 클러스터 문제 해결 및 유지 관리

문제 해결 및 유지 관리는 목표를 달성하는 데 필요한 도구가 없다면 어려울 수 있는 주간 작업입니다. 구성 요소를 업데이트하거나 문제를 조사하려는 경우에도 마찬가지입니다. 과제 중 하나는 도구와 답변을 어디서 어떻게 검색해야 할지 아는 것입니다.

고대역폭 네트워크 처리량이 필요한 베어 메탈 환경을 유지 관리하고 문제를 해결하려면 다음 절차를 참조하세요.

중요

이 문제 해결 정보는 OpenShift Container Platform 구성이나 클라우드 기반 네트워크 기능(CNF) 애플리케이션 개발을 위한 참고 자료가 아닙니다.

통신 회사를 위한 CNF 애플리케이션 개발에 대한 자세한 내용은 Kubernetes를 위한 Red Hat 모범 사례를 참조하세요.

17.3.1.1. 클라우드 기반 네트워크 기능

통신 클라우드 기반 네트워크 기능(CNF) 애플리케이션에 OpenShift Container Platform을 사용하기 시작하는 경우 CNF에 대해 알아보면 발생할 수 있는 문제를 이해하는 데 도움이 될 수 있습니다.

CNF와 그 발전에 대해 자세히 알아보려면 VNF와 CNF, 차이점은 무엇인가요?를 참조하세요.

17.3.1.2. 지원 요청

절차에 어려움이 있는 경우 Red Hat 고객 포털을 방문하세요. 고객 포털에서는 다양한 방법으로 도움을 받을 수 있습니다.

  • Red Hat 제품에 대한 문서와 솔루션이 있는 Red Hat Knowledgebase를 검색하거나 탐색해 보세요.
  • Red Hat 지원팀에 지원 사례를 제출하세요.
  • 다른 제품 설명서에 액세스 가능합니다.

배포와 관련된 문제를 식별하려면 디버깅 도구를 사용하거나 배포의 상태 엔드포인트를 확인할 수 있습니다. 배포에 대한 디버깅을 완료하거나 상태 정보를 얻은 후에는 Red Hat Knowledgebase에서 솔루션을 검색하거나 지원 티켓을 제출할 수 있습니다.

17.3.1.2.1. Red Hat 지식베이스 정보

Red Hat 지식베이스는 Red Hat의 제품과 기술을 최대한 활용할 수 있도록 풍부한 콘텐츠를 제공합니다. Red Hat 지식베이스는 Red Hat 제품 설치, 설정 및 사용에 대한 기사, 제품 문서 및 동영상으로 구성되어 있습니다. 또한 알려진 문제에 대한 솔루션을 검색할 수 있으며, 간결한 근본 원인 설명 및 해결 단계를 제공합니다.

17.3.1.2.2. Red Hat 지식베이스 검색

OpenShift Container Platform 문제가 발생한 경우 초기 검색을 수행하여 솔루션이 이미 Red Hat Knowledgebase 내에 존재하는지 확인할 수 있습니다.

사전 요구 사항

  • Red Hat 고객 포털 계정이 있어야 합니다.

프로세스

  1. Red Hat 고객 포털에 로그인합니다.
  2. Search를 클릭합니다
  3. 검색 필드에 문제와 관련된 키워드와 문자열을 입력합니다.

    • OpenShift Container Platform 구성 요소 (etcd 등)
    • 관련 절차 (예: installation 등)
    • 명시적 실패와 관련된 경고, 오류 메시지 및 기타 출력
  4. Enter 키를 클릭하세요.
  5. 선택 사항: OpenShift Container Platform 제품 필터를 선택합니다.
  6. 선택 사항: 문서 콘텐츠 유형 필터를 선택합니다.
17.3.1.2.3. 지원 케이스 제출

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • Red Hat 고객 포털 계정이 있어야 합니다.
  • Red Hat Standard 또는 Premium 구독이 있습니다.

프로세스

  1. Red Hat 고객 포털의 고객 지원 페이지 에 로그인하세요.
  2. 지원 받기를 클릭하세요.
  3. 고객 지원 페이지의 사례 탭에서:

    1. 선택 사항: 필요한 경우 미리 작성된 계정 및 소유자 세부 정보를 변경합니다.
    2. 버그나 결함 등 문제에 적합한 범주를 선택하고 계속을 클릭합니다.
  4. 다음 정보를 입력하세요:

    1. 요약 필드에 간결하면서도 설명적인 문제 요약과 발생한 증상에 대한 자세한 내용, 그리고 기대 사항을 입력하세요.
    2. 제품 드롭다운 메뉴에서 OpenShift Container Platform을 선택합니다.
    3. 버전 드롭다운에서 4.19를 선택합니다.
  5. 보고되는 문제와 관련이 있을 수 있는 권장 Red Hat 지식베이스 솔루션 목록을 확인합니다. 제안된 문서로 문제가 해결되지 않으면 Continue을 클릭합니다.
  6. 보고되는 문제와 관련있는 제안된 Red Hat 지식베이스 솔루션 목록을 확인하십시오. 케이스 작성 과정에서 더 많은 정보를 제공하면 목록이 구체화됩니다. 제안된 문서로 문제가 해결되지 않으면 Continue을 클릭합니다.
  7. 제시된 계정 정보가 정확한지 확인하고 필요한 경우 적절하게 수정합니다.
  8. 자동 입력된 OpenShift Container Platform 클러스터 ID가 올바른지 확인합니다. 그렇지 않은 경우 클러스터 ID를 수동으로 가져옵니다.

    • OpenShift Container Platform 웹 콘솔을 사용하여 클러스터 ID를 수동으로 가져오려면 다음을 수행합니다.

      1. 개요 로 이동합니다.
      2. Details 섹션의 Cluster ID 필드에서 값을 찾습니다.
    • 또는 OpenShift Container Platform 웹 콘솔을 통해 새 지원 케이스를 열고 클러스터 ID를 자동으로 입력할 수 있습니다.

      1. 툴바에서 (?) Help Open Support Case로 이동합니다.
      2. Cluster ID 값이 자동으로 입력됩니다.
    • OpenShift CLI (oc)를 사용하여 클러스터 ID를 얻으려면 다음 명령을 실행합니다.

      $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
      Copy to Clipboard Toggle word wrap
  9. 프롬프트가 표시되면 다음 질문을 입력한 후 Continue를 클릭합니다.

    • 당신은 무슨 일을 겪고 있나요? 무슨 일이 일어날 것으로 기대하시나요?
    • 당신이나 회사에 미치는 가치나 영향을 정의하세요.
    • 이런 현상은 어디에서 나타나나요? 어떤 시스템 환경을 사용하고 있습니까?
    • 이런 동작은 언제 발생합니까? 발생 빈도는 어떻게 됩니까? 반복적으로 발생합니까? 특정 시간에만 발생합니까?
  10. 관련 진단 데이터 파일을 업로드하고 Continue를 클릭합니다. oc adm must-gather 명령을 사용하여 수집된 데이터와 해당 명령으로 수집되지 않은 특정 문제와 관련된 데이터를 제공하는 것이 좋습니다
  11. 관련 케이스 관리 세부 정보를 입력하고 Continue를 클릭합니다.
  12. 케이스 세부 정보를 미리보고 Submit을 클릭합니다.

17.3.2. 일반 문제 해결

문제가 발생하면 첫 번째 단계는 문제가 발생하는 구체적인 영역을 찾는 것입니다. 문제가 발생할 가능성이 있는 영역을 좁히려면 다음 작업 중 하나 이상을 완료하세요.

  • 클러스터 쿼리
  • 포드 로그를 확인하세요
  • 포드 디버깅
  • 이벤트 검토

17.3.2.1. 클러스터 쿼리

클러스터에 대한 정보를 얻으면 잠재적인 문제를 더 정확하게 찾을 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 프로젝트로 전환하세요.

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 해당 네임스페이스 내의 클러스터 버전, 클러스터 운영자 및 노드를 쿼리합니다.

    $ oc get clusterversion,clusteroperator,node
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version   4.16.11   True        False         62d     Cluster version is 4.16.11
    
    NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    clusteroperator.config.openshift.io/authentication                             4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/baremetal                                  4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/cloud-controller-manager                   4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/cloud-credential                           4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/cluster-autoscaler                         4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/config-operator                            4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/console                                    4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/control-plane-machine-set                  4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/csi-snapshot-controller                    4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/dns                                        4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/etcd                                       4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/image-registry                             4.16.11   True        False         False      55d
    clusteroperator.config.openshift.io/ingress                                    4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/insights                                   4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/kube-apiserver                             4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/kube-controller-manager                    4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/kube-scheduler                             4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/kube-storage-version-migrator              4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/machine-api                                4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/machine-approver                           4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/machine-config                             4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/marketplace                                4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/monitoring                                 4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/network                                    4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/node-tuning                                4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/openshift-apiserver                        4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/openshift-controller-manager               4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/openshift-samples                          4.16.11   True        False         False      35d
    clusteroperator.config.openshift.io/operator-lifecycle-manager                 4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog         4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver   4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/service-ca                                 4.16.11   True        False         False      62d
    clusteroperator.config.openshift.io/storage                                    4.16.11   True        False         False      62d
    
    NAME                STATUS   ROLES                         AGE   VERSION
    node/ctrl-plane-0   Ready    control-plane,master,worker   62d   v1.29.7
    node/ctrl-plane-1   Ready    control-plane,master,worker   62d   v1.29.7
    node/ctrl-plane-2   Ready    control-plane,master,worker   62d   v1.29.7
    Copy to Clipboard Toggle word wrap

자세한 내용은 "oc get" 및 "pod 상태 검토"를 참조하세요.

17.3.2.2. 포드 로그 확인

포드에서 로그를 가져와서 문제가 있는지 로그를 검토할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 포드를 나열합니다.

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        READY   STATUS    RESTARTS          AGE
    busybox-1   1/1     Running   168 (34m ago)     7d
    busybox-2   1/1     Running   119 (9m20s ago)   4d23h
    busybox-3   1/1     Running   168 (43m ago)     7d
    busybox-4   1/1     Running   168 (43m ago)     7d
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 Pod 로그 파일을 확인합니다.

    $ oc logs -n <namespace> busybox-1
    Copy to Clipboard Toggle word wrap

자세한 내용은 "oc 로그", "로깅" 및 "pod 및 컨테이너 로그 검사"를 참조하세요.

17.3.2.3. 포드 설명

포드를 설명하면 문제 해결에 도움이 되는 해당 포드에 대한 정보가 제공됩니다. 이벤트 섹션에서는 포드와 포드 안의 컨테이너에 대한 자세한 정보를 제공합니다.

프로세스

  • 다음 명령을 실행하여 포드를 설명합니다.

    $ oc describe pod -n <namespace> busybox-1
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:             busybox-1
    Namespace:        busy
    Priority:         0
    Service Account:  default
    Node:             worker-3/192.168.0.0
    Start Time:       Mon, 27 Nov 2023 14:41:25 -0500
    Labels:           app=busybox
                      pod-template-hash=<hash>
    Annotations:      k8s.ovn.org/pod-networks:
    …
    Events:
      Type    Reason   Age                   From     Message
      ----    ------   ----                  ----     -------
      Normal  Pulled   41m (x170 over 7d1h)  kubelet  Container image "quay.io/quay/busybox:latest" already present on machine
      Normal  Created  41m (x170 over 7d1h)  kubelet  Created container busybox
      Normal  Started  41m (x170 over 7d1h)  kubelet  Started container busybox
    Copy to Clipboard Toggle word wrap

자세한 내용은 "oc describe"를 참조하세요.

17.3.2.4. 이벤트 검토

주어진 네임스페이스의 이벤트를 검토하여 잠재적인 문제를 찾을 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 네임스페이스에서 이벤트를 확인하세요.

    $ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp" 
    1
    Copy to Clipboard Toggle word wrap
    1
    --sort-by=".metadata.creationTimestamp" 플래그를 추가하면 가장 최근 이벤트가 출력의 끝에 배치됩니다.
  2. 선택 사항: 지정된 네임스페이스 내의 이벤트가 충분한 정보를 제공하지 않는 경우 다음 명령을 실행하여 쿼리를 모든 네임스페이스로 확장합니다.

    $ oc get events -A --sort-by=".metadata.creationTimestamp" 
    1
    Copy to Clipboard Toggle word wrap
    1
    --sort-by=".metadata.creationTimestamp" 플래그는 가장 최근 이벤트를 출력의 끝에 배치합니다.

    클러스터의 모든 이벤트 결과를 필터링하려면 grep 명령을 사용하면 됩니다. 예를 들어, 오류를 찾는 경우 오류는 출력의 두 가지 섹션, 즉 TYPE 섹션과 MESSAGE 섹션에 나타날 수 있습니다. grep 명령을 사용하면 error , failed 등의 키워드를 검색할 수 있습니다.

  3. 예를 들어, 다음 명령을 실행하여 경고오류가 포함된 메시지를 검색합니다.

    $ oc get events -A | grep -Ei "warning|error"
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE    LAST SEEN   TYPE      REASON          OBJECT              MESSAGE
    openshift    59s         Warning   FailedMount     pod/openshift-1     MountVolume.SetUp failed for volume "v4-0-config-user-idp-0-file-data" : references non-existent secret key: test
    Copy to Clipboard Toggle word wrap

  4. 선택 사항: 이벤트를 정리하고 반복되는 이벤트만 보려면 다음 명령을 실행하여 관련 네임스페이스에서 이벤트를 삭제할 수 있습니다.

    $ oc delete events -n <namespace> --all
    Copy to Clipboard Toggle word wrap

자세한 내용은 "클러스터 이벤트 감시"를 참조하세요.

17.3.2.5. 포드에 연결

oc rsh 명령을 사용하면 현재 실행 중인 Pod에 직접 연결할 수 있으며, 해당 Pod에 셸을 제공합니다.

주의

저지연 애플리케이션을 실행하는 포드에서 oc rsh 명령을 실행하면 지연 문제가 발생할 수 있습니다. oc debug 명령을 사용하여 노드에 연결할 수 없는 경우에만 oc rsh 명령을 사용하세요.

프로세스

  • 다음 명령을 실행하여 Pod에 연결합니다.

    $ oc rsh -n <namespace> busybox-1
    Copy to Clipboard Toggle word wrap

자세한 내용은 "oc rsh" 및 "실행 중인 Pod에 액세스"를 참조하세요.

17.3.2.6. 포드 디버깅

경우에 따라 프로덕션 중인 Pod와 직접 상호 작용하지 않으려 합니다.

운행 중인 교통을 방해하지 않으려면 원래 포드의 복사본인 보조 포드를 사용할 수 있습니다. 2차 포드는 원래 포드와 동일한 구성요소를 사용하지만 운행 교통이 없습니다.

프로세스

  1. 다음 명령을 실행하여 포드를 나열합니다.

    $ oc get pod
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME        READY   STATUS    RESTARTS          AGE
    busybox-1   1/1     Running   168 (34m ago)     7d
    busybox-2   1/1     Running   119 (9m20s ago)   4d23h
    busybox-3   1/1     Running   168 (43m ago)     7d
    busybox-4   1/1     Running   168 (43m ago)     7d
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 Pod를 디버깅합니다.

    $ oc debug -n <namespace> busybox-1
    Copy to Clipboard Toggle word wrap

    출력 예

    Starting pod/busybox-1-debug, command was: sleep 3600
    Pod IP: 10.133.2.11
    Copy to Clipboard Toggle word wrap

    셸 프롬프트가 보이지 않으면 Enter를 누르세요.

자세한 내용은 "oc debug" 및 "root 액세스로 디버그 포드 시작"을 참조하세요.

17.3.2.7. 포드에서 명령 실행

포드에 직접 로그인하지 않고도 포드에서 명령이나 명령 세트를 실행하려면 oc exec -it 명령을 사용하면 됩니다. 포드와 빠르게 상호작용하여 포드에서 프로세스나 출력 정보를 얻을 수 있습니다. 일반적인 사용 사례는 스크립트 내에서 oc exec -it 명령을 실행하여 복제본 세트 또는 배포 내의 여러 포드에서 동일한 명령을 실행하는 것입니다.

주의

저지연 애플리케이션을 실행하는 포드에서 oc exec 명령은 지연 문제를 일으킬 수 있습니다.

프로세스

  • 로그인하지 않고 포드에서 명령을 실행하려면 다음 명령을 실행하세요.

    $ oc exec -it <pod> -- <command>
    Copy to Clipboard Toggle word wrap

자세한 내용은 "oc exec" 및 "컨테이너에서 원격 명령 실행"을 참조하세요.

17.3.3. 클러스터 유지 관리

통신사 네트워크에서는 베어메탈 배포의 특성으로 인해 특정 구성에 더 많은 주의를 기울여야 합니다. 다음 작업을 완료하여 보다 효과적으로 문제를 해결할 수 있습니다.

  • 실패하거나 오류가 발생한 하드웨어 구성 요소를 모니터링합니다.
  • 클러스터 운영자의 상태를 주기적으로 확인하세요
참고

하드웨어 모니터링의 경우, 해당 하드웨어 공급업체에 문의하여 해당 하드웨어에 적합한 로깅 도구를 찾으세요.

17.3.3.1. 클러스터 운영자 확인

문제를 조기에 발견하려면 클러스터 운영자의 상태를 주기적으로 확인하세요.

프로세스

  • 다음 명령을 실행하여 클러스터 운영자의 상태를 확인하세요.

    $ oc get co
    Copy to Clipboard Toggle word wrap

17.3.3.2. 실패한 포드를 감시합니다

문제 해결 시간을 줄이려면 클러스터에서 실패한 Pod를 정기적으로 모니터링하세요.

프로세스

  • 실패한 Pod를 감시하려면 다음 명령을 실행하세요.

    $ oc get po -A | grep -Eiv 'complete|running'
    Copy to Clipboard Toggle word wrap

17.3.4. 보안

탄력적인 통신사 네트워크를 구축하려면 강력한 클러스터 보안 프로필을 구현하는 것이 중요합니다.

17.3.4.1. 인증

클러스터에 어떤 ID 공급자가 있는지 확인하세요. 지원되는 ID 공급자에 대한 자세한 내용은 인증 및 권한 부여 에서 "지원되는 ID 공급자"를 참조하세요.

어떤 공급자가 구성되어 있는지 확인한 후 openshift-authentication 네임스페이스를 검사하여 잠재적인 문제가 있는지 확인할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 openshift-authentication 네임스페이스의 이벤트를 확인하세요.

    $ oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 openshift-authentication 네임스페이스의 포드를 확인하세요.

    $ oc get pod -n openshift-authentication
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 더 많은 정보가 필요하면 다음 명령을 실행하여 실행 중인 포드 중 하나의 로그를 확인하세요.

    $ oc logs -n openshift-authentication <pod_name>
    Copy to Clipboard Toggle word wrap

17.3.5. 인증서 유지 관리

지속적인 클러스터 인증을 위해서는 인증서 유지 관리가 필요합니다. 클러스터 관리자는 일부 인증서는 수동으로 갱신해야 하지만, 다른 인증서는 클러스터에서 자동으로 갱신됩니다.

다음 리소스를 사용하여 OpenShift Container Platform의 인증서에 대해 알아보고 인증서를 유지 관리하는 방법을 알아보세요.

17.3.5.1. 관리자가 수동으로 관리하는 인증서

다음 인증서는 클러스터 관리자가 갱신해야 합니다.

  • 프록시 인증서
  • API 서버에 대한 사용자 제공 인증서
17.3.5.1.1. 프록시 인증서 관리

프록시 인증서를 사용하면 사용자는 플랫폼 구성 요소에서 송신 연결을 만들 때 사용되는 하나 이상의 사용자 정의 인증 기관(CA) 인증서를 지정할 수 있습니다.

참고

특정 CA는 만료 날짜를 설정하고 2 개월마다 이러한 인증서를 갱신해야 할 수도 있습니다.

원래 요청한 인증서를 설정하지 않은 경우 여러 가지 방법으로 인증서 만료일을 확인할 수 있습니다. 대부분의 클라우드 기반 네트워크 기능(CNF)은 브라우저 기반 연결에 맞게 특별히 설계되지 않은 인증서를 사용합니다. 따라서 배포의 ConfigMap 개체에서 인증서를 가져와야 합니다.

프로세스

  • 만료 날짜를 알아보려면 인증서 파일에 대해 다음 명령을 실행하세요.

    $ openssl x509 -enddate -noout -in <cert_file_name>.pem
    Copy to Clipboard Toggle word wrap

프록시 인증서를 갱신하는 방법과 시기를 결정하는 방법에 대한 자세한 내용은 보안 및 규정 준수 의 "프록시 인증서"를 참조하세요.

17.3.5.1.2. 사용자 제공 API 서버 인증서

API 서버는 api.<cluster_name>.<base_domain> 에서 클러스터 외부에 있는 클라이언트가 접근할 수 있습니다. 클라이언트가 다른 호스트 이름으로 또는 클러스터 관리 인증 기관(CA) 인증서를 클라이언트에 배포하지 않고 API 서버에 액세스하게 합니다. 콘텐츠를 제공할 때 API 서버에서 사용할 사용자 지정 기본 인증서를 설정해야 합니다.

자세한 내용은 보안 및 규정 준수 의 "API 서버에 대한 사용자 제공 인증서"를 참조하세요.

17.3.5.2. 클러스터에서 관리하는 인증서

로그에서 문제를 감지한 경우에만 클러스터 관리 인증서를 확인하면 됩니다. 다음 인증서는 클러스터에서 자동으로 관리됩니다.

  • 서비스 CA 인증서
  • 노드 인증서
  • 부트스트랩 인증서
  • etcd 인증서
  • OLM 인증서
  • 머신 구성 운영자 인증서
  • 모니터링 및 클러스터 로깅 Operator 구성요소 인증서
  • 컨트롤 플레인 인증서
  • 수신 인증서
17.3.5.2.1. etcd에서 관리하는 인증서

etcd 인증서는 etcd 멤버 피어 간의 암호화된 통신과 암호화된 클라이언트 트래픽에 사용됩니다. 모든 노드와 모든 서비스 간 통신이 최신 상태인 경우 클러스터 내에서 인증서가 자동으로 갱신됩니다. 따라서 etcd 인증서의 수명이 끝나갈 무렵 특정 기간 동안 클러스터에서 구성 요소 간 통신이 끊어질 가능성이 있는 경우 미리 인증서를 갱신하는 것이 좋습니다. 예를 들어 다른 시간에 노드를 재부팅하여 업그레이드 중에 통신이 손실될 수 있습니다.

  • 다음 명령을 실행하여 etcd 인증서를 수동으로 갱신할 수 있습니다.

    $ for each in $(oc get secret -n openshift-etcd | grep "kubernetes.io/tls" | grep -e \
    "etcd-peer\|etcd-serving" | awk '{print $1}'); do oc get secret $each -n openshift-etcd -o \
    jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -noout -enddate; done
    Copy to Clipboard Toggle word wrap

etcd 인증서 업데이트에 대한 자세한 내용은 OpenShift 4에서 etcd 인증서 만료 확인을 참조하세요. etcd 인증서에 대한 자세한 내용은 보안 및 규정 준수 의 "etcd 인증서"를 참조하세요.

17.3.5.2.2. 노드 인증서

노드 인증서는 자체 서명 인증서입니다. 즉, 클러스터에서 서명하고 부트스트랩 프로세스에서 생성된 내부 인증 기관(CA)에서 생성된 인증서입니다.

클러스터가 설치된 후 클러스터가 자동으로 노드 인증서를 갱신합니다.

자세한 내용은 보안 및 규정 준수 의 "노드 인증서"를 참조하세요.

17.3.5.2.3. 서비스 CA 인증서

service-ca는 OpenShift Container Platform 클러스터가 배포될 때 자체 서명된 인증 기관(CA)을 생성하는 운영자입니다. 이를 통해 사용자는 인증서를 수동으로 생성하지 않고도 배포에 인증서를 추가할 수 있습니다. 서비스 CA 인증서는 자체 서명된 인증서입니다.

자세한 내용은 보안 및 규정 준수 의 "서비스 CA 인증서"를 참조하세요.

17.3.6. Machine Config Operator

Machine Config Operator는 클러스터 관리자에게 유용한 정보를 제공하고 베어 메탈 호스트에서 직접 실행되는 작업을 제어합니다.

Machine Config Operator는 클러스터 내의 다양한 노드 그룹을 구별하여 제어 평면 노드와 작업자 노드가 서로 다른 구성으로 실행될 수 있도록 합니다. 이러한 노드 그룹은 MachineConfigPool ( mcp ) 그룹이라고 하는 작업자 또는 애플리케이션 포드를 실행합니다. 동일한 머신 구성이 모든 노드에 적용되거나 클러스터의 한 MCP에만 적용됩니다.

업데이트 전에 노드에 MachineConfigPool 레이블 적용을 참조하여 통신사 코어 클러스터에 MCP를 적용하는 방법과 이유에 대한 자세한 내용을 확인하세요.

Machine Config Operator에 대한 자세한 내용은 Machine Config Operator를 참조하세요.

17.3.6.1. Machine Config Operator의 목적

MCO(Machine Config Operator)는 커널과 kubelet 사이의 모든 것을 포함하여 Red Hat Enterprise Linux CoreOS(RHCOS) 및 컨테이너 런타임의 구성과 업데이트를 관리하고 적용합니다. 대부분의 통신 회사는 베어메탈 하드웨어로 운영되고 어떤 종류의 하드웨어 가속기나 커널 수정을 사용하기 때문에 RHCOS를 관리하는 것이 중요합니다. RHCOS에 수동으로 머신 구성을 적용하면 MCO가 각 노드와 해당 노드에 적용되는 내용을 모니터링하기 때문에 문제가 발생할 수 있습니다.

이러한 사소한 구성 요소를 고려해야 하며 MCO가 클러스터를 효과적으로 관리하는 데 어떻게 도움을 줄 수 있는지 고려해야 합니다.

중요

작업자 또는 제어 평면 노드에서 모든 변경을 수행하려면 MCO를 사용해야 합니다. 수동으로 RHCOS 또는 노드 파일을 변경하지 마십시오.

17.3.6.2. 여러 머신 구성 파일을 동시에 적용

클러스터 내 노드 그룹에 대한 머신 구성(머신 구성 풀(MCP)이라고도 함)을 변경해야 하는 경우, 때로는 여러 개의 서로 다른 머신 구성 파일에 변경 사항을 적용해야 합니다. 머신 구성 파일을 적용하려면 노드를 다시 시작해야 합니다. 각 머신 구성 파일이 클러스터에 적용된 후에는 해당 머신 구성 파일의 영향을 받는 모든 노드가 다시 시작됩니다.

각 머신 구성 파일에 대해 노드가 다시 시작되는 것을 방지하려면 새 머신 구성 파일에 의해 업데이트된 각 MCP를 일시 중지하여 모든 변경 사항을 동시에 적용할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 영향을 받은 MCP를 일시 중지합니다.

    $ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'
    Copy to Clipboard Toggle word wrap
  2. 클러스터에 모든 머신 구성 변경 사항을 적용한 후 다음 명령을 실행합니다.

    $ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
    Copy to Clipboard Toggle word wrap

이렇게 하면 MCP의 노드가 새로운 구성으로 재부팅될 수 있습니다.

17.3.7. 베어 메탈 노드 유지 관리

일반적인 문제 해결을 위해 노드에 연결할 수 있습니다. 그러나 어떤 경우에는 특정 하드웨어 구성 요소에 대한 문제 해결이나 유지 관리 작업을 수행해야 합니다. 이 섹션에서는 하드웨어 유지 관리를 수행하는 데 필요한 항목을 설명합니다.

17.3.7.1. 클러스터의 베어 메탈 노드에 연결

일반적인 유지 관리 작업을 위해 베어 메탈 클러스터 노드에 연결할 수 있습니다.

참고

호스트 운영 체제에서 클러스터 노드를 구성하는 것은 권장되지 않으며 지원되지 않습니다.

노드 문제를 해결하려면 다음 작업을 수행할 수 있습니다.

  • 노드에서 로그 검색
  • 디버깅을 사용하세요
  • SSH를 사용하여 노드에 연결합니다.
중요

oc debug 명령으로 노드에 연결할 수 없는 경우에만 SSH를 사용하세요.

프로세스

  1. 다음 명령을 실행하여 노드에서 로그를 검색합니다.

    $ oc adm node-logs <node_name> -u crio
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 디버깅을 사용하세요.

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap
  3. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

    # chroot /host
    Copy to Clipboard Toggle word wrap

    출력 결과

    You are now logged in as root on the node
    Copy to Clipboard Toggle word wrap

  4. 선택 사항: 다음 명령을 실행하여 SSH를 사용하여 노드에 연결합니다.

    $ ssh core@<node_name>
    Copy to Clipboard Toggle word wrap

17.3.7.2. 클러스터 내의 포드로 애플리케이션 이동

예정된 하드웨어 유지 관리를 위해서는 포드 작업 부하에 영향을 주지 않고 클러스터 내의 다른 노드로 애플리케이션 포드를 이동하는 방법을 고려해야 합니다.

프로세스

  • 다음 명령을 실행하여 노드를 예약 불가능으로 표시합니다.

    $ oc adm cordon <node_name>
    Copy to Clipboard Toggle word wrap

노드를 예약할 수 없는 경우 노드에 Pod를 예약할 수 없습니다. 자세한 내용은 "노드 작업"을 참조하세요.

참고

CNF 애플리케이션을 이동할 때, 반친화성 및 Pod 중단 예산으로 인해 클러스터에 충분한 추가 작업자 노드가 있는지 미리 확인해야 할 수도 있습니다.

17.3.7.3. DIMM 메모리 교체

듀얼 인라인 메모리 모듈(DIMM) 문제는 때때로 서버를 재부팅한 후에만 나타납니다. 로그 파일에서 이러한 문제를 확인할 수 있습니다.

표준 재부팅을 수행했는데 서버가 시작되지 않으면 콘솔에 DIMM 메모리에 오류가 있다는 메시지가 표시됩니다. 그런 경우, 오류가 있는 DIMM을 확인하고 남은 메모리가 충분하다면 재부팅을 계속할 수 있습니다. 그런 다음, 결함이 있는 DIMM을 교체하기 위한 유지 관리 기간을 예약할 수 있습니다.

때로는 이벤트 로그의 메시지가 메모리 모듈에 문제가 있음을 나타냅니다. 이런 경우, 서버를 재부팅하기 전에 메모리 교체 일정을 예약할 수 있습니다.

17.3.7.4. 디스크 교체

하드웨어 또는 소프트웨어 RAID(Redundant Array of Independent Disks)를 통해 노드에 디스크 중복성이 구성되지 않은 경우 다음 사항을 확인해야 합니다.

  • 디스크에 실행 중인 Pod 이미지가 포함되어 있나요?
  • 디스크에 포드에 대한 영구 데이터가 포함되어 있나요?

자세한 내용은 저장소 의 "OpenShift Container Platform 저장소 개요"를 참조하세요.

17.3.7.5. 클러스터 네트워크 카드 교체

네트워크 카드를 교체하면 MAC 주소가 변경됩니다. MAC 주소는 DHCP 또는 SR-IOV 운영자 구성, 라우터 구성, 방화벽 규칙 또는 애플리케이션 클라우드 기반 네트워크 기능(CNF) 구성의 일부가 될 수 있습니다. 네트워크 카드를 교체한 후 노드를 다시 온라인으로 전환하기 전에 이러한 구성이 최신 상태인지 확인해야 합니다.

중요

네트워크 내에서 MAC 주소를 변경하는 구체적인 절차가 없는 경우 네트워크 관리자나 네트워크 하드웨어 공급업체에 문의하세요.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat