Различия
Показаны различия между двумя версиями страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
| network:kubernetes [2024/08/23 09:50] – mirocow | network:kubernetes [2025/08/19 12:19] (текущий) – 192.168.1.159 | ||
|---|---|---|---|
| Строка 3: | Строка 3: | ||
| ====== Kubernetes ====== | ====== Kubernetes ====== | ||
| - | ===== Устанока | + | ===== k3s ===== |
| - | * [[:system:minikube]] | + | {{ :network:how-it-works-k3s-revised.svg? |
| - | ===== Сервисы | + | ===== k8s ===== |
| - | Сервис в Kubernetes — это высокоуровневая абстракция, | + | {{ : |
| + | ===== Устанока | ||
| - | Важно упомянуть, | + | * [[: |
| + | * [[: | ||
| + | * [[: | ||
| + | * [[system: | ||
| - | Каждый сервис имеет уникальное имя и может быть сконфигурирован для работы в разных режимах доступа. Например, | + | ===== Компоненты |
| - | * ClusterIP: самый простой тип сервиса, | + | * [[:system:kubernetes:services]] |
| - | * NodePort: доступен снаружи кластера по определённому порту на всех нодах. | + | |
| - | * LoadBalancer: автоматически создаёт внешний балансировщик нагрузки. | + | |
| - | * ExternalName: | + | |
| - | ==== ClusterIP | + | ===== Проекты ===== |
| - | ClusterIP — это дефолтный тип сервиса в кубах, он поднимает вам сервис внутри кластера на внутрекластеровом IP. Доступа для внешнего трафика нет, только внутри кластера. | + | |
| - | + | ||
| - | YAML для ClusterIP выглядит как-то так: | + | |
| - | + | ||
| - | {{: | + | |
| - | + | ||
| - | <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> | + | |
| - | $ kubectl proxy --port=8080 | + | |
| - | </ | + | |
| - | + | ||
| - | Когда использовать ClusterIP для открытия внешнего доступа? | + | |
| - | Есть парочка вариантов применения, | + | |
| - | + | ||
| - | | + | |
| - | * Когда надо получить доступ к какому-либо сервису | + | |
| - | + | ||
| - | ==== NodePort ==== | + | |
| - | + | ||
| - | NodePort — наиболее простой и “тупой” способ пустить внешний трафик на сервис. Название “NodePort” говорит само за себя — просто открывается порт на ноде для доступа извне, а трафик уже маршрутизируется на сам сервис. | + | |
| - | + | ||
| - | {{: | + | |
| - | + | ||
| - | <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 | + | |
| - | </ | + | |
| - | + | ||
| - | Как можно было заметить, | + | |
| - | + | ||
| - | Когда использовать NodePort? | + | |
| - | Для начала, | + | |
| - | + | ||
| - | * Один порт — один сервис | + | |
| - | * Диапазон 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: bar | + | |
| - | servicePort: 8080 | + | |
| - | </ | + | |
| ===== Авторизация ===== | ===== Авторизация ===== | ||
| Строка 142: | Строка 33: | ||
| ===== Компоненты ===== | ===== Компоненты ===== | ||
| - | * etcd | + | ^ Компоненты |
| - | | + | | etcd | Распределенное надежное хранилище ключей и значений для наиболее важных данных распределенной системы |
| - | * kubeadm | + | | kubelet\\ kubeadm\\ kube-apiserver\\ kube-controller-manager\\ kube-proxy\\ kube-scheduler\\ kubectl |
| - | * kubelet | + | | [[https:// |
| - | * kube-apiserver | + | | [[https:// |
| - | * kube-controller-manager | + | |
| - | * kube-proxy | + | |
| - | * kube-scheduler | + | |
| - | | + | |
| Строка 162: | Строка 50: | ||
| * https:// | * https:// | ||
| * https:// | * https:// | ||
| + | |||
| + | ===== Видео уроки ===== | ||
| + | |||
| + | * [[https:// | ||
| ===== Ссылки ===== | ===== Ссылки ===== | ||
| {{topic> | {{topic> | ||