Loadbalancer IP и статус входящего IP ожидают в kubernetes - PullRequest
Новая
       7

Loadbalancer IP и статус входящего IP ожидают в kubernetes

0 голосов
/ 15 января 2020

Я создал кластер Kubernetes с использованием двух Azure виртуальных машин Ubuntu. Я могу развертывать и получать доступ к модулям и развертываниям, используя тип службы Nodeport. Я также проверил статус модуля в Kube-system пространстве имен. Весь статус модуля отображается как running. но всякий раз, когда я упоминаю тип сервиса в Loadbalancer, он не создает IP-адрес LoadBalancer, и его статус всегда отображается как pending. Я также создал контроллер Ingress для службы Nginx. тем не менее, он не создает входной адрес. При инициализации мастера Kubernetes я использую следующую команду:

kubeadm init

Ниже приведены файлы развертывания, sv c и Ingress manifest.

apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80

apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - name: http port: 80 protocol: TCP targetPort: 80 selector: app: nginx

kubectl describe svc nginx

Name: nginx Namespace: default Labels: app=nginx Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx","namespace":"default"},"spec":{"p... Selector: app=nginx Type: ClusterIP IP: 10.96.107.97 Port: http 80/TCP TargetPort: 80/TCP Endpoints: 10.44.0.4:80,10.44.0.5:80,10.44.0.6:80 Session Affinity: None Events: <none>

apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: test-ingress spec: backend: serviceName: nginx servicePort: 80

kubectl describe ingress nginx

Имя: вход-тест

Пространство имен: по умолчанию

Адрес:

Бэкэнд по умолчанию: nginx: 80 (10.44.0.4:80,10.44.0.5 : 80,10.44.0.6: 80)

Правила:

Бэкэнды пути к хосту

* * nginx: 80 (10.44.0.4 : 80,10.44.0.5: 80,10.44.0.6: 80)

Аннотации: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion": "network.k8s.io/v1beta1", "добрая": "Ingress", "метаданные": { "Аннотация": {}, "имя": "тест-Ingress", "пространство имена": "по умолчанию"}, "сп c": { "бэкенд" : {"serviceName": "nginx", "servicePort": 80}}}

События: <none>

Нужно ли упоминать какие-либо диапазоны IP (частные или publi c) виртуальных машин при инициализации kubead м init? или нам нужно изменить какие-либо сетевые настройки в Azure виртуальных машинах Ubuntu?

1 Ответ

1 голос
/ 16 января 2020

Поскольку вы создали собственный кластер Kubernetes, а не AWS, Azure или GCP, ни один из них, встроенный балансировщик нагрузки отсутствует. По этой причине вы получаете ожидающий статус IP.

Но с помощью Ingress Controller или напрямую через NodePort вы можете обойти эту проблему.

Однако я также заметил, что в вашем nginx service вы используете аннотацию service.beta.kubernetes.io/aws-load-balancer-type: nlb, и вы сказали, что используете Azure, и это аннотации платформы c для службы, и эта аннотация AWS Speci c.

Однако вы можете попробовать что-то подобное, если вы хотите поэкспериментировать непосредственно с IPL c, вы можете определить свою службу, предоставив externalIPs в вашем сервисе, если у вас есть узлы publi c ip, выделенные вашему узлу и позволяющие откуда-то входить traffi c. 

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

Но хороший подход для этого - использование ingress controller, если вы планируете построить свой собственный кластер Kubernetes.

Надеюсь, это поможет.

...