Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия		 Предыдущая версия
system:minikube [2024/08/22 23:02] – [Сервисы] mirocowsystem:minikube [2024/08/26 21:00] (текущий) – mirocow
Строка 2: Строка 2:
  
 ====== Minikube ====== ====== Minikube ======
 +
 +{{ :system:module_04_labels.svg?600 |}}
 +
 +  * kind — это инструмент для запуска локальных кластеров Kubernetes с использованием «узлов» контейнера Docker. kind был в первую очередь разработан для тестирования самого Kubernetes, но может использоваться для локальной разработки или непрерывной интеграции.
 +  * kubectl
 +  * helm
 +
 +===== Установка и настройка =====
 +
  
 <code bash> <code bash>
 $ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 $ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
-$ minikube start+$ minikube start --vm-driver=docker
 $ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" $ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
 $ curl -LO https://dl.k8s.io/release/v1.31.0/bin/linux/amd64/kubectl $ curl -LO https://dl.k8s.io/release/v1.31.0/bin/linux/amd64/kubectl
Строка 27: Строка 36:
 </code> </code>
  
-====== Сервисы ======+===== Запуск панели (dashboard) =====
  
-Сервис в Kubernetes — это высокоуровневая абстракция, предназначенная для обеспечения доступа к одному или нескольким подам, работающим в кластере. Сервисы упрощают процесс взаимодействия между различными компонентами приложения и предоставляют удобный интерфейс для доступа к ресурсам. Проще говоря, сервис в Kubernetes выступает в роли стабильной сетевой точки входа для приложений, которые работают в кластере.+<code bash> 
 +$ minikube dashboard 
 +</code>
  
-Важно упомянуть, что сервисы используют селекторы для идентификации подов, которые должны быть частью данного сервиса. Селекторы позволяют группировать поды по определённым критериям, таким, как метки или имена.+===== Создание деплоймента =====
  
-Каждый сервис имеет уникальное имя и может быть сконфигурирован для работы в разных режимах доступа. Например, service может быть настроен на внутренний доступ только внутри кластера или он может быть настроен на внешний доступ через внешний балансировщик нагрузки. В связи с такой вариативностью сервисы разделили на несколько типов:+<code bash> 
 +$ kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080 
 +$ kubectl get deployments 
 +$ kubectl get events 
 +$ kubectl config view 
 +</code>
  
-  * ClusterIP: самый простой тип сервиса, доступный только внутри кластера. +===== Создание сервиса =====
-  * NodePort: доступен снаружи кластера по определённому порту на всех нодах. +
-  * LoadBalancer: автоматически создаёт внешний балансировщик нагрузки. +
-  * ExternalName: маппинг на внешний ресурс посредством CNAME-записи. +
-===== ClusterIP ===== +
- +
-ClusterIP — это дефолтный тип сервиса в кубах, он поднимает вам сервис внутри кластера на внутрекластеровом IP. Доступа для внешнего трафика нет, только внутри кластера. +
- +
-YAML для ClusterIP выглядит как-то так: +
- +
-{{:system:image-4.png?600|}} +
- +
-<code yaml> +
-apiVersion: v1 +
-kind: Service +
-metadata:   +
-  name: my-internal-service +
-spec: +
-  selector:     +
-    app: my-app +
-  type: ClusterIP +
-  ports:   +
-  - name: http +
-    port: 80 +
-    targetPort: 80 +
-    protocol: TCP +
-</code>+
  
 <code bash> <code bash>
-$ kubectl proxy --port=8080+$ kubectl expose deployment hello-node --type=LoadBalancer --port=8080 
 +$ kubectl get services 
 +$ minikube service hello-node
 </code> </code>
  
-Когда использовать ClusterIP для открытия внешнего доступа? +===== Очистка =====
-Есть парочка вариантов применения, когда стоит пускать трафик на сервис через kubernetes proxy:+
  
-  * Когда надо дебажить сервисы, подключаясь к ним напрямую +<code bash> 
-  * Когда надо получить доступ к какому-либо сервису +$ kubectl delete service hello-node 
- +$ kubectl delete deployment hello-node 
-===== NodePort ===== +$ minikube stop 
- +$ minikube delete
-NodePort — наиболее простой и “тупой” способ пустить внешний трафик на сервис. Название “NodePort” говорит само за себя — просто открывается порт на ноде для доступа извне, а трафик уже маршрутизируется на сам сервис. +
- +
-{{:system:image-5.png?600|}} +
- +
-<code yaml> +
-apiVersion: v1 +
-kind: Service +
-metadata:   +
-  name: my-nodeport-service +
-spec: +
-  selector:     +
-    app: my-app +
-  type: NodePort +
-  ports:   +
-  - name: http +
-    port: 80 +
-    targetPort: 80 +
-    nodePort: 30036 +
-    protocol: TCP+
 </code> </code>
  
-Как можно было заметить, в описании фигурирует параметр nodePort, который задаёт номер порта для открытия. Если его не задавать, то выберется рандомный порт в диапазоне 30000-32767.+===== Ссылки =====
  
-Когда использовать NodePort? +{{topic>[kubernetes]}}
-Для начала, у этого метода сразу несколько минусов: +
- +
-  * Один порт — один сервис +
-  * Диапазон 30000-32767 (хоть и изменяемый, но делать это надо крайне осторожно) +
-  * Если IP ноды может измениться (например, в GKE или AWS при автоскейлинге), то это тоже надо учитывать +
- +
-В общем, не рекомендую использовать этот метод в продакшне. Конечно, если это какой-то демо-сервис и от него не требуется 100% доступность, вполне можно использовать NodePort. +
- +
-===== LoadBalancer ===== +
- +
-LoadBalancer — это, можно сказать, стандартный и самый простой способ пустить внешний трафик на сервис. Правда, работает он только в облаках, т.к. использует нативные облачные решения текущего провайдера. Например, при использовании в GKE будет поднят Network Load Balancer с отдельным внешним IP-адресом, который будет маршрутизировать весь трафик на указанный сервис. +
- +
-{{:system:image-6.png?600|}} +
- +
-Когда использовать LoadBalancer? +
- +
-  * Элемент ненумерованного списка +
-  * Если надо дать прямой доступ к сервису извне, это ваш выбор. Весь трафик на выбранный порт будет маршрутизироваться на сервис. Это значит, что можно пускать практически любой вид трафика: HTTP, TCP, UDP, Websockets, gRPC и т.п. +
- +
-Огромный минус в том, что для каждого сервиса будет использоваться свой LoadBalancer со своим внешним IP, и придётся в результате платить сразу за несколько LoadBalancer’ов. +
- +
-===== Ingress ===== +
- +
-В отличие от других приведённых выше примеров Ingress — вообще не сервис как таковой. Его нельзя задать как type в описании сервиса. На деле Ingress поднимается между сервисами и внешним миром и выступает в роли некоего умного маршрутизатора, который является точкой входа в кластер. +
- +
-С Ingress’ом можно делать очень много разных штук, т.к. существует множество Ingress Controller’ов с разными возможностями. Например, в GKE дефолтный Ingress Controller поднимет HTTP(S) Load Balancer. Он позволяет роутить трафик на сервисы по путям URL’ов и поддоменам. Например, можно отправить всё, что приходит на foo.yourdomain.com на сервис foo, а всё, что приходит на yourdomain.com/bar/ на сервис bar +
- +
-{{:system:image-7.png?600|}} +
- +
-<code yaml> +
-apiVersion: extensions/v1beta1 +
-kind: Ingress +
-metadata: +
-  name: my-ingress +
-spec: +
-  backend: +
-    serviceName: other +
-    servicePort: 8080 +
-  rules: +
-  - host: foo.mydomain.com +
-    http: +
-      paths: +
-      - backend: +
-          serviceName: foo +
-          servicePort: 8080 +
-  - host: mydomain.com +
-    http: +
-      paths: +
-      - path: /bar/* +
-        backend: +
-          serviceName: bar +
-          servicePort: 8080 +
-</code>+