16.2. 통신 핵심 CNF 클러스터 문제 해결 및 유지 관리
16.2.1. 통신 핵심 CNF 클러스터 문제 해결 및 유지 관리
문제 해결 및 유지 관리는 구성 요소를 업데이트하거나 문제를 조사하려는지 여부에 관계없이 목표에 도달할 수 있는 도구가 없는 경우 문제가 될 수 있는 주간 작업입니다. 이 문제의 일부는 도구와 답변을 찾는 위치와 방법을 아는 것입니다.
대역폭이 높은 네트워크 처리량이 필요한 베어 메탈 환경을 유지 관리하고 문제를 해결하려면 다음 절차를 참조하십시오.
이 문제 해결 정보는 OpenShift Container Platform 구성 또는 CNF(클라우드 네이티브 네트워크 기능) 애플리케이션 개발을 위한 참조가 아닙니다.
통신용 CNF 애플리케이션 개발에 대한 자세한 내용은 Red Hat Best Practices for Kubernetes 를 참조하십시오.
16.2.1.1. 클라우드 네이티브 네트워크 기능
통신 클라우드 네이티브 네트워크 기능(CNF) 애플리케이션에 OpenShift Container Platform을 사용하기 시작하는 경우 CNF에 대해 학습하면 발생할 수 있는 문제를 이해하는 데 도움이 될 수 있습니다.
CNF 및 진화에 대한 자세한 내용은 VNF 및 CNF, 차이점은 무엇입니까?를 참조하십시오.
16.2.1.2. 지원 요청
절차에 어려움이 있는 경우 Red Hat 고객 포털 을 방문하십시오. 고객 포털에서는 다음과 같은 다양한 방법으로 도움말을 찾을 수 있습니다.
- Red Hat 제품에 대한 기사 및 솔루션에 대한 Red Hat 지식베이스를 검색하거나 살펴보십시오.
- Red Hat 지원에 지원 케이스 제출.
- 다른 제품 설명서에 액세스 가능합니다.
배포 문제를 식별하기 위해 디버깅 툴을 사용하거나 배포의 상태 끝점을 확인할 수 있습니다. 배포에 대한 상태 정보를 디버깅하거나 얻은 후 Red Hat 지식베이스에서 솔루션을 검색하거나 지원 티켓을 제출할 수 있습니다.
16.2.1.2.1. Red Hat 지식베이스 정보
Red Hat 지식베이스는 Red Hat의 제품과 기술을 최대한 활용할 수 있도록 풍부한 콘텐츠를 제공합니다. Red Hat 지식베이스는 Red Hat 제품 설치, 설정 및 사용에 대한 기사, 제품 문서 및 동영상으로 구성되어 있습니다. 또한 알려진 문제에 대한 솔루션을 검색할 수 있으며, 간결한 근본 원인 설명 및 해결 단계를 제공합니다.
16.2.1.2.2. Red Hat 지식베이스 검색
OpenShift Container Platform 문제가 발생한 경우 초기 검색을 수행하여 솔루션이 이미 Red Hat Knowledgebase 내에 존재하는지 확인할 수 있습니다.
사전 요구 사항
- Red Hat 고객 포털 계정이 있어야 합니다.
프로세스
- Red Hat 고객 포털에 로그인합니다.
- Search를 클릭합니다
검색 필드에서 다음을 포함하여 문제와 관련된 키워드 및 문자열을 입력합니다.
- OpenShift Container Platform 구성 요소 (etcd 등)
- 관련 절차 (예: installation 등)
- 명시적 실패와 관련된 경고, 오류 메시지 및 기타 출력
- Enter 키를 클릭합니다.
- 선택 사항: OpenShift Container Platform 제품 필터를 선택합니다.
- 선택 사항: 문서 콘텐츠 유형 필터를 선택합니다.
16.2.1.2.3. 지원 케이스 제출
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc)가 설치되어 있습니다. - Red Hat 고객 포털 계정이 있어야 합니다.
- Red Hat Standard 또는 Premium 서브스크립션이 있어야 합니다.
프로세스
- Red Hat 고객 포털의 고객 지원 페이지에 로그인합니다.
- 지원 받기를 클릭합니다.
고객 지원 페이지의 케이스 탭에서 다음을 수행합니다.
- 선택 사항: 필요한 경우 미리 채워진 계정 및 소유자 세부 정보를 변경합니다.
- Bug 또는 Defect 와 같은 문제에 대한 적절한 카테고리를 선택하고 Continue 를 클릭합니다.
다음 정보를 입력합니다.
- 요약 필드에 간결하지만 설명적인 문제 요약을 입력하고 경험되는 증상에 대한 자세한 내용과 기대치를 입력합니다.
- 제품 드롭다운 메뉴에서 OpenShift Container Platform 을 선택합니다.
- 버전 드롭다운에서 4.16 을 선택합니다.
- 보고되는 문제와 관련이 있을 수 있는 권장 Red Hat 지식베이스 솔루션 목록을 확인합니다. 제안된 문서로 문제가 해결되지 않으면 Continue을 클릭합니다.
- 보고되는 문제와 관련있는 제안된 Red Hat 지식베이스 솔루션 목록을 확인하십시오. 케이스 작성 과정에서 더 많은 정보를 제공하면 목록이 구체화됩니다. 제안된 문서로 문제가 해결되지 않으면 Continue을 클릭합니다.
- 제시된 계정 정보가 정확한지 확인하고 필요한 경우 적절하게 수정합니다.
자동 입력된 OpenShift Container Platform 클러스터 ID가 올바른지 확인합니다. 그렇지 않은 경우 클러스터 ID를 수동으로 가져옵니다.
OpenShift Container Platform 웹 콘솔을 사용하여 클러스터 ID를 수동으로 가져오려면 다음을 수행합니다.
-
홈
개요 로 이동합니다. - Details 섹션의 Cluster ID 필드에서 값을 찾습니다.
-
홈
또는 OpenShift Container Platform 웹 콘솔을 통해 새 지원 케이스를 열고 클러스터 ID를 자동으로 입력할 수 있습니다.
-
툴바에서 (?) Help
Open Support Case로 이동합니다. - Cluster ID 값이 자동으로 입력됩니다.
-
툴바에서 (?) Help
OpenShift CLI (
oc)를 사용하여 클러스터 ID를 얻으려면 다음 명령을 실행합니다.$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
프롬프트가 표시되면 다음 질문을 입력한 후 Continue를 클릭합니다.
- 무엇을 경험하고 있습니까? 어떤 일이 발생할 것으로 예상하십니까?
- 귀하 또는 비즈니스에 미치는 영향 또는 가치를 정의합니다.
- 이 동작을 어디에서 경험하고 있습니까? 어떤 시스템 환경을 사용하고 있습니까?
- 이 동작이 언제 발생합니까? 발생 빈도는 어떻게 됩니까? 반복적으로 발생합니까? 특정 시간에만 발생합니까?
-
관련 진단 데이터 파일을 업로드하고 Continue를 클릭합니다.
oc adm must-gather명령을 사용하여 수집된 데이터와 해당 명령으로 수집되지 않은 특정 문제와 관련된 데이터를 제공하는 것이 좋습니다 - 관련 케이스 관리 세부 정보를 입력하고 Continue를 클릭합니다.
- 케이스 세부 정보를 미리보고 Submit을 클릭합니다.
16.2.2. 일반 문제 해결
문제가 발생하면 첫 번째 단계는 문제가 발생하는 특정 영역을 찾는 것입니다. 잠재적인 문제가 있는 영역을 좁히려면 하나 이상의 작업을 완료합니다.
- 클러스터 쿼리
- Pod 로그 확인
- Pod 디버그
- 이벤트 검토
16.2.2.1. 클러스터 쿼리
잠재적인 문제를 보다 정확하게 찾을 수 있도록 클러스터에 대한 정보를 제공합니다.
프로세스
다음 명령을 실행하여 프로젝트로 전환합니다.
$ oc project <project_name>
다음 명령을 실행하여 해당 네임스페이스 내에서 클러스터 버전, 클러스터 Operator 및 노드를 쿼리합니다.
$ oc get clusterversion,clusteroperator,node
출력 예
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
자세한 내용은 "oc get" 및 "Pod 상태 검토"를 참조하십시오.
16.2.2.2. Pod 로그 확인
로그에서 문제에 대한 로그를 검토할 수 있도록 Pod에서 로그를 가져옵니다.
프로세스
다음 명령을 실행하여 Pod를 나열합니다.
$ oc get pod
출력 예
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
다음 명령을 실행하여 Pod 로그 파일을 확인합니다.
$ oc logs -n <namespace> busybox-1
자세한 내용은 "oc logs", "Logging" 및 "Pod 및 컨테이너 로그 검사"를 참조하십시오.
추가 리소스
16.2.2.3. Pod 설명
Pod를 설명하면 문제 해결에 도움이 되는 해당 Pod에 대한 정보가 제공됩니다. Events 섹션에서는 Pod 및 Pod 내부의 컨테이너에 대한 자세한 정보를 제공합니다.
프로세스
다음 명령을 실행하여 Pod를 설명합니다.
$ oc describe pod -n <namespace> busybox-1
출력 예
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
자세한 내용은 "oc describe"를 참조하십시오.
추가 리소스
16.2.2.4. 이벤트 검토
지정된 네임스페이스의 이벤트를 검토하여 잠재적인 문제를 찾을 수 있습니다.
프로세스
다음 명령을 실행하여 네임스페이스에서 이벤트를 확인합니다.
$ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp" 1- 1
--sort-by=".metadata.creationTimestamp"플래그를 추가하면 출력 끝에 가장 최근 이벤트가 배치됩니다.
선택 사항: 지정된 네임스페이스 내의 이벤트가 충분한 정보를 제공하지 않으면 다음 명령을 실행하여 모든 네임스페이스에 대한 쿼리를 확장합니다.
$ oc get events -A --sort-by=".metadata.creationTimestamp" 1- 1
--sort-by=".metadata.creationTimestamp"플래그는 출력 끝에 최신 이벤트를 배치합니다.
클러스터의 모든 이벤트 결과를 필터링하려면
grep명령을 사용하면 됩니다. 예를 들어 오류를 검색하는 경우TYPE또는MESSAGE섹션의 두 가지 다른 섹션에 오류가 표시될 수 있습니다.grep명령을 사용하면error또는failed와 같은 키워드를 검색할 수 있습니다.예를 들어 다음 명령을 실행하여
경고또는오류가포함된 메시지를 검색합니다.$ oc get events -A | grep -Ei "warning|error"
출력 예
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
선택 사항: 이벤트를 정리하고 반복 이벤트만 보려면 다음 명령을 실행하여 관련 네임스페이스에서 이벤트를 삭제할 수 있습니다.
$ oc delete events -n <namespace> --all
자세한 내용은 "클러스터 이벤트 감시"를 참조하십시오.
추가 리소스
16.2.2.5. Pod에 연결
해당 Pod의 쉘을 제공하는 oc rsh 명령을 사용하여 현재 실행 중인 Pod에 직접 연결할 수 있습니다.
대기 시간이 짧은 애플리케이션을 실행하는 Pod에서는 oc rsh 명령을 실행할 때 대기 시간 문제가 발생할 수 있습니다. oc debug 명령을 사용하여 노드에 연결할 수 없는 경우에만 oc rsh 명령을 사용합니다.
프로세스
다음 명령을 실행하여 Pod에 연결합니다.
$ oc rsh -n <namespace> busybox-1
자세한 내용은 "oc rsh" 및 "실행 중인 Pod 액세스"를 참조하십시오.
추가 리소스
16.2.2.6. Pod 디버깅
경우에 따라 프로덕션 중인 Pod와 직접 상호 작용하지 않으려 합니다.
실행 중인 트래픽을 방해하지 않도록 원래 Pod의 사본인 보조 Pod를 사용할 수 있습니다. 보조 Pod는 원래 Pod의 구성 요소와 동일한 구성 요소를 사용하지만 실행 중인 트래픽은 없습니다.
프로세스
다음 명령을 실행하여 Pod를 나열합니다.
$ oc get pod
출력 예
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
다음 명령을 실행하여 Pod를 디버깅합니다.
$ oc debug -n <namespace> busybox-1
출력 예
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
쉘 프롬프트가 표시되지 않으면 Enter를 누릅니다.
자세한 내용은 "oc debug" 및 "root access를 사용하여 디버그 Pod 시작"을 참조하십시오.
추가 리소스
16.2.2.7. Pod에서 명령 실행
직접 로그인하지 않고 Pod에서 명령 또는 명령 세트를 실행하려면 oc exec -it 명령을 사용할 수 있습니다. Pod와 빠르게 상호 작용하여 Pod에서 프로세스 또는 출력 정보를 가져올 수 있습니다. 일반적인 사용 사례는 스크립트 내에서 oc exec -it 명령을 실행하여 복제본 세트 또는 배포의 여러 포드에서 동일한 명령을 실행하는 것입니다.
대기 시간이 짧은 애플리케이션을 실행하는 Pod에서 oc exec 명령으로 대기 시간 문제가 발생할 수 있습니다.
프로세스
로그인하지 않고 Pod에서 명령을 실행하려면 다음 명령을 실행합니다.
$ oc exec -it <pod> -- <command>
자세한 내용은 "oc exec" 및 "컨테이너에서 원격 명령 제거"를 참조하십시오.
추가 리소스
16.2.3. 클러스터 유지 관리
통신 네트워크의 경우 베어 메탈 배포의 특성으로 인해 특정 구성에 더 많은 관심을 지불합니다. 다음 작업을 완료하여 보다 효과적으로 문제를 해결할 수 있습니다.
- 하드웨어 구성 요소 실패 또는 실패 여부를 모니터링
- 클러스터 Operator의 상태를 주기적으로 확인
하드웨어 모니터링의 경우 하드웨어 벤더에 문의하여 특정 하드웨어에 적합한 로깅 툴을 찾으십시오.
16.2.3.1. 클러스터 Operator 확인
정기적으로 클러스터 Operator의 상태를 확인하여 문제를 조기에 찾습니다.
프로세스
다음 명령을 실행하여 클러스터 Operator의 상태를 확인합니다.
$ oc get co
16.2.3.2. 실패한 Pod 확인
문제 해결 시간을 줄이기 위해 클러스터에서 실패한 Pod를 정기적으로 모니터링합니다.
프로세스
실패한 Pod를 확인하려면 다음 명령을 실행합니다.
$ oc get po -A | grep -Eiv 'complete|running'
16.2.4. 보안
강력한 클러스터 보안 프로필을 구현하는 것은 탄력적 인 통신 네트워크를 구축하는 데 중요합니다.
16.2.4.1. 인증
클러스터에 있는 ID 공급자를 확인합니다. 지원되는 ID 공급자에 대한 자세한 내용은 인증 및 권한 부여 의 "지원 ID 공급자"를 참조하십시오.
구성된 공급자를 확인한 후 openshift-authentication 네임스페이스를 검사하여 잠재적인 문제가 있는지 확인할 수 있습니다.
프로세스
다음 명령을 실행하여
openshift-authentication네임스페이스에서 이벤트를 확인합니다.$ oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
다음 명령을 실행하여
openshift-authentication네임스페이스에서 포드를 확인합니다.$ oc get pod -n openshift-authentication
선택 사항: 자세한 정보가 필요한 경우 다음 명령을 실행하여 실행 중인 Pod 중 하나의 로그를 확인합니다.
$ oc logs -n openshift-authentication <pod_name>
추가 리소스
16.2.5. 인증서 유지 관리
지속적인 클러스터 인증에는 인증서 유지 관리가 필요합니다. 클러스터 관리자는 특정 인증서를 수동으로 갱신해야 하지만 다른 인증서는 클러스터에 의해 자동으로 갱신됩니다.
OpenShift Container Platform의 인증서와 다음 리소스를 사용하여 유지 관리하는 방법에 대해 알아봅니다.
16.2.5.1. 관리자가 수동으로 관리하는 인증서
클러스터 관리자가 다음 인증서를 갱신해야 합니다.
- 프록시 인증서
- API 서버의 사용자 프로비저닝 인증서
16.2.5.1.1. 프록시 인증서 관리
프록시 인증서를 사용하면 송신 연결을 수행할 때 플랫폼 구성 요소에서 사용하는 하나 이상의 사용자 정의 인증 기관(CA) 인증서를 지정할 수 있습니다.
특정 CA는 만료 날짜를 설정하고 2 개월마다 이러한 인증서를 갱신해야 할 수도 있습니다.
요청된 인증서를 원래 설정하지 않은 경우 여러 가지 방법으로 인증서 만료를 확인할 수 있습니다. 대부분의 CNF(클라우드 네이티브 네트워크 기능)는 브라우저 기반 연결을 위해 특별히 설계되지 않은 인증서를 사용합니다. 따라서 배포의 ConfigMap 오브젝트에서 인증서를 가져와야 합니다.
프로세스
만료 날짜를 가져오려면 인증서 파일에 대해 다음 명령을 실행합니다.
$ openssl x509 -enddate -noout -in <cert_file_name>.pem
프록시 인증서를 갱신하는 방법과 시기를 결정하는 방법에 대한 자세한 내용은 보안 및 규정 준수 의 "Proxy 인증서"를 참조하십시오.
추가 리소스
16.2.5.1.2. 사용자 프로비저닝 API 서버 인증서
API 서버는 api.<cluster_name>.<base_domain> 에서 클러스터 외부에 있는 클라이언트가 액세스할 수 있습니다. 클라이언트가 다른 호스트 이름으로 또는 클러스터 관리 인증 기관(CA) 인증서를 클라이언트에 배포하지 않고 API 서버에 액세스하게 합니다. 콘텐츠를 제공할 때 API 서버에서 사용할 사용자 정의 기본 인증서를 설정해야 합니다.
자세한 내용은 보안 및 규정 준수의 "API 서버의 사용자 제공 인증서"를 참조하십시오.
추가 리소스
16.2.5.2. 클러스터에서 관리하는 인증서
로그에서 문제를 감지하는 경우에만 클러스터 관리 인증서를 확인해야 합니다. 다음 인증서는 클러스터에서 자동으로 관리합니다.
- 서비스 CA 인증서
- 노드 인증서
- 부트스트랩 인증서
- etcd 인증서
- OLM 인증서
- Machine Config Operator 인증서
- 모니터링 및 클러스터 로깅 Operator 구성요소 인증서
- 컨트롤 플레인 인증서
- 수신 인증서
추가 리소스
16.2.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
etcd 인증서 업데이트에 대한 자세한 내용은 OpenShift 4에서 etcd 인증서 만료 확인을 참조하십시오. etcd 인증서에 대한 자세한 내용은 보안 및 규정 준수 의 "etcd 인증서"를 참조하십시오.
추가 리소스
16.2.5.2.2. 노드 인증서
노드 인증서는 자체 서명된 인증서입니다. 즉, 클러스터에서 서명하고 부트스트랩 프로세스를 통해 생성된 내부 CA(인증 기관)에서 시작됩니다.
클러스터가 설치되면 클러스터가 노드 인증서를 자동으로 갱신합니다.
자세한 내용은 보안 및 규정 준수 의 "노드 인증서"를 참조하십시오.
추가 리소스
16.2.5.2.3. 서비스 CA 인증서
service-ca 는 OpenShift Container Platform 클러스터가 배포될 때 자체 서명된 CA(인증 기관)를 생성하는 Operator입니다. 이를 통해 사용자는 수동으로 생성하지 않고 배포에 인증서를 추가할 수 있습니다. 서비스 CA 인증서는 자체 서명된 인증서입니다.
자세한 내용은 보안 및 규정 준수 의 "서비스 CA 인증서"를 참조하십시오.
추가 리소스
16.2.6. Machine Config Operator
Machine Config Operator는 클러스터 관리자에게 유용한 정보를 제공하고 베어 메탈 호스트에서 직접 실행 중인 항목을 제어합니다.
Machine Config Operator는 클러스터의 다양한 노드 그룹을 구분하여 컨트롤 플레인 노드와 작업자 노드를 다른 구성으로 실행할 수 있습니다. 이러한 노드 그룹은 MachineConfigPool (mcp) 그룹이라는 작업자 또는 애플리케이션 Pod를 실행합니다. 동일한 머신 구성은 모든 노드에 적용되거나 클러스터의 MCP 한 개에만 적용됩니다.
통신 코어 클러스터에서 MCP를 적용하는 방법과 이유에 대한 자세한 내용은 업데이트 전에 MachineConfigPool 라벨을 노드에 적용합니다.
Machine Config Operator에 대한 자세한 내용은 Machine Config Operator 를 참조하십시오.
16.2.6.1. Machine Config Operator의 목적
MCO(Machine Config Operator)는 커널과 kubelet 사이의 모든 항목을 포함하여 RHCOS(Red Hat Enterprise Linux CoreOS) 및 컨테이너 런타임의 구성 및 업데이트를 관리하고 적용합니다. RHCOS 관리는 대부분의 통신 회사가 베어 메탈 하드웨어에서 실행되고 일종의 하드웨어 가속기 또는 커널 수정을 사용하기 때문에 중요합니다. RHCOS에 머신 구성을 수동으로 적용하면 MCO가 각 노드와 적용되는 항목을 모니터링하므로 문제가 발생할 수 있습니다.
이러한 마이너 구성 요소와 MCO가 클러스터를 효과적으로 관리하는 데 도움이 되는 방법을 고려해야 합니다.
MCO를 사용하여 작업자 또는 컨트롤 플레인 노드에서 모든 변경 사항을 수행해야 합니다. 수동으로 RHCOS 또는 노드 파일을 변경하지 마십시오.
16.2.6.2. 동시에 여러 머신 구성 파일 적용
MCP(Machine config pool)라고도 하는 클러스터의 노드 그룹에 대한 머신 구성을 변경해야 하는 경우 여러 다른 머신 구성 파일에 변경 사항을 적용해야 합니다. 머신 구성 파일을 적용하려면 노드를 재시작해야 합니다. 각 머신 구성 파일이 클러스터에 적용된 후 머신 구성 파일의 영향을 받는 모든 노드를 재시작합니다.
각 머신 구성 파일에 대해 노드를 다시 시작하지 못하도록 새 머신 구성 파일에서 업데이트한 각 MCP를 일시 중지하여 모든 변경 사항을 동시에 적용할 수 있습니다.
프로세스
다음 명령을 실행하여 영향을 받는 MCP를 일시 중지합니다.
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'클러스터에 모든 머신 구성 변경 사항을 적용한 후 다음 명령을 실행합니다.
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
이렇게 하면 MCP의 노드가 새 구성으로 재부팅할 수 있습니다.
16.2.7. 베어 메탈 노드 유지보수
일반적인 문제 해결을 위해 노드에 연결할 수 있습니다. 그러나 경우에 따라 특정 하드웨어 구성 요소에서 문제 해결 또는 유지 관리 작업을 수행해야 하는 경우도 있습니다. 이 섹션에서는 해당 하드웨어 유지 관리를 수행해야 하는 항목에 대해 설명합니다.
16.2.7.1. 클러스터의 베어 메탈 노드에 연결
일반적인 유지 관리 작업을 위해 베어 메탈 클러스터 노드에 연결할 수 있습니다.
호스트 운영 체제에서 클러스터 노드를 구성하는 것은 권장되거나 지원되지 않습니다.
노드의 문제를 해결하려면 다음 작업을 수행할 수 있습니다.
- 노드에서 로그 검색
- 디버깅 사용
- SSH를 사용하여 노드에 연결
oc debug 명령으로 노드에 연결할 수 없는 경우에만 SSH를 사용합니다.
프로세스
다음 명령을 실행하여 노드에서 로그를 검색합니다.
$ oc adm node-logs <node_name> -u crio
다음 명령을 실행하여 디버깅을 사용합니다.
$ oc debug node/<node_name>
디버그 쉘 내에서
/host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를/host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.# chroot /host
출력 결과
You are now logged in as root on the node
선택 사항: 다음 명령을 실행하여 SSH를 사용하여 노드에 연결합니다.
$ ssh core@<node_name>
16.2.7.2. 클러스터 내의 Pod로 애플리케이션 이동
예약된 하드웨어 유지 관리의 경우 Pod 워크로드에 영향을 주지 않고 애플리케이션 Pod를 클러스터 내의 다른 노드로 이동하는 방법을 고려해야 합니다.
프로세스
다음 명령을 실행하여 노드를 예약 불가로 표시합니다.
$ oc adm cordon <node_name>
노드를 예약할 수 없는 경우 노드에 Pod를 예약할 수 없습니다. 자세한 내용은 "노드 작업"을 참조하십시오.
CNF 애플리케이션을 이동할 때 유사성 방지 및 Pod 중단 예산으로 인해 클러스터에 추가 작업자 노드가 충분한지 미리 확인해야 할 수 있습니다.
추가 리소스
16.2.7.3. DIMM 메모리 교체
듀얼 인라인 메모리 모듈(DIMM) 문제는 서버가 재부팅된 후에만 표시되는 경우가 있습니다. 로그 파일에서 이러한 문제를 확인할 수 있습니다.
표준 재부팅을 수행하고 서버가 시작되지 않으면 콘솔에 결함이 있는 DIMM 메모리가 표시됩니다. 이 경우 결함이 있는 DIMM을 확인하고 나머지 메모리가 충분한 경우 재부팅을 계속할 수 있습니다. 그런 다음 유지 관리 기간을 예약하여 잘못된 DIMM을 교체할 수 있습니다.
이벤트 로그의 메시지는 잘못된 메모리 모듈을 나타내는 경우가 있습니다. 이 경우 서버를 재부팅하기 전에 메모리 교체를 예약할 수 있습니다.
16.2.7.4. 디스크 교체
하드웨어 또는 RAID(독립 디스크)의 중복 어레이를 통해 노드에 디스크 중복이 구성되지 않은 경우 다음을 확인해야 합니다.
- 디스크에 실행 중인 Pod 이미지가 포함되어 있습니까?
- 디스크에 Pod에 대한 영구 데이터가 포함되어 있습니까?
자세한 내용은 스토리지의 "OpenShift Container Platform 스토리지 개요"를 참조하십시오.
16.2.7.5. 클러스터 네트워크 카드 교체
네트워크 카드를 교체하면 MAC 주소가 변경됩니다. MAC 주소는 DHCP 또는 SR-IOV Operator 구성, 라우터 구성, 방화벽 규칙 또는 애플리케이션 CNF(클라우드 네이티브 네트워크 기능) 구성의 일부일 수 있습니다. 네트워크 카드를 교체한 후 노드를 온라인 상태로 되돌리기 전에 이러한 구성이 최신 상태인지 확인해야 합니다.
네트워크 내에서 MAC 주소 변경에 대한 특정 절차가 없는 경우 네트워크 관리자 또는 네트워크 하드웨어 공급업체에 문의하십시오.
