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>). 그렇지 않으면 클러스터 성능이 저하됩니다.

절차

  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.12.0     True        False         False      145m

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

    참고

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