503 UH-Fehler bei Kubernetes mit Istio, aber der Dienst funktioniert
Ich habe ein Problem mit der richtigen Konfiguration der Kommunikation zwischen meinen Diensten auf Kubernetes (Minikube) mit installiertem Istio.
Ich versuche, eine POST
Anfrage von meinem Dienst an elasticsearch zu senden , aber die ganze Zeit erhalte ich:
POST /_bulk?timeout=1m HTTP/1.1" 503 UH "-" "-" 0 19 0 - "-" "Apache-HttpAsyncClient/4.1.4 (Java/11.0.9.1)" "1a290357-7b18-9692-9392-d0298ed3276c" "elasticsearch:9200" "-" - - 10.102.10.19:9200 172.18.0.12:39194 - default
Istioctl analyze
zeigt keine Probleme. Ich habe auch mtls deaktiviert.
Haben Sie eine Idee, was falsch sein könnte? Ich verstehe nicht, warum es UH (ungesund) gibt, weil Elasticsearch funktioniert und das Kiali-Dashboard es auch als gesund anzeigt.
Meine Bereitstellungen + Dienste:
Elasticsearch
apiVersion: v1
kind: Service
metadata:
name: elasticsearch
labels:
app: elasticsearch
tier: database
spec:
selector:
app: elasticsearch
ports:
- name: "http-9200"
port: 9200
targetPort: 9200
- name: "tcp-9300"
port: 9300
targetPort: 9300
selector:
app: elasticsearch
tier: database
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: elasticsearch
labels:
service: elasticsearch
spec:
serviceName: elasticsearch
replicas: 1
selector:
matchLabels:
service: elasticsearch
template:
metadata:
labels:
service: elasticsearch
spec:
terminationGracePeriodSeconds: 300
initContainers:
- name: fix-the-volume-permission
image: busybox
command:
- sh
- -c
- chown -R 1000:1000 /usr/share/elasticsearch/data
securityContext:
privileged: true
volumeMounts:
- name: data
mountPath: /usr/share/elasticsearch/data
- name: increase-the-vm-max-map-count
image: busybox
command:
- sysctl
- -w
- vm.max_map_count=262144
securityContext:
privileged: true
- name: increase-the-ulimit
image: busybox
command:
- sh
- -c
- ulimit -n 65536
securityContext:
privileged: true
containers:
- name: elasticsearch
image: docker.elastic.co/elasticsearch/elasticsearch-oss:6.2.4
ports:
- containerPort: 9200
name: "http-9200"
- containerPort: 9300
name: "tcp-9300"
env:
- name: cluster.name
value: elasticsearch-cluster
- name: node.name
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: ES_JAVA_OPTS
value: -Xms4g -Xmx4g
volumeMounts:
- name: data
mountPath: /usr/share/elasticsearch/data
volumeClaimTemplates:
- metadata:
name: data
annotations:
volume.beta.kubernetes.io/storage-class: "standard"
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Mein Service
apiVersion: v1
kind: Service
metadata:
name: scrappers-service
labels:
name: scrappers-service
spec:
ports:
- nodePort: 30164
name: "http-8080"
port: 8080
targetPort: 8080
selector:
app: scrappers-service
type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: scrappers-service
labels:
name: scrappers-service
spec:
selector:
matchLabels:
app: scrappers-service
replicas: 1
template:
metadata:
labels:
app: scrappers-service
spec:
containers:
- image: example/scrappers:master
imagePullPolicy: Never
name: scrappers-service
ports:
- containerPort: 8080
Antworten
Wie hier erwähnt
Ich habe mich für die von elasticsearch beschriebene Lösung entschieden. Ich meine elasticseach-operator. Ich habe alle Schritte angewendet und es funktioniert einfach ohne größere Probleme.
Die Lösung wäre also, der Dokumentation zur Elasticsearch zu folgen , die die folgenden Anmerkungen verwendet, damit sie funktioniert.
annotations:
traffic.sidecar.istio.io/excludeOutboundPorts: ""
traffic.sidecar.istio.io/excludeInboundPorts: ""
Damit der validierende Webhook unter Istio funktioniert, müssen Sie den eingehenden Port 9443 vom Proxy ausschließen. Dies kann durch Bearbeiten der Vorlagendefinition des elastischen Operators StatefulSet erfolgen, um dem Operator Pod die folgenden Anmerkungen hinzuzufügen:
[...]
spec:
template:
metadata:
annotations:
traffic.sidecar.istio.io/excludeInboundPorts: "9443"
traffic.sidecar.istio.io/includeInboundPorts: '*'
[...]
Wenn Sie Istio im zulässigen Modus konfiguriert haben, funktionieren an anderer Stelle in der ECK-Dokumentation definierte Beispiele weiterhin, ohne dass Änderungen erforderlich sind. Wenn Sie jedoch die strikte gegenseitige TLS- Authentifizierung zwischen Diensten entweder über eine globale Konfiguration (MeshPolicy) oder eine Konfiguration auf Namespace-Ebene (Richtlinie) aktiviert haben, sind die folgenden Änderungen an den Ressourcenmanifesten für den korrekten Betrieb erforderlich.
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: elastic-istio
spec:
version: 7.10.0
http:
tls:
selfSignedCertificate:
disabled: true
nodeSets:
- name: default
count: 3
podTemplate:
metadata:
annotations:
traffic.sidecar.istio.io/includeInboundPorts: "*"
traffic.sidecar.istio.io/excludeOutboundPorts: "9300"
traffic.sidecar.istio.io/excludeInboundPorts: "9300"
spec:
automountServiceAccountToken: true
Wenn Sie kein automatisches gegenseitiges TLS aktiviert haben, müssen Sie möglicherweise eine Zielregel erstellen, damit der Bediener mit dem Elasticsearch-Cluster kommunizieren kann. Ein Kommunikationsproblem zwischen dem Bediener und dem verwalteten Elasticsearch-Cluster kann anhand der Bedienerprotokolle erkannt werden, um festzustellen, ob Fehler mit dem Text 503 Service Nicht verfügbar gemeldet wurden.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: elastic-istio
spec:
host: "elastic-istio-es-http.default.svc.cluster.local"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
Es gibt verwandte Github-Probleme:
- https://github.com/istio/istio/issues/14662
- https://github.com/elastic/cloud-on-k8s/issues/2770