El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe un posible problema de interrupción que los clientes podrían enfrentar cuando tienen un sistema basado en Kubernetes que se ha instalado durante más de 365 días. Además, sigue los pasos necesarios para solucionar la situación y poner en marcha el sistema basado en Kubernetes.
Después de un año de instalación predeterminada del clúster de Kubernetes, los certificados de cliente caducan. No podrá acceder a Cisco CloudCenter Suite (CCS). Aunque todavía aparecerá, no podrá iniciar sesión. Si navega a la CLI kubectl, verá este error, "No se puede conectar al servidor: x509: el certificado ha caducado o aún no es válido."
Puede ejecutar esta secuencia de comandos bash para ver la fecha de vencimiento de sus certificados:
for crt in /etc/kubernetes/pki/*.crt; do printf '%s: %s\n' \ "$(date --date="$(openssl x509 -enddate -noout -in "$crt"|cut -d= -f 2)" --iso-8601)" \ "$crt" done | sort
También puede encontrar un flujo de trabajo de código abierto para Action Orchestrator que supervisará este proceso diariamente y los alertará de problemas.
Los nuevos certificados se deben volver a emitir a través de Kubeadm a través del clúster y luego se debe volver a unir los nodos de los trabajadores a los maestros.
[root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes]# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8920 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:19:63:a2 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.20/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 37806sec preferred_lft 37806sec
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:d0:29:ce:5e brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever
13: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1430 qdisc noqueue state UNKNOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
inet 172.16.176.128/32 brd 172.16.176.128 scope global tunl0
valid_lft forever preferred_lft forever
14: cali65453a0219d@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1430 qdisc noqueue state UP group default
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 4
apiVersion: kubeadm.k8s.io/v1alpha1 kind: MasterConfiguration api: advertiseAddress: <IP ADDRESS FROM STEP 2> kubernetesVersion: v1.11.6
#NOTE: If the customer is running a load balancer VM then you must add these lines after...
#apiServerCertSANs:
#- <load balancer IP>
#Files #apiserver.crt #apiserver.key #apiserver-kubelet-client.crt #apiserver-kubelet-client.key #front-proxy-client.crt #front-proxy-client.key #ie cd /etc/kubernetes/pki mkdir backup mv apiserver.key backup/apiserver.key.bak
[root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes]# kubeadm --config kubeadmCERT.yaml alpha phase certs apiserver [certificates] Generated apiserver certificate and key. [certificates] apiserver serving cert is signed for DNS names [cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.1.20]
[root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 kubernetes]# kubeadm --config kubeadmCERT.yaml alpha phase kubeconfig all [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf" [kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config chmod 777 $HOME/.kube/config export KUBECONFIG=.kube/config
[root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1 Ready master 1y v1.11.6 cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a2 Ready master 1y v1.11.6 cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 Ready master 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1 NotReady <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a2 NotReady <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a3 NotReady <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a4 NotReady <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a5 NotReady <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a6 NotReady <none> 1y v1.11.6
[root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1 k8s-mgmt]# kubeadm token create
--print-join-command kubeadm join 192.168.1.14:6443 --token m1ynvj.f4n3et3poki88ry4
--discovery-token-ca-cert-hash
sha256:4d0c569985c1d460ef74dc01c85740285e4af2c2369ff833eed1ba86e1167575
rm /etc/kubernetes/pki/ca.crt rm /etc/kubernetes/kubelet.conf rm /etc/kubernetes/bootstrap-kubelet.conf
[root@cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1 kubernetes]# kubeadm join 192.168.1.14:6443 --token m1ynvj.f4n3et3poki88ry4 --discovery-token-ca-cert-hash sha256:4d0c569985c1d460ef74dc01c85740285e4af2c2369ff833eed1ba86e1167575 --node-name cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1 [preflight] running pre-flight checks [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}] you can solve this problem with following methods: 1. Run 'modprobe -- ' to load missing kernel modules; 2. Provide the missing builtin kernel ipvs support I0226 17:59:52.644282 19170 kernel_validator.go:81] Validating kernel version I0226 17:59:52.644421 19170 kernel_validator.go:96] Validating kernel config [discovery] Trying to connect to API Server "192.168.1.14:6443" [discovery] Created cluster-info discovery client, requesting info from "https://192.168.1.14:6443" [discovery] Requesting info from "https://192.168.1.14:6443" again to validate TLS against the pinned public key [discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "192.168.1.14:6443" [discovery] Successfully established connection with API Server "192.168.1.14:6443" [kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.11" ConfigMap in the kube-system namespace [kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" [kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env" [preflight] Activating the kubelet service [tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap... [patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1" as an annotation This node has joined the cluster: * Certificate signing request was sent to master and a response was received. * The Kubelet was informed of the new secure connection details. Run 'kubectl get nodes' on the master to see this node join the cluster.
[root@cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1 ~]# kubectl get nodes NAME STATUS ROLES AGE VERSION cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a1 Ready master 1y v1.11.6 cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a2 Ready master 1y v1.11.6 cx-ccs-prod-master-d7f34f25-f524-4f90-9037-7286202ed13a3 Ready master 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a1 Ready <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a2 Ready <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a3 Ready <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a4 Ready <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a5 Ready <none> 1y v1.11.6 cx-ccs-prod-worker-d7f34f25-f524-4f90-9037-7286202ed13a6 Ready <none> 1y v1.11.6