
Ich verwende Kubernet zum Bereitstellen meiner Anwendung: Hier ist meine Servicebeschreibung:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: flaskgql
labels:
name: flaskgql
spec:
replicas: 1
template:
metadata:
labels:
name: flaskgql
spec:
containers:
- name: flaskgql
image: cryptodraco/flask_gql
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
volumeMounts:
- name: secrets
mountPath: /etc/secrets
readOnly: true
volumes:
- name: secrets
secret:
secretName: db-passwords
---
apiVersion: v1
kind: Service
metadata:
name: flaskgql
labels:
name: flaskgql
spec:
type: LoadBalancer
#loadBalancerIP: 35.189.238.42
ports:
- port: 80
targetPort: 8080
selector:
name: flaskgql
Wenn ich meine Leistungen aufliste, ist alles in Ordnung:
flaskgql LoadBalancer 10.59.251.206 35.189.238.42 80:30677/TCP 6m
Und meine Docker-Datei sieht wie folgt aus:
FROM gcr.io/google_appengine/python
RUN virtualenv /env
# source venv/bin/activate
ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH
ADD requirements.txt /app/requirements.txt
RUN pip install -r /app/requirements.txt
# no database - SQL only
#ENV NODB 1
ADD . /app
CMD gunicorn -b :$PORT wsgi:app
Aber wenn ich versuche, auf meine zugewiesene statische IP zuzugreifen, funktioniert es nicht. Hinweis: Ich habe das Gleiche schon einmal gemacht und es war in Ordnung. Aber jetzt, wenn ich auf die statische IP zugreife, erhalte ich einen 404-Fehler. Es scheint, als ob mein Gunicorn-Server nicht an die IP weitergeleitet wird. Selbst wenn ich von gcloud komme, erhalte ich:
Ich weiß nicht, ob es daran liegt, dass ich die VM statt der Instanz anhängen sollte. Aber ich weiß nur, dass es nicht funktioniert und ich habe keine Ahnung, wie ich das debuggen soll. Vielen Dank im Voraus
Antwort1
Zunächst einmal bedeutet „404 nicht gefunden“, dass die Anforderung an den gewünschten Server gesendet wird, dieser jedoch die angeforderte Datei nicht finden kann. Ich bezweifle, dass dies ein Problem mit der statischen IP ist.
Es gibt einige Dinge, die Sie tun können, um dies zu debuggen. Der erste Schritt besteht darin, sich per SSH bei einem Ihrer Knoten anzumelden und zu versuchen, über die Cluster-IP direkt eine Verbindung zum Pod herzustellen:
Listen Sie Ihre Pods zusammen mit ihrer Cluster-IP auf
kubectl get pods -o breit
Melden Sie sich per SSH bei einem der Knoten Ihres Clusters an, entweder über die GCP-Konsole oder mit dem Befehl „gcloud“
gcloud compute instances ssh [Knotenname]
Sobald Sie mit dem Knoten verbunden sind, führen Sie einen Curl-Befehl aus, um zu sehen, ob Ihr Container ordnungsgemäß auf Anfragen antwortet
curl [Pod-Cluster-IP]
Wenn dies eine 404-Fehlermeldung zurückgibt, bedeutet dies, dass ein Problem mit Ihrem Container-Image vorliegt. Entweder gibt es keine Dateien im Stammverzeichnis des Servers oder dieDocker-Image hat Port 80 nicht freigegeben.
Wenn dieser Test funktioniert, wissen Sie, dass der Container ordnungsgemäß funktioniert und dass möglicherweise ein Problem mit dem Dienst vorliegt.
Wiederholen Sie den Curl-Test mit der IP des LB-Serviceclusters.
Sie können sich auch an der Kapsel befestigen, um auf Aktivitäten zu achten
kubectl attach [Podname] -i
Zuletzt können Sie den GCP Load Balancer überprüfen, um festzustellen, ob dort Fehler gemeldet wurden, z. B. fehlerhafte Backends.
Ich bin nicht so gut mit Dockerfiles, aber das K8s-YAML sieht gut aus