Monitor dieser Service zu Pod Iptables Mappings sind aktuelle

Question

Das Problem trat auf Kubernetes 1.2.3 auf, aber wir laufen 1.3.3 jetzt.

Wir hatten 2 Situationen, in denen Kube-Proxy lief, aber verkeilt war und nicht iptables mit dem aktuellen Stand der Dienste zu Pods aktualisiert. Dies führte zu einer Situation, in der Verkehr, der für den Service bestimmt war, an Pods weitergeleitet wurde, die Teil von ServiceB sind. Also haben wir unser Monitoring nachträglich verbessert, um auf dem Kube-Proxy abzufragen. Ich frage mich, ob ich etwas über die Existenz des Kube-Proxy-Prozesses hinaus überwachen sollte und dass es 200 von/healthz zurückgibt.

Überwachen Sie alles Weitere, um sicherzustellen, dass der Dienst für Pod-Mappings aktuell ist. Mir ist klar, dass sich die Service-Landschaft verändert, so dass wir einen gewissen Zeitraum haben, in dem alle Hosts nicht genau sind, aber ich bin nur an dem Szenario interessiert, in dem 3 Minuten vergangen sind und iptables nicht auf jedem Knoten aktuell ist der Cluster, der mir zu zeigen scheint, dass irgendwo etwas kaputt ist.

Ich hatte über einen Kanarienvogel-Dienst nachgedacht, bei dem die Backing-Bereitstellung alle 5 Minuten neu implementiert wird. Anschließend überprüfe ich von jedem Knoten, dass ich über den Dienstcluster ip alle Backing-Pods erreichen kann.

Ich bin mir nicht sicher, ob dies der richtige Ansatz ist. Es scheint so, als könnte es das Problem, das wir früher hatten, auffangen, aber ich denke auch, dass ein anderer einfacherer Weg existieren könnte, als nur den Zeitstempel zu überprüfen, als iptables zuletzt aktualisiert wurde?

Danke!

Answer 1

Sie könnten kube-proxy innerhalb eines Pods ausführen (indem Sie ein Manifest innerhalb von /etc/kubernetes/manifests auf jedem Knoten löschen), profitieren Sie von den von Kubernetes angebotenen Health Check/Liveness-Tests und lassen Sie den Dienst im Falle eines Problems neu starten .

Die Einstellung eines sehr niedrigen Schwellenwerts für den Liveness-Test löst einen Neustart aus, sobald der Endpunkt /healthz zu lange zum Antworten braucht. Es garantiert Ihnen nicht, dass iptables-Regeln sind immer up-to-date, aber wird dafür sorgen, dass die kube-proxy immer gesund ist

Beispiel (was wiederum iptables-Regeln sind im Einklang gewährleisten):

Überprüfen Sie den healthz Endpunkt von kube-proxy alle 10s. Starten Sie den Pod neu, wenn er nicht in weniger als 1s antwortet:

apiVersion: v1 
kind: Pod 

metadata: 
    name: kube-proxy 
    namespace: kube-system 

spec: 
    hostNetwork: true 

    containers: 

    - name: kube-proxy 
    image: gcr.io/google_containers/hyperkube:v1.3.4 
    command: 
    - /hyperkube 
    - proxy 
    - --master=https://master.kubernetes.io:6443 
    - --kubeconfig=/conf/kubeconfig 
    - --proxy-mode=iptables 

    livenessProbe: 
     httpGet: 
     path: /healthz 
     port: 10249 
     timeoutSeconds: 1 
     periodSeconds: 10 
     failureThreshold: 1 

    securityContext: 
     privileged: true 

    volumeMounts: 
    - mountPath: /conf/kubeconfig 
     name: kubeconfig 
     readOnly: true 
    - mountPath: /ssl/kubernetes 
     name: ssl-certs-kubernetes 
     readOnly: true 
    - mountPath: /etc/ssl/certs 
     name: ssl-certs-host 
     readOnly: true 

    volumes: 
    - hostPath: 
     path: /etc/kubernetes/proxy-kubeconfig.yml 
    name: kubeconfig 
    - hostPath: 
     path: /etc/kubernetes/ssl 
    name: ssl-certs-kubernetes 
    - hostPath: 
     path: /usr/share/ca-certificates 
    name: ssl-certs-host