Erreur 503 UH sur Kubernetes avec Istio, mais le service fonctionne
J'ai un problème avec la bonne configuration de la communication entre mes services sur Kubernetes (minikube) avec Istio installé.
J'essaie d'envoyer une POST
demande de mon service à elasticsearch, mais je reçois tout le temps:
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
ne montre aucun problème. J'ai également désactivé mtls.
Avez-vous une idée de ce qui pourrait ne pas aller? Je ne comprends pas pourquoi il y a UH (malsain), car elasticsearch fonctionne et le tableau de bord Kiali l'affiche également comme sain.
Mes déploiements + services:
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
Mon 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
Réponses
Comme mentionné ici
J'ai décidé d'utiliser la solution décrite par elasticsearch. Je veux dire elasticseach-opérateur. J'ai appliqué toutes les étapes et cela fonctionne sans problème.
La solution serait donc de suivre la documentation elasticsearch , qui utilise les annotations ci-dessous pour le faire fonctionner.
annotations:
traffic.sidecar.istio.io/excludeOutboundPorts: ""
traffic.sidecar.istio.io/excludeInboundPorts: ""
Pour que le webhook de validation fonctionne sous Istio, vous devez exclure le port entrant 9443 du proxy. Cela peut être fait en modifiant la définition de modèle de l'opérateur élastique StatefulSet pour ajouter les annotations suivantes à l'opérateur Pod:
[...]
spec:
template:
metadata:
annotations:
traffic.sidecar.istio.io/excludeInboundPorts: "9443"
traffic.sidecar.istio.io/includeInboundPorts: '*'
[...]
Si vous avez configuré Istio en mode permissif , les exemples définis ailleurs dans la documentation ECK continueront de fonctionner sans nécessiter de modifications. Cependant, si vous avez activé l' authentification TLS mutuelle stricte entre les services via une configuration globale (MeshPolicy) ou au niveau de l'espace de noms (Policy), les modifications suivantes des manifestes de ressources sont nécessaires pour un fonctionnement correct.
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
Si vous n'avez pas activé le TLS mutuel automatique , vous devrez peut-être créer une règle de destination pour permettre à l'opérateur de communiquer avec le cluster Elasticsearch. Un problème de communication entre l'opérateur et le cluster Elasticsearch géré peut être détecté en consultant les journaux de l'opérateur pour voir s'il y a des erreurs signalées avec le texte 503 Service indisponible.
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
Il y a des problèmes liés à Github:
- https://github.com/istio/istio/issues/14662
- https://github.com/elastic/cloud-on-k8s/issues/2770