J'ai un cluster kubernetes déployé avec rke witch est composé de 3 nœuds dans 3 serveurs différents et dans ces serveurs, il y a 1 pod qui exécute yatsukino / healthereum qui est une modification personnelle de ethereum / client-go: stable. Le problème est que je ne comprends pas comment ajouter une adresse IP externe pour envoyer une requête aux pods qui sont
Mes pods pourraient être dans 3 états:
Je ne veux pas que mon équilibreur de charge transfère les requêtes vers les 2 premiers états, seul le troisième point considère mon pod comme à jour.
J'ai effectué une recherche dans le kubernetes doc mais (peut-être parce que je ne comprends pas bien) je ne trouve que l'équilibrage de charge pour les pods à l'intérieur d'un nœud unique.
Voici mon fichier de déploiement:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: goerli
name: goerli-deploy
spec:
replicas: 3
selector:
matchLabels:
app: goerli
template:
metadata:
labels:
app: goerli
spec:
containers:
- image: yatsukino/healthereum
name: goerli-geth
args: ["--goerli", "--datadir", "/app", "--ipcpath", "/root/.ethereum/geth.ipc"]
env:
- name: LASTBLOCK
value: "0"
- name: FAILCOUNTER
value: "0"
ports:
- containerPort: 30303
name: geth
- containerPort: 8545
name: console
livenessProbe:
exec:
command:
- /bin/sh
- /app/health.sh
initialDelaySeconds: 20
periodSeconds: 60
volumeMounts:
- name: app
mountPath: /app
initContainers:
- name: healthcheck
image: ethereum/client-go:stable
command: ["/bin/sh", "-c", "wget -O /app/health.sh http://my-bash-script && chmod 544 /app/health.sh"]
volumeMounts:
- name: app
mountPath: "/app"
restartPolicy: Always
volumes:
- name: app
hostPath:
path: /app/
3 Réponses :
Pour équilibrer la charge et exposer vos pods, vous pouvez utiliser https: // kubernetes. io / docs / concepts / services-networking / service /
et pour vérifier quand un pod est prêt, vous pouvez modifier vos sondes de vivacité et de préparation comme expliqué https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
pour les sondes, vous voudrez peut-être envisager des actions d'exécution comme l'exécution d'un script qui vérifie ce qui est requis et renvoie 0 ou 1 en fonction de l'état.
J'écrivais littéralement la même chose haha!
@FrankYuchengGu oui, cela arrive dans les forums ouverts :)
Pour le loadBalancing, j'ai déjà vu ces pages de doc mais je ne comprends pas comment cela fonctionne. Pourquoi le client est-il dans le nœud? Pourquoi y a-t-il toujours un proxy kube? Et où est le service?
Pour la vivacité et la disponibilité, je l'ai déjà fait. J'expliquais juste plus précisément mon idée, mais la question portait simplement sur la façon d'équilibrer la charge. Désolé pour cette confusion!
l'équilibrage de charge est implémenté avec les services in.
Les réponses ci-dessus expliquent les concepts, mais sur vos questions sur les services et l'adresse IP externe; vous devez déclarer le service, par exemple;
ip route add 222.0.0.30/32 \ nexthop via 192.168.0.1 \ nexthop via 192.168.0.2 \ nexthop via 192.168.0.3
Le type: LoadBalancer attribuera une adresse externe pour dans le cloud public ou si vous utilisez quelque chose comme metallb . Vérifiez votre adresse avec kubectl get svc goerli . Si l'adresse externe est "en attente", vous avez un problème ...
S'il s'agit de votre propre configuration, vous pouvez utiliser externalIPs pour attribuer votre propre adresse IP externe;
apiVersion: v1
kind: Service
metadata:
name: goerli
spec:
selector:
app: goerli
ports:
- port: 8545
externalIPs:
- 222.0.0.30
Les externalIPs peuvent être utilisés depuis l'extérieur du cluster mais vous devez acheminer le trafic vers n'importe quel nœud vous-même, par exemple; p >
apiVersion: v1
kind: Service
metadata:
name: goerli
spec:
selector:
app: goerli
ports:
- port: 8545
type: LoadBalancer
En supposant que vos nœuds k8s aient l'ip 192.168.0.x. Cela configurera les routes ECMP vers vos nœuds. Lorsque vous faites une demande depuis l'extérieur du cluster vers 222.0.0.30:8545, les k8s équilibreront la charge entre vos POD prêts .
Merci ! J'apprécie la réponse claire. Dans le premier cas, il semble que j'ai un problème ... Le statut est en attente. J'ai essayé la deuxième manière alors et l'IP externe mais il est impossible pour moi de cingler l'IP externe ... Des idées? Peut-être à cause de rke?
Vous ne pouvez jamais envoyer une requête ping à un service (externe ou interne) dans k8 car l'écho ICMP n'est pas transmis. Cependant, la connexion TCP fonctionne de toute façon.
Lorsqu'un conteneur est démarré, Kubernetes peut être configuré pour attendre un le temps écoulé avant d'effectuer le premier contrôle de l'état de préparation. Après cela, il appelle la sonde périodiquement et agit en fonction du résultat de la sonde de disponibilité. Si un le pod signale qu'il n'est pas prêt, il a été supprimé du service. Si le pod devient alors prêt à nouveau, il est de nouveau ajouté. Contrairement aux sondes de vivacité, si un conteneur échoue au contrôle de disponibilité, il ne sera pas tué ou redémarré. Il s'agit d'une distinction importante entre les sondes de vivacité et de préparation. Les sondes de vie maintiennent les gousses en bonne santé en éliminant les contenants malsains et en les remplaçant les avec de nouveaux, sains, tandis que les sondes de préparation s'assurent que seules les gousses qui sont prêts à répondre aux demandes de les recevoir. Ceci est surtout nécessaire pendant le conteneur démarrer, mais il est également utile après que le conteneur a fonctionné pendant un certain temps.
Je pense que vous pouvez utiliser la sonde pour votre objectif