3.2. API 서버 인증서 추가
기본 API 서버 인증서는 내부 OpenShift Container Platform 클러스터 CA에서 발급합니다. 클러스터 외부의 클라이언트는 기본적으로 API 서버의 인증서를 확인할 수 없습니다. 이 인증서는 클라이언트가 신뢰하는 CA에서 발급한 인증서로 교체할 수 있습니다.
3.2.1. certificate이라는 API 서버 추가
기본 API 서버 인증서는 내부 OpenShift Container Platform 클러스터 CA에서 발급합니다. 리버스 프록시 또는 로드 밸런서가 사용되는 경우와 같이 클라이언트가 요청한 정규화된 도메인 이름(FQDN)을 기반으로 API 서버가 반환할 대체 인증서를 하나 이상 추가할 수 있습니다.
사전 요구 사항
- FQDN의 인증서와 해당 개인 키가 있어야 합니다. 각각은 별도의 PEM 형식 파일이어야 합니다.
- 개인 키는 암호화되지 않아야 합니다. 키가 암호화된 경우 OpenShift Container Platform으로 가져오기 전에 키의 암호를 해독합니다.
-
인증서에는 FQDN을 표시하는
subjectAltName
확장자가 포함되어야 합니다. - 인증서 파일은 체인에 하나 이상의 인증서를 포함할 수 있습니다. API 서버 FQDN의 인증서는 파일의 첫 번째 인증서여야 합니다. 그런 다음 중간 인증서가 올 수 있으며 파일은 루트 CA 인증서로 끝나야 합니다.
내부 로드 밸런서용으로 이름 지정된 인증서를 제공하지 마십시오(host name api-int.<cluster_name>.<base_domain>
). 그렇지 않으면 클러스터 성능이 저하됩니다.
프로세스
kubeadmin
사용자로 새 API에 로그인합니다.$ oc login -u kubeadmin -p <password> https://FQDN:6443
kubeconfig
파일을 가져옵니다.$ oc config view --flatten > kubeconfig-newapi
openshift-config
네임스페이스에 인증서 체인과 개인 키가 포함된 보안을 생성합니다.$ oc create secret tls <secret> \1 --cert=</path/to/cert.crt> \2 --key=</path/to/cert.key> \3 -n openshift-config
생성된 보안을 참조하도록 API 서버를 업데이트합니다.
$ oc patch apiserver cluster \ --type=merge -p \ '{"spec":{"servingCerts": {"namedCertificates": [{"names": ["<FQDN>"], 1 "servingCertificate": {"name": "<secret>"}}]}}}' 2
apiserver/cluster
오브젝트를 조사하고 보안이 이제 참조되는지 확인합니다.$ oc get apiserver cluster -o yaml
출력 예
... spec: servingCerts: namedCertificates: - names: - <FQDN> servingCertificate: name: <secret> ...
kube-apiserver
운영자를 확인하고 Kubernetes API 서버의 새 버전이 롤아웃되는지 확인합니다. 운영자가 구성 변경 사항을 탐지하고 새 배포를 트리거하는 데 1분 정도 걸릴 수 있습니다. 새 버전이 롤아웃되는 동안PROGRESSING
은True
를 보고합니다.$ oc get clusteroperators kube-apiserver
다음 출력에 표시된 것처럼
PROGRESSING
이False
로 표시될 때까지 다음 단계를 진행하지 마십시오.출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE kube-apiserver 4.6.0 True False False 145m
PROGRESSING
에True
가 표시되면 몇 분 기다렸다가 다시 시도하십시오.