сервіс kubernetes зовнішній ip в очікуванні

Я намагаюся розгорнути nginx на kubernetes, версія kubernetes v1.5.2, я розгорнув nginx з 3-ма репліками, файл YAML знаходиться нижче,

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deployment-example
spec:
  replicas: 3
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

і тепер я хочу виставити його порт 80 на порт 30062 вузла, для цього я створив службу нижче,

kind: Service
apiVersion: v1
metadata:
  name: nginx-ils-service
spec:
  ports:
    - name: http
      port: 80
      nodePort: 30062
  selector:
    app: nginx
  type: LoadBalancer

ця послуга працює добре, як і належить, але вона демонструється як очікує не тільки на інформаційній панелі kubernetes, але і на терміналі.

тож допоможіть мені вирішити цю проблему. Дякую ...

Схоже , що ви використовуєте для користувача Kubernetes кластера (використовуючи minikube, kubeadmчи щось таке). У цьому випадку немає інтегрованого LoadBalancer (на відміну від AWS або Google Cloud). За допомогою цього налаштування за замовчуванням можна використовувати лише NodePortконтролер Ingress.

За допомогою контролера Ingress ви можете встановити доменне ім’я, яке відображається у вашому стручку; вам не потрібно надавати своєму сервісу LoadBalancerтип, якщо ви використовуєте контролер Ingress.

Якщо ви використовуєте Minikube, є магічна команда!

$ minikube tunnel

Сподіваємось, хтось може заощадити на цьому кілька хвилин.

Посилання на посилання https://minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel

Якщо ви не використовуєте GCE або EKS (ви використовували kubeadm), ви можете додати externalIPsспецифікацію до своєї послуги YAML. Ви можете використовувати IP, пов'язаний з основним інтерфейсом вашого вузла, наприклад eth0. Потім ви можете отримати доступ до послуги зовнішньо, використовуючи зовнішній IP вузол.

...
spec:
  type: LoadBalancer
  externalIPs:
  - 192.168.0.10

Щоб отримати доступ до служби minikube, потрібно виконати таку команду:

minikube service [-n NAMESPACE] [--url] NAME

Більше інформації тут: Minikube GitHub

Я створив кластер кластерів одного вузла, використовуючи kubeadm. Коли я спробував проксі PortForward та kubectl , він показав зовнішній IP як очікуваний.

$ kubectl get svc -n argocd argocd-server
NAME            TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
argocd-server   LoadBalancer   10.107.37.153   <pending>     80:30047/TCP,443:31307/TCP   110s

У моєму випадку я скопіював такий сервіс:

kubectl patch svc <svc-name> -n <namespace> -p '{"spec": {"type": "LoadBalancer", "externalIPs":["172.31.71.218"]}}'

Після цього він розпочав службу через публічну ІС

$ kubectl get svc argo-ui -n argo
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
argo-ui   LoadBalancer   10.103.219.8   172.31.71.218   80:30981/TCP   7m50s

Якщо ви працюєте на minikube , не забудьте згадати простір імен, якщо ви не використовуєте за замовчуванням.

сервіс minikube << службове ім'я >> --url - namespace = << простір імен_ім'я >>

Якщо ви використовуєте minikube, тоді запускайте команди нижче від терміналу,

$ minikube ip
$ 172.17.0.2 // then 
$ curl http://172.17.0.2:31245
or simply
$ curl http://$(minikube ip):31245

те саме питання:

os> kubectl отримати svc право-sabertooth-wordpress

НАЗВАННЯ ТИП CLUSTER-IP
ВНУТРІШНІЙ- ІРТ ПОРТ

os> список послуг minikube

| ------------- | ---------------------------- | ------ -------------------------- |

| ІМЕНА! ІМ’Я | URL |

| ------------- | ---------------------------- | ------ -------------------------- |

| за замовчуванням | кубернети | Немає порту вузла |

| за замовчуванням | право-саберто-маріадб | Немає порту вузла |

| за замовчуванням | право-саберто-слово-слово | http://192.168.99.100:30454 |

| | | http://192.168.99.100:30427 |

| кубе-система | кубе-днс | Немає порту вузла |

| кубе-система | тиллер-розгортання | Немає порту вузла |

| ------------- | ---------------------------- | ------ -------------------------- |

Однак це доступно за допомогою http://192.168.99.100:30454 .

Після відповіді @ Хав'єра. Я вирішив перейти на "виправлення зовнішнього IP" для мого балансира навантаження.

 $ kubectl patch service my-loadbalancer-service-name \
-n lb-service-namespace \
-p '{"spec": {"type": "LoadBalancer", "externalIPs":["192.168.39.25"]}}'

Це замінить це "очікування" новою виправленою IP-адресою, яку ви можете використовувати для свого кластера.

Більше про це. Будь ласка , см Картік - х пост по підтримці LoadBalancer з Minikube для Kubernetes

Не найчистіший спосіб це зробити. Мені потрібно було тимчасове рішення. Сподіваюся, це комусь допомагає.

Використовуйте NodePort:

kubectl run user-login --replicas = 2 --labels = "run = user-login" --image = kingslayerr / teamproject: version2 --port = 5000

kubectl викриває розгортання користувача-вхід --type = NodePort --name = користувач-вхід-сервіс

kubectl описує сервіс для входу користувачів (занотуйте порт)

kubect кластерна інформація (IP-> Отримати IP, де працює майстер)

Ваша послуга доступна за адресою (IP) :( порт)

Використовуючи Minikube, ви можете отримати IP та порт, через який можна отримати доступ до служби, запустивши службу minikube kubia-http.

Якщо ви не підтримуєте хмару (aws, azure, gcloud і т. Д.), Ви не можете використовувати LoadBalancer без MetalLB https://metallb.universe.tf/, але це ще в бета-версії.

Тип сервісу LoadBalancer працюватиме лише в тому випадку, якщо базова інфраструктура підтримує автоматичне створення навантажувачів та матиме відповідну підтримку в Kubernetes, як це стосується хмарної платформи Google та AWS. Якщо така функція не налаштована, поле IP-адреси LoadBalancer не заповнюється і все ще знаходиться в стані очікування, і Сервіс буде працювати так само, як послуга типу NodePort

Ви можете зафіксувати IP-адресу вузла, де розміщуються стручки (приватний IP-код вузла), це просте вирішення.

Звертаючись до вищезгаданих постів, наступний працював для мене:

kubectl patch service my-loadbalancer-service-name \ -n lb-service-namespace \ -p '{"spec": {"type": "LoadBalancer", "externalIPs": ["xxx.xxx.xxx.xxx Private IP фізичного сервера - Вузол - де здійснюється розгортання "]}} '

видалити існуючий сервіс і створити такий же новий сервіс вирішив мої проблеми. Мої проблеми полягають у тому, що Ip I, який визначає балансування завантаження, використовується таким чином, що зовнішня кінцева точка очікує на розгляд. Коли я змінив новий IP-балансуючий навантаження, він все ще не працює. Нарешті, видалення існуючої служби та створення нового вирішили мою проблему.

Перевірте журнали кубе-контролера. Мені вдалося вирішити цю проблему, встановивши теги clusterID на екземпляр ec2, на якому я розгорнув кластер.

Якщо це ваш приватний кластер k8s, MetalLB був би кращим. Нижче наведені етапи.

Крок 1. Встановіть MetalLB у свій кластер

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
# On first install only
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

Крок 2. Налаштуйте його за допомогою конфігураційної карти

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 172.42.42.100-172.42.42.105 #Update this with your Nodes IP range 

Крок 3: Створіть свою службу, щоб отримати зовнішній IP (хоча це буде приватний IP).

КЮР:

Перед встановленням MetalLB:

Після установки MetalLB:

Додавання рішення для тих, хто зіткнувся з цією помилкою під час роботи амазон-екс.

Перш за все, запустіть:

kubectl describe svc <service-name>

А потім перегляньте eventsполе у ​​наведеному нижче прикладі:

Name:                     some-service
Namespace:                default
Labels:                   <none>
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"some-service","namespace":"default"},"spec":{"ports":[{"port":80,...
Selector:                 app=some
Type:                     LoadBalancer
IP:                       10.100.91.19
Port:                     <unset>  80/TCP
TargetPort:               5000/TCP
NodePort:                 <unset>  31022/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type     Reason                  Age        From                Message
  ----     ------                  ----       ----                -------
  Normal   EnsuringLoadBalancer    68s  service-controller  Ensuring load balancer
  Warning  SyncLoadBalancerFailed  67s  service-controller  Error syncing load balancer: failed to ensure load balancer: could not find any suitable subnets for creating the ELB

Перегляньте повідомлення про помилку:

Failed to ensure load balancer: could not find any suitable subnets for creating the ELB

У моєму випадку причиною того, що для створення ЕЛБ не було надано відповідних підмереж, були:

1: Кластер EKS був розгорнутий у неправильній групі підмереж - внутрішні підмережі замість загальнодоступних.
(*) За замовчуванням служби типу LoadBalancerстворюють загальнодоступні балансири навантажень, якщо service.beta.kubernetes.io/aws-load-balancer-internal: "true"анотація не надана).

2: Підмережі не позначені тегами відповідно до зазначених тут вимог .

Позначення VPC за допомогою:

Key: kubernetes.io/cluster/yourEKSClusterName
Value: shared

Позначення загальних підмереж:

Key: kubernetes.io/role/elb
Value: 1