У меня есть настройка кластера k8s через kops на AWS. Моей первоначальной настройкой был один узел, на котором я развернул службу и показал ее через внутренний балансировщик нагрузки AWS:
apiVersion: v1
kind: Service
metadata:
name: kube-state-metrics-2
namespace: kube-system
labels:
k8s-app: kube-state-metrics
annotations:
service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
spec:
ports:
- name: http-metrics
port: 8080
targetPort: http-metrics
protocol: TCP
- name: telemetry
port: 8081
targetPort: telemetry
protocol: TCP
selector:
k8s-app: kube-state-metrics
type: LoadBalancer
После того, как балансировщик нагрузки был создан, консоль AWS показала, что не может связаться со службой в экземпляре. Я проверил, что служба работает и доступна через IP-адрес кластера от мастера.
Столкнувшись с этой проблемой раньше, я создал новый узел. Балансировщик нагрузки теперь показывает, что он может достигать одного из двух экземпляров. То есть теперь он может достигать службы через новый IP-адрес узла. У меня все еще было два модуля, работающих на моем старом узле. Теперь я увеличил количество реплик своего сервиса на 1, и, следовательно, у меня также были запущены модули на новом узле. Теперь мой балансировщик нагрузки показывает, что он может достигать обоих экземпляров. Моя теория заключается в том, что старый узел перенаправляет трафик на модули на новых узлах, поскольку правила iptables были изменены с помощью kube-proxy для вероятностной пересылки трафика в один из двух контейнеров, работающих на разных узлах.
Что может происходить? Я посмотрел на правила IPtables, и они выглядят хорошо для меня.
FWIW, я использую amazon-vpc-cni-k8s .
Я разместил более подробную информацию здесь