$ oc login -u kubeadmin -p <password> https://FQDN:6443
默认 API 服务器证书由内部 OpenShift Container Platform 集群 CA 颁发。默认情况下,集群外部的客户端将无法验证 API 服务器的证书。此证书可以替换为客户端信任的 CA 颁发的证书。
默认 API 服务器证书由内部 OpenShift Container Platform 集群 CA 颁发。您可以添加一个或多个备用证书,API 服务器将根据客户端请求的完全限定域名 (FQDN) 返回这些证书,例如使用反向代理或负载均衡器时。
您必须拥有 FQDN 的证书及其对应的私钥。每个证书都应位于单独的 PEM 格式文件中。
私钥必须未加密。如果您的密钥已加密,请在将其导入 OpenShift Container Platform 之前对其进行解密。
证书必须包含显示 FQDN 的subjectAltName
扩展。
证书文件可以包含一个或多个证书链中的证书。API 服务器 FQDN 的证书必须是文件中的第一个证书。然后可以跟随着任何中间证书,文件应以根 CA 证书结尾。
不要为内部负载均衡器 (主机名 |
以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
1 | <secret> 是将包含证书链和私钥的密钥的名称。 |
2 | </path/to/cert.crt> 是本地文件系统上证书链的路径。 |
3 | </path/to/cert.key> 是与该证书关联的私钥的路径。 |
更新 API 服务器以引用已创建的密钥。
$ oc patch apiserver cluster \
--type=merge -p \
'{"spec":{"servingCerts": {"namedCertificates":
[{"names": ["<FQDN>"], (1)
"servingCertificate": {"name": "<secret>"}}]}}}' (2)
1 | 将<FQDN> 替换为 API 服务器应为此提供证书的 FQDN。 |
2 | 将<secret> 替换为上一步中使用的密钥名称。 |
检查apiserver/cluster
对象并确认现在已引用该密钥。
$ oc get apiserver cluster -o yaml
...
spec:
servingCerts:
namedCertificates:
- names:
- <FQDN>
servingCertificate:
name: <secret>
...
检查kube-apiserver
操作符,并验证 Kubernetes API 服务器的新版本是否已推出。操作符可能需要一分钟才能检测到配置更改并触发新的部署。在新的版本推出期间,PROGRESSING
将报告True
。
$ oc get clusteroperators kube-apiserver
除非PROGRESSING
显示为False
,否则请勿继续下一步操作,如下所示:
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
kube-apiserver 4.17.0 True False False 145m
如果PROGRESSING
显示为True
,请等待几分钟后再试。
只有在首次添加名为 API server 的证书时,Kubernetes API 服务器才会推出新版本。当名为 API server 的证书被续期时,Kubernetes API 服务器不会推出新版本,因为 |