3.2. API 서버 인증서 추가

프로세스

1. kubeadmin 사용자로 새 API에 로그인합니다.

   $ oc login -u kubeadmin -p <password> https://FQDN:6443

2. kubeconfig 파일을 가져옵니다.

   $ oc config view --flatten > kubeconfig-newapi

3. openshift-config 네임스페이스에 인증서 체인과 개인 키가 포함된 보안을 생성합니다.

   $ oc create secret tls <secret> \1
        --cert=</path/to/cert.crt> \2
        --key=</path/to/cert.key> \3
        -n openshift-config

   1

   <secret>은 인증서 체인과 개인 키를 포함할 보안의 이름입니다.

   2

   </path/to/cert.crt>는 로컬 파일 시스템의 인증서 체인 경로입니다.

   3

   </path/to/cert.key>는 이 인증서와 관련된 개인 키의 경로입니다.

4. 생성된 보안을 참조하도록 API 서버를 업데이트합니다.

   $ oc patch apiserver cluster \
        --type=merge -p \
        '{"spec":{"servingCerts": {"namedCertificates":
        [{"names": ["<FQDN>"], 1
        "servingCertificate": {"name": "<secret>"}}]}}}' 2

   1

   <FQDN>을 API 서버가 인증서를 제공해야 하는 FQDN으로 바꿉니다.

   2

   <secret>을 이전 단계에서 보안에 사용된 이름으로 교체합니다.

5. apiserver/cluster 오브젝트를 조사하고 보안이 이제 참조되는지 확인합니다.

   $ oc get apiserver cluster -o yaml

   출력 예

   ...
   spec:
     servingCerts:
       namedCertificates:
       - names:
         - <FQDN>
         servingCertificate:
           name: <secret>
   ...

6. kube-apiserver 운영자를 확인하고 Kubernetes API 서버의 새 버전이 롤아웃되는지 확인합니다. 운영자가 구성 변경 사항을 탐지하고 새 배포를 트리거하는 데 1분 정도 걸릴 수 있습니다. 새 버전이 롤아웃되는 동안 PROGRESSING은 True를 보고합니다.

   $ oc get clusteroperators kube-apiserver

   다음 출력에 표시된 것처럼 PROGRESSING이 False로 표시될 때까지 다음 단계를 진행하지 마십시오.

   출력 예

   NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
   kube-apiserver   4.11.0     True        False         False      145m

   PROGRESSING에 True가 표시되면 몇 분 기다렸다가 다시 시도하십시오.

   참고

   Kubernetes API 서버의 새 버전은 certificate라는 API 서버가 처음으로 추가되는 경우에만 롤아웃됩니다. certificate라는 API 서버가 갱신되면 kube-apiserver Pod가 업데이트된 인증서를 동적으로 다시 로드하므로 Kubernetes API 서버의 새 버전이 롤아웃되지 않습니다.