Início / server / Perguntas / 1163539
Accepted
lsambo
Asked: 2024-08-06 16:03:08 +0800 CST

Kubernetes kube-apiserver não pode inicializar após a renovação dos certificados kubeadm, conexão oidc recusada

  • 772

Em um cluster Kubernetes 1.25 com 2 controladores Ubuntu, após detectar a expiração de certificados dentro de /etc/kubernetes/pki, lançamos o comando 'kubeadm promote all' em ambos os nós controladores e reinicializamos os nós.

Após a reinicialização, o kube-apiserver não consegue mais inicializar e seu contêiner docker continua travando.

Os logs do docker reclamam de não alcançar o servidor oidc (é um pod keycloak), então parece que o conector oidc é obrigatório para iniciar o servidor api:

{"log":"I0805 13:24:51.011009       1 plugins.go:158] Loaded 12 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,NodeRestriction,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,StorageObjectInUseProtection,RuntimeClass,DefaultIngressClass,MutatingAdmissionWebhook.\n","stream":"stderr","time":"2024-08-05T13:24:51.011063776Z"}
{"log":"I0805 13:24:51.011027       1 plugins.go:161] Loaded 11 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,PodSecurity,Priority,PersistentVolumeClaimResize,RuntimeClass,CertificateApproval,CertificateSigning,CertificateSubjectRestriction,ValidatingAdmissionWebhook,ResourceQuota.\n","stream":"stderr","time":"2024-08-05T13:24:51.011072396Z"}
{"log":"I0805 13:24:51.013060       1 etcd.go:292] \"Using watch cache\" resource=\"customresourcedefinitions.apiextensions.k8s.io\"\n","stream":"stderr","time":"2024-08-05T13:24:51.013133647Z"}
{"log":"E0805 13:25:01.010261       1 oidc.go:335] oidc authenticator: initializing plugin: Get \"https://10.10.2.123/admin/master/console/#/MYORGANIZATION/.well-known/openid-configuration\": dial tcp 10.10.2.123:443: connect: connection refused\n","stream":"stderr","time":"2024-08-05T13:25:01.010450438Z"}
{"log":"E0805 13:25:11.009612       1 oidc.go:335] oidc authenticator: initializing plugin: Get \"https://10.10.2.123/admin/master/console/#/MYORGANIZATION/.well-known/openid-configuration\": dial tcp 10.10.2.123:443: connect: connection refused\n","stream":"stderr","time":"2024-08-05T13:25:11.009785705Z"}

Os logs do kubelet dizem que o kubelet não consegue encontrar o primeiro nó do kubernetes (esperado porque o kube-apiserver não está funcionando):

Aug 05 16:33:21 mynode1hostname kubelet[3556]: E0805 16:33:21.973266    3556 kubelet.go:2448] "Error getting node" err="node \"mynode1hostname\" not found"
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.032233    3556 controller.go:144] failed to ensure lease exists, will retry in 7s, error: Get "https://10.10.2.123:6443/apis/coordination.k8s.io/v1/namespaces/kube-node-lease/leases/mynode1hostname?timeout=10s": dial tcp 10.10.2.123:6443: connect: connection refused
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.074320    3556 kubelet.go:2448] "Error getting node" err="node \"mynode1hostname\" not found"
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.083596    3556 file.go:182] "Provided manifest path is a directory, not recursing into manifest path" path="/etc/kubernetes/manifests/BACKUP"
Aug 05 16:33:22 mynode1hostname kubelet[3556]: E0805 16:33:22.174820    3556 kubelet.go:2448] "Error getting node" err="node \"mynode1hostname\" not found"

O arquivo kube-apiserver.yaml é bastante padrão. Tentamos remover a dependência do OIDC comentando suas linhas sem sucesso, pois o kubelet ainda reclama por não alcançar o OIDC (então o OIDC parece um loop morto circular, pois o kubelet não pode iniciar sem oidc e o pod keycloak não pode iniciar devido ao kubelet falhar e assim por diante):

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.10.2.123:6443
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=10.10.2.123
    - --anynomous-auth=true
    - --allow-privileged=true
    - --audit-log-path=/var/log/kube-apiserver.log
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-issuer=https://kubernetes.default.svc.cluster.local
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
    - --service-cluster-ip-range=10.96.0.0/12
    - --token-auth-file=/etc/kubernetes/passwords.csv
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
      #    - --oidc-issuer-url=https://10.10.2.123/admin/master/console/#/MYORGANIZATION
      #    - --oidc-client-id=Kubernetes
      #    - --oidc-username-claim=username
      #    - --oidc-groups-claim=group
    - -v=5
    image: registry.k8s.io/kube-apiserver:v1.25.11
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 10.10.2.123
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: kube-apiserver
    readinessProbe:
      failureThreshold: 3
      httpGet:
        host: 10.10.2.123
        path: /readyz
        port: 6443
        scheme: HTTPS
      periodSeconds: 1
      timeoutSeconds: 15
    resources:
      requests:
        cpu: 250m
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 10.10.2.123
        path: /livez
        port: 6443
        scheme: HTTPS
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/ca-certificates
      name: etc-ca-certificates
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
    - mountPath: /usr/local/share/ca-certificates
      name: usr-local-share-ca-certificates
      readOnly: true
    - mountPath: /usr/share/ca-certificates
      name: usr-share-ca-certificates
      readOnly: true
  hostNetwork: true
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/ca-certificates
      type: DirectoryOrCreate
    name: etc-ca-certificates
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs
  - hostPath:
      path: /usr/local/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-local-share-ca-certificates
  - hostPath:
      path: /usr/share/ca-certificates
      type: DirectoryOrCreate
    name: usr-share-ca-certificates
status: {}

Alguém também encontrou um caso semelhante após renovar os certificados do Kubernetes e reiniciar os nós? Tentei pesquisar no SO sem nenhuma evidência clara deste caso.

Agradeço antecipadamente

ubuntu

2 respostas

  1. Com base no título da pergunta, o problema parece ser uma incompatibilidade nos certificados após a renovação e um possível problema de configuração relacionado à integração do OIDC.

    Siga as etapas de solução de problemas abaixo:

    • Certifique-se de que os caminhos do certificado especificados no arquivo de configuração do kube-apiserver (/etc/kubernetes/pki/)estejam corretos e apontem para os certificados recém-gerados após a renovação e verifique também o arquivo de log do kube-apiserver para mensagens de erro específicas relacionadas à validação do certificado.
    • Reinicie os nós do controlador e os pods kube apiserver. Ao fazer isso, o kube-apiserver deverá ser capaz de iniciar sem depender do OIDC.
    • Após a reinicialização do sistema, certifique-se de que o pod Keycloak funcione bem, o que pode ser verificado executando:Kubectl get pods -n kube-system
    • Certifique-se de que o serviço keycloak esteja exposto e acessível nos pods kube-apiserver. Use kubectl get service -n kube -systempara verificar o serviço e seus terminais.
    • Certifique-se de ter verificado problemas de conectividade de rede ou outras políticas de firewall ou rede que possam bloquear a comunicação entre os pods kube apiserver e o serviço keycloak.
    • E se todas essas etapas de solução de problemas não funcionarem, significa que sua configuração precisa do OIDC e, nesse caso, sugiro começar tudo de novo para reinstalar seu cluster kubernetes com kubeadm init & kubeadm join em cada nó do controlador que pode recriar o estado do cluster ter certificados atualizados para talvez corrigir problemas de configuração também.

    Consulte este link do Github e o blog Medium escrito por Bob Killen para obter mais informações.

    • 1
  2. Best Answer

    Para qualquer pessoa que possa encontrar um problema semelhante: A dependência do oidc exigia um endpoint funcional do keycloak.

    No nosso caso, o keycloak não estava funcionando corretamente (descobrimos em seus logs problemas de conexão com seu postgresdb).

    Desativamos totalmente as partes oidc do kube-apiserver e, dessa forma, solicitamos que o api-server inicialize sem integração oidc/sso/keycloak.

    Para "forçar" o kube-apiserver a iniciar novamente a partir do novo yaml em /etc/kubernetes/manifests, vimos que mover para fora e mover o arquivo yamls de e para /etc/kubernetes/manifests de alguma forma "aciona" a reimplantação de a janela de encaixe kube-apiserver (junto com a reinicialização do serviço kubelet).

    Em qualquer caso, o kubelet está lendo continuamente do /etc/kubernetes/manifests (se você não alterou o caminho yaml do padrão), então comentar as linhas oidc do kube-apiserver é suficiente para gerar um novo kube- janela de encaixe do apiserver.

    • 0

relate perguntas