3.2. API サーバー証明書の追加
デフォルトの API サーバー証明書は、内部 OpenShift Container Platform クラスター CA によって発行されます。クラスター外のクライアントは、デフォルトで API サーバーの証明書を検証できません。この証明書は、クライアントが信頼する CA によって発行される証明書に置き換えることができます。
3.2.1. API サーバーの名前付き証明書の追加
デフォルトの API サーバー証明書は、内部 OpenShift Container Platform クラスター CA によって発行されます。リバースプロキシーやロードバランサーが使用される場合など、クライアントが要求する完全修飾ドメイン名 (FQDN) に基づいて、API サーバーが返す代替証明書を 1 つ以上追加できます。
前提条件
- FQDN とそれに対応するプライベートキーの証明書が必要です。それぞれが個別の PEM 形式のファイルである必要があります。
- プライベートキーの暗号化は解除されている必要があります。キーが暗号化されている場合は、これを OpenShift Container Platform にインポートする前に復号化します。
-
証明書には、FQDN を示す
subjectAltName
拡張が含まれる必要があります。 - 証明書ファイルでは、チェーンに 1 つ以上の証明書を含めることができます。API サーバー FQDN の証明書は、ファイルの最初の証明書である必要があります。この後には中間証明書が続き、ファイルの最後はルート CA 証明書にすることができます。
内部ロードバランサーに名前付きの証明書を指定しないようにしてください (ホスト名 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
namespace に証明書およびプライベートキーが含まれるシークレットを作成します。$ 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
Operator を確認し、Kubernetes API サーバーの新しいリビジョンがロールアウトされることを確認します。Operator が設定の変更を検出して新しいデプロイメントをトリガーするのに 1 分かかる場合があります。新しいリビジョンが公開されている間、PROGRESSING
はTrue
を報告します。$ oc get clusteroperators kube-apiserver
以下の出力にあるように、
PROGRESSING
がFalse
と表示されるまで次の手順に移行しないでください。出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE kube-apiserver 4.7.0 True False False 145m
PROGRESSING
がTrue
と表示されている場合は、数分待機してから再試行します。