Различия

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

--- network:kubernetes [2024/08/26 21:04] – [Устанока] mirocow
+++ network:kubernetes [2025/08/19 12:19] (текущий) – 192.168.1.159
@@ Строка 3: / Строка 3: @@
 ====== Kubernetes ======
+===== k3s =====
+{{ :network:how-it-works-k3s-revised.svg?600 |}}
+===== k8s =====
+{{ :network:1_ksrh4t8s1ymauhbpgq3ylw.webp?600 |}}
 ===== Устанока =====
@@ Строка 9: / Строка 16: @@
   * [[:system:helm]]
   * [[system:podman]]
+===== Компоненты =====
+  * [[:system:kubernetes:services]]
 ===== Проекты =====
   * [[:application:reana]]
-===== Сервисы =====
-Сервис в Kubernetes — это высокоуровневая абстракция, предназначенная для обеспечения доступа к одному или нескольким подам, работающим в кластере. Сервисы упрощают процесс взаимодействия между различными компонентами приложения и предоставляют удобный интерфейс для доступа к ресурсам. Проще говоря, сервис в Kubernetes выступает в роли стабильной сетевой точки входа для приложений, которые работают в кластере.
-Важно упомянуть, что сервисы используют селекторы для идентификации подов, которые должны быть частью данного сервиса. Селекторы позволяют группировать поды по определённым критериям, таким, как метки или имена.
-Каждый сервис имеет уникальное имя и может быть сконфигурирован для работы в разных режимах доступа. Например, service может быть настроен на внутренний доступ только внутри кластера или он может быть настроен на внешний доступ через внешний балансировщик нагрузки. В связи с такой вариативностью сервисы разделили на несколько типов:
-  * 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>
-$ kubectl proxy --port=8080
-</code>
-Когда использовать ClusterIP для открытия внешнего доступа?
-Есть парочка вариантов применения, когда стоит пускать трафик на сервис через kubernetes proxy:
-  * Когда надо дебажить сервисы, подключаясь к ним напрямую
-  * Когда надо получить доступ к какому-либо сервису
-==== NodePort ====
-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>
-Как можно было заметить, в описании фигурирует параметр 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|}}
-<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>
 ===== Авторизация =====
@@ Строка 149: / Строка 33: @@
 ===== Компоненты =====
-  * etcd
+^ Компоненты                                                                                                      ^  Описание                                                                                                                                                                                                                                  ^
-  * kubelet
+| etcd | Распределенное надежное хранилище ключей и значений для наиболее важных данных распределенной системы                                                                                                                                      |
-  * kubeadm
+| kubelet\\ kubeadm\\ kube-apiserver\\ kube-controller-manager\\ kube-proxy\\ kube-scheduler\\ kubectl  |                                                                                                                                                                                                                                            |
-  * kubelet
+| [[https://github.com/containerd/containerd|containerd]]                                                         | Это стандартная в отрасли среда выполнения контейнера. Управляет полным жизненным циклом контейнера своей хост-системы: передача и хранение образов, выполнение и контроль контейнера, низкоуровневое хранение и сетевые вложения и т. д.  |
-  * kube-apiserver
+| [[https://github.com/opencontainers/runc|runc]]                                                                 | CLI-инструмент для создания и запуска контейнеров в соответствии со спецификацией OCI                                                                                                                                                      |
-  * kube-controller-manager
-  * kube-proxy
-  * kube-scheduler
-  * kubectl
@@ Строка 169: / Строка 50: @@
   * https://habr.com/ru/companies/aenix/articles/544390/
   * https://habr.com/ru/companies/otus/articles/809941/
+===== Видео уроки =====
+  * [[https://www.youtube.com/watch?v=sLQefhPfwWE|Введение в Kubernetes на примере Minikube]]
 ===== Ссылки =====
 {{topic>[kubernetes]}}