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 고객 포털 계정이 있어야 합니다.
프로세스
- Red Hat 고객 포털에 로그인합니다.
- Search를 클릭합니다
검색 필드에 문제와 관련된 키워드와 문자열을 입력합니다.
- OpenShift Container Platform 구성 요소 (etcd 등)
- 관련 절차 (예: installation 등)
- 명시적 실패와 관련된 경고, 오류 메시지 및 기타 출력
- Enter 키를 클릭하세요.
- 선택 사항: OpenShift Container Platform 제품 필터를 선택합니다.
- 선택 사항: 문서 콘텐츠 유형 필터를 선택합니다.
17.3.1.2.3. 지원 케이스 제출 링크 복사링크가 클립보드에 복사되었습니다!
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다. - Red Hat 고객 포털 계정이 있어야 합니다.
- Red Hat Standard 또는 Premium 구독이 있습니다.
프로세스
- Red Hat 고객 포털의 고객 지원 페이지 에 로그인하세요.
- 지원 받기를 클릭하세요.
고객 지원 페이지의 사례 탭에서:
- 선택 사항: 필요한 경우 미리 작성된 계정 및 소유자 세부 정보를 변경합니다.
- 버그나 결함 등 문제에 적합한 범주를 선택하고 계속을 클릭합니다.
다음 정보를 입력하세요:
- 요약 필드에 간결하면서도 설명적인 문제 요약과 발생한 증상에 대한 자세한 내용, 그리고 기대 사항을 입력하세요.
- 제품 드롭다운 메뉴에서 OpenShift Container Platform을 선택합니다.
- 버전 드롭다운에서 4.19를 선택합니다.
- 보고되는 문제와 관련이 있을 수 있는 권장 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"}'
$ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
프롬프트가 표시되면 다음 질문을 입력한 후 Continue를 클릭합니다.
- 당신은 무슨 일을 겪고 있나요? 무슨 일이 일어날 것으로 기대하시나요?
- 당신이나 회사에 미치는 가치나 영향을 정의하세요.
- 이런 현상은 어디에서 나타나나요? 어떤 시스템 환경을 사용하고 있습니까?
- 이런 동작은 언제 발생합니까? 발생 빈도는 어떻게 됩니까? 반복적으로 발생합니까? 특정 시간에만 발생합니까?
-
관련 진단 데이터 파일을 업로드하고 Continue를 클릭합니다.
oc adm must-gather
명령을 사용하여 수집된 데이터와 해당 명령으로 수집되지 않은 특정 문제와 관련된 데이터를 제공하는 것이 좋습니다 - 관련 케이스 관리 세부 정보를 입력하고 Continue를 클릭합니다.
- 케이스 세부 정보를 미리보고 Submit을 클릭합니다.
17.3.2. 일반 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
문제가 발생하면 첫 번째 단계는 문제가 발생하는 구체적인 영역을 찾는 것입니다. 문제가 발생할 가능성이 있는 영역을 좁히려면 다음 작업 중 하나 이상을 완료하세요.
- 클러스터 쿼리
- 포드 로그를 확인하세요
- 포드 디버깅
- 이벤트 검토
17.3.2.1. 클러스터 쿼리 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에 대한 정보를 얻으면 잠재적인 문제를 더 정확하게 찾을 수 있습니다.
프로세스
다음 명령을 실행하여 프로젝트로 전환하세요.
oc project <project_name>
$ oc project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 해당 네임스페이스 내의 클러스터 버전, 클러스터 운영자 및 노드를 쿼리합니다.
oc get clusterversion,clusteroperator,node
$ oc get clusterversion,clusteroperator,node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
자세한 내용은 "oc get" 및 "pod 상태 검토"를 참조하세요.
17.3.2.2. 포드 로그 확인 링크 복사링크가 클립보드에 복사되었습니다!
포드에서 로그를 가져와서 문제가 있는지 로그를 검토할 수 있습니다.
프로세스
다음 명령을 실행하여 포드를 나열합니다.
oc get pod
$ oc get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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 Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod 로그 파일을 확인합니다.
oc logs -n <namespace> busybox-1
$ oc logs -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
자세한 내용은 "oc 로그", "로깅" 및 "pod 및 컨테이너 로그 검사"를 참조하세요.
17.3.2.3. 포드 설명 링크 복사링크가 클립보드에 복사되었습니다!
포드를 설명하면 문제 해결에 도움이 되는 해당 포드에 대한 정보가 제공됩니다. 이벤트
섹션에서는 포드와 포드 안의 컨테이너에 대한 자세한 정보를 제공합니다.
프로세스
다음 명령을 실행하여 포드를 설명합니다.
oc describe pod -n <namespace> busybox-1
$ oc describe pod -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
자세한 내용은 "oc describe"를 참조하세요.
17.3.2.4. 이벤트 검토 링크 복사링크가 클립보드에 복사되었습니다!
주어진 네임스페이스의 이벤트를 검토하여 잠재적인 문제를 찾을 수 있습니다.
프로세스
다음 명령을 실행하여 네임스페이스에서 이벤트를 확인하세요.
oc get events -n <namespace> --sort-by=".metadata.creationTimestamp"
$ oc get events -n <namespace> --sort-by=".metadata.creationTimestamp"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--sort-by=".metadata.creationTimestamp"
플래그를 추가하면 가장 최근 이벤트가 출력의 끝에 배치됩니다.
선택 사항: 지정된 네임스페이스 내의 이벤트가 충분한 정보를 제공하지 않는 경우 다음 명령을 실행하여 쿼리를 모든 네임스페이스로 확장합니다.
oc get events -A --sort-by=".metadata.creationTimestamp"
$ oc get events -A --sort-by=".metadata.creationTimestamp"
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--sort-by=".metadata.creationTimestamp"
플래그는 가장 최근 이벤트를 출력의 끝에 배치합니다.
클러스터의 모든 이벤트 결과를 필터링하려면
grep
명령을 사용하면 됩니다. 예를 들어, 오류를 찾는 경우 오류는 출력의 두 가지 섹션, 즉TYPE
섹션과MESSAGE
섹션에 나타날 수 있습니다.grep
명령을 사용하면error
,failed
등의 키워드를 검색할 수 있습니다.예를 들어, 다음 명령을 실행하여
경고
나오류가
포함된 메시지를 검색합니다.oc get events -A | grep -Ei "warning|error"
$ oc get events -A | grep -Ei "warning|error"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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 Copied! Toggle word wrap Toggle overflow 선택 사항: 이벤트를 정리하고 반복되는 이벤트만 보려면 다음 명령을 실행하여 관련 네임스페이스에서 이벤트를 삭제할 수 있습니다.
oc delete events -n <namespace> --all
$ oc delete events -n <namespace> --all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
자세한 내용은 "클러스터 이벤트 감시"를 참조하세요.
17.3.2.5. 포드에 연결 링크 복사링크가 클립보드에 복사되었습니다!
oc rsh
명령을 사용하면 현재 실행 중인 Pod에 직접 연결할 수 있으며, 해당 Pod에 셸을 제공합니다.
저지연 애플리케이션을 실행하는 포드에서 oc rsh
명령을 실행하면 지연 문제가 발생할 수 있습니다. oc debug
명령을 사용하여 노드에 연결할 수 없는 경우에만 oc rsh
명령을 사용하세요.
프로세스
다음 명령을 실행하여 Pod에 연결합니다.
oc rsh -n <namespace> busybox-1
$ oc rsh -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
자세한 내용은 "oc rsh" 및 "실행 중인 Pod에 액세스"를 참조하세요.
17.3.2.6. 포드 디버깅 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 프로덕션 중인 Pod와 직접 상호 작용하지 않으려 합니다.
운행 중인 교통을 방해하지 않으려면 원래 포드의 복사본인 보조 포드를 사용할 수 있습니다. 2차 포드는 원래 포드와 동일한 구성요소를 사용하지만 운행 교통이 없습니다.
프로세스
다음 명령을 실행하여 포드를 나열합니다.
oc get pod
$ oc get pod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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 Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Pod를 디버깅합니다.
oc debug -n <namespace> busybox-1
$ oc debug -n <namespace> busybox-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
Starting pod/busybox-1-debug, command was: sleep 3600 Pod IP: 10.133.2.11
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 셸 프롬프트가 보이지 않으면 Enter를 누르세요.
자세한 내용은 "oc debug" 및 "root 액세스로 디버그 포드 시작"을 참조하세요.
17.3.2.7. 포드에서 명령 실행 링크 복사링크가 클립보드에 복사되었습니다!
포드에 직접 로그인하지 않고도 포드에서 명령이나 명령 세트를 실행하려면 oc exec -it
명령을 사용하면 됩니다. 포드와 빠르게 상호작용하여 포드에서 프로세스나 출력 정보를 얻을 수 있습니다. 일반적인 사용 사례는 스크립트 내에서 oc exec -it
명령을 실행하여 복제본 세트 또는 배포 내의 여러 포드에서 동일한 명령을 실행하는 것입니다.
저지연 애플리케이션을 실행하는 포드에서 oc exec
명령은 지연 문제를 일으킬 수 있습니다.
프로세스
로그인하지 않고 포드에서 명령을 실행하려면 다음 명령을 실행하세요.
oc exec -it <pod> -- <command>
$ oc exec -it <pod> -- <command>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
자세한 내용은 "oc exec" 및 "컨테이너에서 원격 명령 실행"을 참조하세요.
17.3.3. 클러스터 유지 관리 링크 복사링크가 클립보드에 복사되었습니다!
통신사 네트워크에서는 베어메탈 배포의 특성으로 인해 특정 구성에 더 많은 주의를 기울여야 합니다. 다음 작업을 완료하여 보다 효과적으로 문제를 해결할 수 있습니다.
- 실패하거나 오류가 발생한 하드웨어 구성 요소를 모니터링합니다.
- 클러스터 운영자의 상태를 주기적으로 확인하세요
하드웨어 모니터링의 경우, 해당 하드웨어 공급업체에 문의하여 해당 하드웨어에 적합한 로깅 도구를 찾으세요.
17.3.3.1. 클러스터 운영자 확인 링크 복사링크가 클립보드에 복사되었습니다!
문제를 조기에 발견하려면 클러스터 운영자의 상태를 주기적으로 확인하세요.
프로세스
다음 명령을 실행하여 클러스터 운영자의 상태를 확인하세요.
oc get co
$ oc get co
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.3.2. 실패한 포드를 감시합니다 링크 복사링크가 클립보드에 복사되었습니다!
문제 해결 시간을 줄이려면 클러스터에서 실패한 Pod를 정기적으로 모니터링하세요.
프로세스
실패한 Pod를 감시하려면 다음 명령을 실행하세요.
oc get po -A | grep -Eiv 'complete|running'
$ oc get po -A | grep -Eiv 'complete|running'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.4. 보안 링크 복사링크가 클립보드에 복사되었습니다!
탄력적인 통신사 네트워크를 구축하려면 강력한 클러스터 보안 프로필을 구현하는 것이 중요합니다.
17.3.4.1. 인증 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에 어떤 ID 공급자가 있는지 확인하세요. 지원되는 ID 공급자에 대한 자세한 내용은 인증 및 권한 부여 에서 "지원되는 ID 공급자"를 참조하세요.
어떤 공급자가 구성되어 있는지 확인한 후 openshift-authentication
네임스페이스를 검사하여 잠재적인 문제가 있는지 확인할 수 있습니다.
프로세스
다음 명령을 실행하여
openshift-authentication
네임스페이스의 이벤트를 확인하세요.oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
$ oc get events -n openshift-authentication --sort-by='.metadata.creationTimestamp'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
openshift-authentication
네임스페이스의 포드를 확인하세요.oc get pod -n openshift-authentication
$ oc get pod -n openshift-authentication
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 더 많은 정보가 필요하면 다음 명령을 실행하여 실행 중인 포드 중 하나의 로그를 확인하세요.
oc logs -n openshift-authentication <pod_name>
$ oc logs -n openshift-authentication <pod_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
$ openssl x509 -enddate -noout -in <cert_file_name>.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
프록시 인증서를 갱신하는 방법과 시기를 결정하는 방법에 대한 자세한 내용은 보안 및 규정 준수 의 "프록시 인증서"를 참조하세요.
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
$ 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 Copied! Toggle word wrap Toggle overflow
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를 일시 중지하여 모든 변경 사항을 동시에 적용할 수 있습니다.
프로세스
다음 명령을 실행하여 영향을 받은 MCP를 일시 중지합니다.
oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":true}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터에 모든 머신 구성 변경 사항을 적용한 후 다음 명령을 실행합니다.
oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
$ oc patch mcp/<mcp_name> --type merge --patch '{"spec":{"paused":false}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이렇게 하면 MCP의 노드가 새로운 구성으로 재부팅될 수 있습니다.
17.3.7. 베어 메탈 노드 유지 관리 링크 복사링크가 클립보드에 복사되었습니다!
일반적인 문제 해결을 위해 노드에 연결할 수 있습니다. 그러나 어떤 경우에는 특정 하드웨어 구성 요소에 대한 문제 해결이나 유지 관리 작업을 수행해야 합니다. 이 섹션에서는 하드웨어 유지 관리를 수행하는 데 필요한 항목을 설명합니다.
17.3.7.1. 클러스터의 베어 메탈 노드에 연결 링크 복사링크가 클립보드에 복사되었습니다!
일반적인 유지 관리 작업을 위해 베어 메탈 클러스터 노드에 연결할 수 있습니다.
호스트 운영 체제에서 클러스터 노드를 구성하는 것은 권장되지 않으며 지원되지 않습니다.
노드 문제를 해결하려면 다음 작업을 수행할 수 있습니다.
- 노드에서 로그 검색
- 디버깅을 사용하세요
- SSH를 사용하여 노드에 연결합니다.
oc debug
명령으로 노드에 연결할 수 없는 경우에만 SSH를 사용하세요.
프로세스
다음 명령을 실행하여 노드에서 로그를 검색합니다.
oc adm node-logs <node_name> -u crio
$ oc adm node-logs <node_name> -u crio
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 디버깅을 사용하세요.
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를/host
로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 결과
You are now logged in as root on the node
You are now logged in as root on the node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 다음 명령을 실행하여 SSH를 사용하여 노드에 연결합니다.
ssh core@<node_name>
$ ssh core@<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.3.7.2. 클러스터 내의 포드로 애플리케이션 이동 링크 복사링크가 클립보드에 복사되었습니다!
예정된 하드웨어 유지 관리를 위해서는 포드 작업 부하에 영향을 주지 않고 클러스터 내의 다른 노드로 애플리케이션 포드를 이동하는 방법을 고려해야 합니다.
프로세스
다음 명령을 실행하여 노드를 예약 불가능으로 표시합니다.
oc adm cordon <node_name>
$ oc adm cordon <node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
노드를 예약할 수 없는 경우 노드에 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 주소를 변경하는 구체적인 절차가 없는 경우 네트워크 관리자나 네트워크 하드웨어 공급업체에 문의하세요.