Различия
Показаны различия между двумя версиями страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
system:minikube [2024/08/22 22:59] – mirocow | system:minikube [2024/08/26 21:00] (текущий) – mirocow | ||
---|---|---|---|
Строка 2: | Строка 2: | ||
====== Minikube ====== | ====== Minikube ====== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | * kind — это инструмент для запуска локальных кластеров Kubernetes с использованием «узлов» контейнера Docker. kind был в первую очередь разработан для тестирования самого Kubernetes, но может использоваться для локальной разработки или непрерывной интеграции. | ||
+ | * kubectl | ||
+ | * helm | ||
+ | |||
+ | ===== Установка и настройка ===== | ||
+ | |||
<code bash> | <code bash> | ||
$ curl -LO https:// | $ curl -LO https:// | ||
- | $ minikube start | + | $ minikube start --vm-driver=docker |
$ curl -LO " | $ curl -LO " | ||
$ curl -LO https:// | $ curl -LO https:// | ||
Строка 27: | Строка 36: | ||
</ | </ | ||
- | ====== Сервисы ====== | + | ===== Запуск панели (dashboard) |
- | ===== ClusterIP ===== | + | <code bash> |
+ | $ minikube dashboard | ||
+ | </ | ||
- | ClusterIP — это дефолтный тип сервиса в кубах, он поднимает вам сервис внутри кластера на внутрекластеровом IP. Доступа для внешнего | + | ===== Создание деплоймента |
- | YAML для ClusterIP выглядит как-то так: | + | <code bash> |
+ | $ kubectl create deployment hello-node --image=registry.k8s.io/ | ||
+ | $ kubectl get deployments | ||
+ | $ kubectl get events | ||
+ | $ kubectl config view | ||
+ | </ | ||
- | {{: | + | ===== Создание сервиса ===== |
- | + | ||
- | <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 bash> | <code bash> | ||
- | $ kubectl | + | $ kubectl |
+ | $ kubectl get services | ||
+ | $ minikube service hello-node | ||
</ | </ | ||
- | Когда использовать ClusterIP для открытия внешнего доступа? | + | ===== Очистка |
- | Есть парочка вариантов применения, | + | |
- | * Когда надо дебажить сервисы, | + | < |
- | * Когда надо получить доступ к какому-либо сервису | + | $ kubectl delete |
- | + | $ kubectl delete deployment hello-node | |
- | ===== NodePort ===== | + | $ minikube stop |
- | + | $ minikube delete | |
- | NodePort — наиболее простой и “тупой” способ пустить внешний трафик на сервис. Название “NodePort” говорит само за себя — просто открывается порт на ноде для доступа извне, а трафик уже маршрутизируется на сам сервис. | + | |
- | + | ||
- | {{: | + | |
- | + | ||
- | < | + | |
- | apiVersion: v1 | + | |
- | kind: Service | + | |
- | metadata: | + | |
- | name: my-nodeport-service | + | |
- | spec: | + | |
- | selector: | + | |
- | app: my-app | + | |
- | type: NodePort | + | |
- | ports: | + | |
- | | + | |
- | port: 80 | + | |
- | targetPort: 80 | + | |
- | | + | |
- | | + | |
</ | </ | ||
- | Как можно было заметить, | + | ===== Ссылки |
- | Когда использовать NodePort? | + | {{topic> |
- | Для начала, | + | |
- | + | ||
- | * Один порт — один сервис | + | |
- | * Диапазон 30000-32767 (хоть и изменяемый, | + | |
- | * Если IP ноды может измениться (например, | + | |
- | + | ||
- | В общем, не рекомендую использовать этот метод в продакшне. Конечно, | + | |
- | + | ||
- | ===== LoadBalancer ===== | + | |
- | + | ||
- | LoadBalancer — это, можно сказать, | + | |
- | + | ||
- | {{: | + | |
- | + | ||
- | Когда использовать LoadBalancer? | + | |
- | + | ||
- | * Элемент ненумерованного списка | + | |
- | * Если надо дать прямой доступ к сервису извне, это ваш выбор. Весь трафик на выбранный порт будет маршрутизироваться на сервис. Это значит, | + | |
- | + | ||
- | Огромный минус в том, что для каждого сервиса будет использоваться свой LoadBalancer со своим внешним IP, и придётся в результате платить сразу за несколько LoadBalancer’ов. | + | |
- | + | ||
- | ===== Ingress ===== | + | |
- | + | ||
- | В отличие от других приведённых выше примеров Ingress — вообще не сервис как таковой. Его нельзя задать как type в описании сервиса. На деле Ingress поднимается между сервисами и внешним миром и выступает в роли некоего умного маршрутизатора, | + | |
- | + | ||
- | С Ingress’ом можно делать очень много разных штук, т.к. существует множество Ingress Controller’ов с разными возможностями. Например, | + | |
- | + | ||
- | {{: | + | |
- | + | ||
- | <code yaml> | + | |
- | apiVersion: extensions/ | + | |
- | kind: Ingress | + | |
- | metadata: | + | |
- | name: my-ingress | + | |
- | spec: | + | |
- | backend: | + | |
- | serviceName: | + | |
- | servicePort: | + | |
- | rules: | + | |
- | - host: foo.mydomain.com | + | |
- | http: | + | |
- | paths: | + | |
- | - backend: | + | |
- | serviceName: | + | |
- | servicePort: | + | |
- | - host: mydomain.com | + | |
- | http: | + | |
- | paths: | + | |
- | - path: /bar/* | + | |
- | backend: | + | |
- | serviceName: | + | |
- | servicePort: | + | |
- | </ | + |