Estou tendo um problema em que kube-apiserver.service sempre falhará no meu Fedora 36 local.
Obtendo os namespaces de um contexto Eu estava enfrentando problemas de certificado que me impediram de ter sucesso. Eu estava usando kubense recebendo o erro:
> error: You must be logged in to the server (Unauthorized)
> error getting namespace list
A primeira coisa que verifiquei meu ~/.kube/config e tudo parecia bem. Então, depois de algumas leituras e convencido de que era um erro de certificado (estávamos enfrentando erros de certificados com um cluster kube específico), instalei kubeadmvia yum ( sudo yum install kubernetes-kubeadm.x86_64). Usei-o para renovar automaticamente todos os certificados que precisavam, com o comando kubeadm certs renew all.
O comando saiu com uma saída limpa, nenhum erro sinalizado. Verificar o kubens ainda dá o mesmo erro. Então tentei reiniciar os serviços kube e tudo reiniciou bem, exceto kube-apiserver. Sempre ocorre o mesmo erro, muitos comandos de reinicialização repetidos muito rapidamente. Esta é a saída de sudo systemctl status kube-apiserver -l:
> × kube-apiserver.service - Kubernetes API Server
> Loaded: loaded (/usr/lib/systemd/system/kube-apiserver.service; enabled; vendor preset: disabled)
> Active: failed (Result: exit-code) since Thu 2022-11-17 09:07:44 CET; 12min ago
> Docs: https://kubernetes.io/docs/concepts/overview/components/#kube-apiserver
> https://kubernetes.io/docs/reference/generated/kube-apiserver/
> Process: 1752 ExecStart=/usr/bin/kube-apiserver $KUBE_LOGTOSTDERR $KUBE_LOG_LEVEL $KUBE_ETCD_SERVERS $KUBE_API_ADDRESS $KUBE_API_PORT
> $KUBELET_PORT > Main PID: 1752 (code=exited, status=1/FAILURE)
> CPU: 48ms
>
> Nov 17 09:07:44 fedora systemd[1]: kube-apiserver.service: Scheduled
> restart job, restart counter is at 5. Nov 17 09:07:44 fedora
> systemd[1]: Stopped kube-apiserver.service - Kubernetes API Server.
> Nov 17 09:07:44 fedora systemd[1]: kube-apiserver.service: Start
> request repeated too quickly. Nov 17 09:07:44 fedora systemd[1]:
> kube-apiserver.service: Failed with result 'exit-code'. Nov 17
> 09:07:44 fedora systemd[1]: Failed to start kube-apiserver.service -
> Kubernetes API Server.
Então procurei no Journalctl e encontrei esta seção de log:
> Nov 16 16:33:30 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=kube-apiserver comm="systemd" exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=failed'
> Nov 16 16:33:30 fedora systemd[1]: kube-apiserver.service: Scheduled restart job, restart counter is at 5.
> ░░ Automatic restarting of the unit kube-apiserver.service has been scheduled, as the result for
> Nov 16 16:33:30 fedora systemd[1]: Stopped kube-apiserver.service - Kubernetes API Server.
> ░░ Subject: A stop job for unit kube-apiserver.service has finished
> ░░ A stop job for unit kube-apiserver.service has finished.
> Nov 16 16:33:30 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=kube-apiserver comm="systemd" exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
> Nov 16 16:33:30 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> msg='unit=kube-apiserver comm="systemd" exe="/usr/lib/systemd/systemd"
> hostname=? addr=? terminal=? res=success'
> Nov 16 16:33:30 fedora systemd[1]: kube-apiserver.service: Start request repeated too quickly.
> Nov 16 16:33:30 fedora systemd[1]: kube-apiserver.service: Failed with result 'exit-code'.
> ░░ The unit kube-apiserver.service has entered the 'failed' state with result 'exit-code'.
> Nov 16 16:33:30 fedora systemd[1]: Failed to start kube-apiserver.service - Kubernetes API Server.
> ░░ Subject: A start job for unit kube-apiserver.service has failed
> ░░ A start job for unit kube-apiserver.service has finished with a failure.
> Nov 16 16:33:37 fedora kubelet[8800]: --rotate-certificates <Warning: Beta feature> Auto rotate the kubelet client certificates by
> requesting new certificates from the kube-apiserver when the
> certificate expiration approaches. (DEPRECATED: This parameter should
> be set via the config file specified by the Kubelet's --config flag.
> See
> https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
> for more information.)
> Nov 16 16:33:37 fedora kubelet[8800]: --rotate-server-certificates Auto-request and rotate the kubelet serving certificates by requesting
> new certificates from the kube-apiserver when the certificate
> expiration approaches. Requires the RotateKubeletServerCertificate
> feature gate to be enabled, and approval of the submitted
> CertificateSigningRequest objects. (DEPRECATED: This parameter should
> be set via the config file specified by the Kubelet's --config flag.
> See
> https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
> for more information.)
> Nov 16 16:33:47 fedora kubelet[8818]: --rotate-certificates <Warning: Beta feature> Auto rotate the kubelet client certificates by
> requesting new certificates from the kube-apiserver when the
> certificate expiration approaches. (DEPRECATED: This parameter should
> be set via the config file specified by the Kubelet's --config flag.
> See
> https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
> for more information.)
> Nov 16 16:33:47 fedora kubelet[8818]: --rotate-server-certificates Auto-request and rotate the kubelet serving certificates by requesting
> new certificates from the kube-apiserver when the certificate
> expiration approaches. Requires the RotateKubeletServerCertificate
> feature gate to be enabled, and approval of the submitted
> CertificateSigningRequest objects. (DEPRECATED: This parameter should
> be set via the config file specified by the Kubelet's --config flag.
> See
> https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
> for more information.)
> Nov 16 16:33:57 fedora kubelet[8834]: --rotate-certificates <Warning: Beta feature> Auto rotate the kubelet client certificates by
> requesting new certificates from the kube-apiserver when the
> certificate expiration approaches. (DEPRECATED: This parameter should
> be set via the config file specified by the Kubelet's --config flag.
> See
> https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
> for more information.)
> Nov 16 16:33:57 fedora kubelet[8834]: --rotate-server-certificates Auto-request and rotate the kubelet serving certificates by requesting
> new certificates from the kube-apiserver when the certificate
> expiration approaches. Requires the RotateKubeletServerCertificate
> feature gate to be enabled, and approval of the submitted
> CertificateSigningRequest objects. (DEPRECATED: This parameter should
> be set via the config file specified by the Kubelet's --config flag.
> See
> https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
> for more information.)
A saída de kubectl versioné:
> Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.7",
> GitCommit:"e6f35974b08862a23e7f4aad8e5d7f7f2de26c15",
> GitTreeState:"archive", BuildDate:"2022-10-14T00:00:00Z",
> GoVersion:"go1.18.7", Compiler:"gc", Platform:"linux/amd64"}
> Kustomize Version: v4.5.4
> error: You must be logged in to the server (the server has asked for the client to provide credentials)
(sim, contém uma mensagem de erro).
Realmente não sei para onde ir a partir daqui. O que você tentaria para colocar o kube-apiserver.service de volta nos trilhos?
Tentei desinstalar todos os pacotes kubernetes que encontrei em meu sistema:
sudo rpm -e kubernetes-client-1.24.7-1.fc36.x86_64 kubernetes-1.24.7-1.fc36.x86_64 kubernetes-master-1.24.7-1.fc36.x86_64
kubernetes-node-1.24.7-1.fc36.x86_64
depois de remover todos os plug-ins do kubectl por meio do krew. Então fiz backup do meu .kube/config e mudei o nome para toda a pasta ~/.kube. Reinstalei o kubernetes, neste momento kubectl versionestava retornando o erro da porta 8080, e pensei que fosse porque ainda não tenho um .kube/config. Reinstalei o krew e meus plug-ins kubectl favoritos (ctx, ns, cm) e reconstruí a configuração para todos os clusters kubernetes que preciso acessar (com comandos aws eks update-kubeconfige kubecm add -f <file>). Agora a versão kubectl tem uma saída mais normal:
> Client Version: version.Info{Major:"1", Minor:"24",
> GitVersion:"v1.24.7",
> GitCommit:"e6f35974b08862a23e7f4aad8e5d7f7f2de26c15",
> GitTreeState:"archive", BuildDate:"2022-10-14T00:00:00Z",
> GoVersion:"go1.18.7", Compiler:"gc", Platform:"linux/amd64"} Kustomize
> Version: v4.5.4 Server Version: version.Info{Major:"1", Minor:"21+",
> GitVersion:"v1.21.14-eks-fb459a0",
> GitCommit:"b07006b2e59857b13fe5057a956e86225f0e82b7",
> GitTreeState:"clean", BuildDate:"2022-10-24T20:32:54Z",
> GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"} WARNING:
> version difference between client (1.24) and server (1.21) exceeds the
> supported minor version skew of +/-1
running apenas sudo kube-apiserverfornece a saída:
> W1117 10:13:55.819927 16008 services.go:37] No CIDR for service
> cluster IPs specified. Default value which was 10.0.0.0/24 is
> deprecated and will be removed in future releases. Please specify it
> using --service-cluster-ip-range on kube-apiserver. I1117
> 10:13:56.031051 16008 serving.go:342] Generated self-signed cert
> (/var/run/kubernetes/apiserver.crt, /var/run/kubernetes/apiserver.key)
> I1117 10:13:56.031063 16008 server.go:558] external host was not
> specified, using 192.168.XX.XX W1117 10:13:56.031069 16008
> authentication.go:526] AnonymousAuth is not allowed with the
> AlwaysAllow authorizer. Resetting AnonymousAuth to false. You should
> use a different authorizer E1117 10:13:56.031184 16008 run.go:74]
> "command failed" err="[--etcd-servers must be specified,
> service-account-issuer is a required flag,
> --service-account-signing-key-file and --service-account-issuer are required flags]"
sudo systemctl status kube-apiserver ainda mostra estado de falha e sudo systemctl restart kube-apiserver ainda resulta em falha