Kubernetes，k8s, как сделать сервис URL?

Я учу k8s. Мой вопрос заключается в том, как разрешить k8s получить URL-адрес службы, как это делает команда minikube "minikube get service xxx --url"? Я спрашиваю, потому что, когда модуль pod выключен и снова запущен / создан / инициирован, нет необходимости изменять URL, посещая URL службы. Развертывая модуль как NodePort, я мог получить доступ к модулю с IP-адресом хоста и портом, но если он будет заново инициирован / создан, порт изменится.

Мой случай иллюстрируется ниже: у меня есть

one master(172.16.100.91) and 
one node(hostname node3, 172.16.100.96)

Я создаю pod и сервис, как показано ниже, helllocomm, развернутый как NodePort, и helloext, развернутый как ClusterIP. hellocomm и helloext являются приложениями hello world с весенней загрузкой.

docker build -t jshenmaster2/hellocomm:0.0.2 .
kubectl run hellocomm --image=jshenmaster2/hellocomm:0.0.2 --port=8080
kubectl expose deployment hellocomm --type NodePort

docker build -t jshenmaster2/helloext:0.0.1 .
kubectl run helloext --image=jshenmaster2/helloext:0.0.1 --port=8080
kubectl expose deployment helloext --type ClusterIP


[root@master2 shell]# kubectl get service -o wide
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE       SELECTOR
hellocomm    NodePort    10.108.175.143   <none>        8080:31666/TCP   8s        run=hellocomm
helloext     ClusterIP   10.102.5.44      <none>        8080/TCP         2m        run=helloext

[root@master2 hello]# kubectl get pods -o wide
NAME                         READY     STATUS    RESTARTS   AGE       IP              NODE
hellocomm-54584f59c5-7nxp4   1/1       Running   0          18m       192.168.136.2   node3
helloext-c455859cc-5zz4s     1/1       Running   0          21m       192.168.136.1   node3

Выше мой модуль развернут на узле 3(172.16.100.96), поэтому я мог получить доступ к hellocomm с помощью 172.16.100.96:31666/hello. В этом сценарии можно легко увидеть, что когда узел 3 не работает, создается и инициируется новый модуль, порт тоже меняется. так что мой клиент потерял связь. Я не хочу этого решения.

Мой текущий вопрос заключается в том, что helloext развернут как ClusteriP, и это также сервис, как показано выше. Означает ли это, что ClusterIP 10.102.5.44 и порт 8080 будут URL-адресом службы, http://10.102.5.44:8080/hello?

Нужно ли снова создавать сервис по файлу yaml? Чем отличается сервис, созданный командой от файла yaml? Как написать следующий файл yaml, если мне нужно создать сервис по yaml?

Ниже приведен шаблон определения yaml, который мне нужно заполнить. Как заполнить?

apiVersion: v1
kind: Service
matadata:
  name: string         helloext      
  namespace: string    default
  labels:              
    - name: string     helloext
  annotations:
    - name: string     hello world   
spec:
  selector: []            ?
  type: string            ?
  clusterIP: string       anything I could give?  
  sessionAffinity: string  ? (yes or no) 
  ports:
  - name: string          helloext  
    protocol: string      tcp  
    port: int             8081? (port used by host machine)
    targetPort: int       8080? (spring boot uses 8080)
    nodePort: int         ? 
  status:                 since I am not using loadBalancer in deploymennt, I could forget this.  
    loadBalancer:
      ingress:
        ip: string
        hostname: string
Источник

2 ответа

Решение

NodePort, как следует из названия, открывает порт непосредственно на узле (фактически на всех узлах кластера), чтобы вы могли получить доступ к своей службе. По умолчанию он случайный - поэтому, когда умирает стручок, он генерирует новый для вас. Однако вы также можете указать порт (3-й абзац здесь) - и вы сможете получить доступ к тому же порту даже после повторного создания модуля.

ClusterIP доступен только внутри кластера, так как это частный IP. Это означает, что в сценарии по умолчанию вы можете получить доступ к этой службе из другого контейнера / узла внутри кластера. Вы можете exec / ssh в любой работающий контейнер / узел и попробуйте.

Файлы Yaml могут контролироваться версиями, документироваться, шаблонизироваться ( Helm) и т. Д.

Проверьте https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/ для получения подробной информации о каждом поле.

РЕДАКТИРОВАТЬ: более подробную информацию об услугах здесь: https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

Источник

Как насчет создания входа и указания его службе для доступа к нему вне кластера?

Источник
Другие вопросы по тегам