Summary
La plupart du temps, lorsque vous configurez votre cluster Kubernetes, l’utilisation des paramètres du contrôleur d’entrée par défaut fonctionne. Mais lorsque vous devez faire quelque chose de personnalisé, vous pouvez rencontrer des problèmes. Votre docker sous-jacent et votre moteur kubernetes peuvent vous donner des têtes. Nous allons voir dans cette soluce, comment les réparer et vous redonner le sourire.
TL;DR
J’ai généré quelques hypothèses et étudié, mais je n’ai pas pu résoudre le problème au moment de la rédaction. Déposez un commentaire ci-dessous si vous avez la solution.
La mise en place
J’ai un cluster Azure Kubernetes Service. J’ai une machine virtuelle en dehors du cluster et elle provient d’un réseau virtuel différent, à partir duquel j’essaie de me connecter à mon conteneur Pod App qui est exécuté sur le port TCP 9000.
graph TD
subgraph F[Virtual Network 1]
subgraph D[Cluster Kubernetes]
direction LR
E[App container, pod, port 9000]
end
end
subgraph G[Virtual network 2]
A[VM]
end
A --use TCP connection and not http--> E
Mon but
Je ne dois pas utiliser l’adresse IP publique et ce n’est pas une connexion HTTP, mais je dois me connecter à l’aide de la connexion TCP.
Pour cela, j’ai suivi les instructions de ce lien : https://docs.microsoft.com/en-us/azure/aks/ingress-internal-ip
## Étape 1 : Créez le fichier yaml pour l’installation de la barre
Mon fichier ressemblait à ceci :
controller:
service:
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
Etape 2 : Configurer nginx
J’ai configuré le nginx pour qu’il fonctionne sur les ports 80 et 443.
helm install nginx-ingress ingress-nginx/ingress-nginx \
-f internal-ingress.yaml \
--set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \
--set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux \
--set controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\.io/os"=linux
Une vérification rapide de l’état du service donne les informations suivantes :
kubectl get services -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
nginx-ingress-ingress-ngingx controller LoadBalancer 10.0.36.81 10.33.27.35 80:31312/TCP,443:30653/TCP
Étape 3 : Exécutez la mise à niveau de helm
Exécutez la commande de mise à niveau pour vous assurer que les ports sont en service (configurés).
helm upgrade nginx-ingress ingress-nginx/ingress-nginx -f internal-ingress.yaml --set tcp.9000="default/frontarena-ads-aks-test:9000"
Ensuite, jetez un oeil à la config map
kubectl get configmaps
Il vous donne cette sortie :
apiVersion: v1
data:
"9000": default/frontarena-ads-aks-test:9000
kind: ConfigMap
Étape 4 : Modifier le service nginx
Modifiez votre service nginx pour qu’il corresponde à cela.
spec:
clusterIP: 10.0.36.81
externalTrafficPolicy: Cluster
ports:
- name: http
nodePort: 31312
port: 80
protocol: TCP
targetPort: http
- name: https
nodePort: 30653
port: 443
protocol: TCP
targetPort: https
- name: 9000-tcp
nodePort: 30758
port: 9000
protocol: TCP
targetPort: 9000
## Étape 5 : Déployez votre pod d’application et vérifiez le résultat
J’ai ensuite déployé mon pod et voilà le résultat.
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontarena-ads-deployment
labels:
app: frontarena-ads-deployment
spec:
replicas: 1
template:
metadata:
name: frontarena-ads-aks-test
labels:
app: frontarena-ads-aks-test
spec:
nodeSelector:
"beta.kubernetes.io/os": linux
restartPolicy: Always
containers:
- name: frontarena-ads-aks-test
image: fa.dev/:test1
ports:
- containerPort: 9000
selector:
matchLabels:
app: frontarena-ads-aks-test
---
apiVersion: v1
kind: Service
metadata:
name: frontarena-ads-aks-test
spec:
type: ClusterIP
ports:
- protocol: TCP
port: 9000
selector:
app: frontarena-ads-aks-test
Étape 6 : Configurez et déployez votre contrôleur d’entrée
N’oubliez pas de le déployer dans le même espace de noms par défaut que le service ci-dessus que nous avons configuré précédemment.
Mon hypothèse est qu’il se connectera via le ClusterIP.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ads-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- http:
paths:
- path:
backend:
serviceName: frontarena-ads-aks-test
servicePort: 9000
Le problème
Passons maintenant au problème.
Si j’essaie de cibler à partir de mon application VM déployée en dehors du cluster AKS, je n’obtiens aucune réponse. N’oubliez pas que la machine virtuelle se trouve dans un autre réseau virtuel avec le contrôleur d’entrée.
Mes hypothèses :
- le contrôleur d’entrée ne transmet pas la demande au pod d’application.
- J’ai configuré un passthrough dans le service et le ConfigMap. Je pense que je n’ai probablement pas besoin du contrôleur d’entrée.
- Je vais essayer d’accéder au contrôleur d’entrée depuis le même réseau virtuel pour vérifier si le problème est à l’intérieur ou à l’extérieur.
Conclusion
Je n’ai pas trouvé de solution à mon problème mais j’espère que mes investigations et seup vous aideront à trouver la solution au vôtre.
Si cela se produit, veuillez laisser un commentaire pour les personnes qui liront ce message après vous.
![Comment créer un nouvel utilisateur compatible Sudo sur Ubuntu 20.04 [Quickstart]](https://res.cloudinary.com/brightsoftwares/image/upload/t_BSBlogImage/f_auto/q_auto/dpr_auto/v1656243722/pexels-franklin-david-10670164_uqf4i1.jpg)
