2
votes

Exécution du cluster kubernetes kubeadm derrière un pare-feu / serveur proxy d'entreprise

Nous avons un cluster à 5 nœuds qui a été déplacé derrière notre pare-feu / serveur proxy d'entreprise.

Selon les instructions ici: setup-up-standalone-kubernetes-cluster-behind-corporate-proxy p>

J'ai défini les variables d'environnement du serveur proxy en utilisant:

Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s

Maintenant, tout dans notre cluster fonctionne en interne. Cependant, lorsque j'essaie de créer un pod qui extrait une image de l'extérieur, le pod est bloqué sur ContainerCreating , par exemple,

Volumes:
  default-token-2kfbw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-2kfbw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age   From                          Message
  ----     ------                  ----  ----                          -------
  Normal   Scheduled               73s   default-scheduler             Successfully assigned default/busybox to thalia3.ahc.umn.edu
  Warning  FailedCreatePodSandBox  10s   kubelet, thalia3.ahc.umn.edu  Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "6af48c5dadf6937f9747943603a3951bfaf25fe1e714cb0b0cbd4ff2d59aa918" network for pod "busybox": NetworkPlugin cni failed to set up pod "busybox_default" network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: dial tcp 10.96.0.1:443: i/o timeout, failed to clean up sandbox container "6af48c5dadf6937f9747943603a3951bfaf25fe1e714cb0b0cbd4ff2d59aa918" network for pod "busybox": NetworkPlugin cni failed to teardown pod "busybox_default" network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: dial tcp 10.96.0.1:443: i/o timeout]
  Normal   SandboxChanged          10s   kubelet, thalia3.ahc.umn.edu  Pod sandbox changed, it will be killed and re-created.

est coincé ici:

k8s.io
kubernetes.io
docker.io
docker.com

Je suppose que cela est dû au fait que l'hôte / domaine sur lequel l'image est extraite n'est pas dans nos règles de proxy d'entreprise. Nous avons des règles pour

[gms@thalia0 ~]$ kubectl get pods
NAME                            READY   STATUS              RESTARTS   AGE
busybox                         0/1     ContainerCreating   0          17m

donc, je ne sais pas quels autres hôtes / domaines doivent être ajoutés.

J'ai fait une description des pods pour busybox et voir la référence à node.kubernetes.io (je mets une exception à l'échelle du domaine pour * .kubernetes.io qui, espérons-le, suffira).

Voici ce que j'obtiens de kubectl describe pods busybox :

[gms@thalia0 ~]$ kubectl apply -f https://k8s.io/examples/admin/dns/busybox.yaml
pod/busybox created

Je suppose que l'erreur calico est due à ceci: p >

export http_proxy=http://proxy-host:proxy-port/
export HTTP_PROXY=$http_proxy
export https_proxy=$http_proxy
export HTTPS_PROXY=$http_proxy
printf -v lan '%s,' localip_of_machine
printf -v pool '%s,' 192.168.0.{1..253}
printf -v service '%s,' 10.96.0.{1..253}
export no_proxy="${lan%,},${service%,},${pool%,},127.0.0.1";
export NO_PROXY=$no_proxy

Les pods calico et coredns semblent avoir des erreurs similaires atteignant node.kubernetes.io , donc je suppose que cela est dû au fait que notre serveur ne peut pas extraire les nouvelles images lors d'un redémarrage.

docker kubernetes http-proxy corporate-policy

0 commentaires

3 Réponses :

0
votes

Il ne semble pas que vous ayez de problème pour extraire l'image car vous devriez voir un état ImagePullBackOff . (Bien que cela puisse venir plus tard après le message d'erreur que vous voyez)

L'erreur que vous voyez de vos pods est liée au fait qu'ils ne peuvent pas se connecter au kube-apiserver en interne. Cela ressemble à un délai d'expiration, donc il y a probablement quelque chose avec le service kubernetes dans votre espace de noms par défaut. Vous pouvez le vérifier comme ceci, par exemple:

$ cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  labels:
    component: apiserver
    provider: kubernetes
  name: kubernetes
  namespace: default
spec:
  clusterIP: 10.96.0.1
  type: ClusterIP
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: 443
EOF

Il se peut qu'il manque (?) Vous pouvez toujours le recréer:

$ kubectl -n default get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   2d20h

La tolérance veut essentiellement dire que le pod peut tolérer d'être planifié sur un nœud qui a le node.kubernetes.io/not-ready:NoExecute et node.kubernetes .io / injoignable: NoExecute est teinté mais votre erreur ne semble pas être liée à cela.

1 commentaires

Je pense que cela pourrait être dû au fait de ne pas configurer de règles de proxy sur les nœuds non maîtres, puis de redémarrer docker et kubelet, mais je suis frustré et j'ai simplement démoli et reconstruit le cluster et tout est maintenant entièrement fonctionnel. Lorsque je l'ai déchiré pour la première fois et reconstruit les nœuds, je n'ai pas pu extraire les images, mais après avoir ajouté des règles de proxy et tout redémarré, tout allait bien. Hypothèse intéressante que vous avez posée. Pas sur le point de le tester, car tout fonctionne.

0
votes

Le problème signifie normalement que le démon docker est incapable de répondre.

Si un autre service consomme plus de CPU ou d'E / S, ce problème peut se produire.

1 commentaires

Oui, voir mon commentaire ci-dessus. J'ai résolu le problème. Le proxy n'a pas été configuré pour les nœuds worker et, par conséquent, ils ne peuvent pas extraire d'images.

1
votes

Il semble que vous ayez mal compris quelques concepts Kubernetes que j'aimerais clarifier ici. Les références à node.kubernetes.io ne constituent pas une tentative d'appels réseau vers ce domaine. C'est simplement la convention que Kubernetes utilise pour spécifier des clés de chaîne. Donc, si jamais vous devez appliquer des étiquettes, des annotations ou des tolérances, vous définirez vos propres clés telles que subdomain.domain.tld / some-key .

Quant au problème Calico que vous rencontrez , cela ressemble à l'erreur:

network: error getting ClusterInformation: Get https://[10.96.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformations/default: dial tcp 10.96.0.1:443: i/o timeout]

est notre coupable ici. 10.96.0.1 est l'adresse IP utilisée pour faire référence au serveur d'API Kubernetes dans les pods. Il semble que le pod calico / node en cours d'exécution sur votre nœud ne parvienne pas à atteindre le serveur API. Pourriez-vous plus de contexte sur la façon dont vous configurez Calico? Savez-vous quelle version de Calico vous utilisez?

Le fait que votre instance calico / node tente d'accéder à crd.projectcalico.org/v1/clusterinformations m'indique qu'elle utilise la banque de données Kubernetes pour son backend. Êtes-vous sûr de ne pas essayer d'exécuter Calico en mode Etcd?

2 commentaires

Merci pour la vue d'ensemble. Oui, j'ai compris que node.kubernetes.io était une référence interne et que l'erreur était de ne pas pouvoir communiquer avec le serveur api. Tout est en mode par défaut. Et le coupable était en fait que docker ne pouvait pas extraire de nouvelles images et que les k8 ne pouvaient pas reconstruire les conteneurs pour déployer de nouveaux pods.

Je suis content que vous l'aillez compris!