Различия

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

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

Предыдущая версия справа и слева Предыдущая версия
Следующая версия		 Предыдущая версия
system:minikube [2024/08/22 22:59] – 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) =====
  
-===== ClusterIP =====+<code bash> 
 +$ minikube dashboard 
 +</code>
  
-ClusterIP — это дефолтный тип сервиса в кубах, он поднимает вам сервис внутри кластера на внутрекластеровом IP. Доступа для внешнего трафика нет, только внутри кластера.+===== Создание деплоймента =====
  
-YAML для ClusterIP выглядит как-то так: +<code bash> 
- +$ kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080 
-{{:system:image-4.png?600|}} +$ kubectl get deployments 
- +$ kubectl get events 
-<code yaml> +$ kubectl config view
-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>
 +
 +===== Создание сервиса =====
  
 <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? +
-Для начала, у этого метода сразу несколько минусов: +
- +
-  * Один порт — один сервис +
-  * Диапазон 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|}} +
  
 +{{topic>[kubernetes]}}