Kubernetes для начинающих: принцип работы, установка и настройка

Введение

Хочу сразу обратить внимание на важный момент. У меня нет опыта промышленной эксплуатации кластера Kubernetes

Я нахожусь в состоянии обучения и исследования этого инструмента. Я прошел обучение Слёрм, это дало базовые знания и понимание принципов работы. Дальше стал разворачивать свои кластера и исследовать их. Изначально я не хотел писать статьи по этой теме до тех пор, пока не накопится достаточного опыта, но сейчас поменял свое мнение.

В рунете очень мало материалов по kubernetes с конкретикой и практикой, по которым можно было бы учиться. Думаю, что даже те знания, что есть сейчас у меня, будут многим полезны и интересны. Плюс, когда пишешь статьи, систематизируешь свои знания, запоминаешь и получаешь обратную связь. Ускоряется процесс обучения. Так что статьям по kubernetes и devops в целом быть. Думаю, что в ближайшее время я сфокусируюсь именно на этом.

Могу однозначно сказать, что если у вас есть необходимость в продакшене использовать Kubernetes, не тяните время и не откладывайте. Идите учиться на курсы. Самостоятельно вы не освоите в достаточном объеме материал, чтобы можно было переносить рабочую нагрузку в свой кластер. Очень много нюансов и подводных камней. Вы потратите больше времени, нервов и денег на самостоятельное освоение, если будете сами все с нуля изучать.

Лично у меня сейчас нет цели становиться администратором Kubernetes. Мой формат занятости не подразумевает обслуживание таких крупных систем и в планах этого тоже пока нет. Мне просто любопытно его исследовать, узнавать что-то новое, поэтому я этим занимаюсь. Знания карман не тянут, особенно современные и востребованные.

Если у вас нет возможности или желания настраивать кластер Kubernetes самостоятельно на своем железе, можете купить его в готовом виде как сервис в облаке Mail.ru Cloud Solutions.

В-третьих, настройте и установите мастер и миньон ноды Kubernetes.

1. Запустите виртуальную машину как главный узел.

2. Отредактируйте файл конфигурации kubeadm kubeadm.config.

3. Используйте kubeadm для инициализации главного узла.

kubeadm init —config ./kubeadm.config Using Kubernetes version: v1.10.0

……

4. Выполните указанную выше команду инициализации, чтобы настроить kubectl.

5. Установите плагин flannel CNI.

wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

kubectl apply -f kube-flannel.yml

Это запустит демон flannel на каждом узле

6. Запустите команду соединения на каждом узле.

kubeadm join 192.168.166.101:6443 —token dtvlg9.798fbe57awyzjzfx —discovery-token-ca-cert-hash sha256:a3406c544acb65954339ab9d6b9801673cb646dd17fa162fbf8aa1cd239b2b99

7. Просмотрите результаты установки.

Обратите внимание, что для сброса всего кластера вы можете выполнить следующие команды на главном сервере и на каждом узле, а затем выполнить шаг инициализации:

Чтобы переключить режим kube-proxy, вы должны изменить kubeadm.config, затем использовать kubeadm reset и затем инициализировать весь кластер

Перепечатано с https://blog.csdn.net/cloudvtech

定义 Service

Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。
像所有的 REST 对象一样，Service 定义可以基于方式，请求 API server 创建新的实例。
Service 对象的名称必须是合法的
.。

例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上标签：

上述配置创建一个名称为 «my-service» 的 Service 对象，它会将请求代理到使用
TCP 端口 9376，并且具有标签的 Pod 上。

Kubernetes 为该服务分配一个 IP 地址（有时称为 «集群IP»），该 IP 地址由服务代理使用。
(请参见下面的 ).

服务选择算符的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为
“my-service” 的 Endpoint 对象。

说明：需要注意的是，Service 能够将一个接收映射到任意的。
默认情况下，将被设置为与字段相同的值。

Pod 中的端口定义是有名字的，你可以在服务的属性中引用这些名称。
即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。
这为部署和发展服务提供了很大的灵活性。
例如，你可以更改 Pods 在新版本的后端软件中公开的端口号，而不会破坏客户端。

服务的默认协议是 TCP；你还可以使用任何其他。

由于许多服务需要公开多个端口，因此 Kubernetes 在服务对象上支持多个端口定义。
每个端口定义可以具有相同的，也可以具有不同的协议。

没有选择算符的 Service

服务最常见的是抽象化对 Kubernetes Pod 的访问，但是它们也可以抽象化其他种类的后端。
实例:

希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
希望服务指向另一个名字空间（Namespace）中或其它集群中的服务。
你正在将工作负载迁移到 Kubernetes。在评估该方法时，你仅在 Kubernetes 中运行一部分后端。

在任何这些场景中，都能够定义没有选择算符的 Service。
实例:

由于此服务没有选择算符，因此不会自动创建相应的 Endpoint 对象。
你可以通过手动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口：

Endpoints 对象的名称必须是合法的
。

说明：

端点 IPs 必须不可以是：本地回路（IPv4 的 127.0.0.0/8, IPv6 的 ::1/128）或
本地链接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64)。

端点 IP 地址不能是其他 Kubernetes 服务的集群 IP，因为
kube-proxy 不支持将虚拟 IP 作为目标。

访问没有选择算符的 Service，与有选择算符的 Service 的原理相同。
请求将被路由到用户定义的 Endpoint，YAML 中为：（TCP）。

ExternalName Service 是 Service 的特例，它没有选择算符，但是使用 DNS 名称。
有关更多信息，请参阅本文档后面的。

超出容量的 Endpoints

如果某个 Endpoints 资源中包含的端点个数超过 1000，则 Kubernetes v1.22 版本
（及更新版本）的集群会将为该 Endpoints 添加注解
。
这一注解表明所影响到的 Endpoints 对象已经超出容量，此外 Endpoints 控制器还会将 Endpoints 对象数量截断到 1000。

EndpointSlice

FEATURE STATE:

Endpoint 切片是一种 API 资源，可以为 Endpoint 提供更可扩展的替代方案。
尽管从概念上讲与 Endpoint 非常相似，但 Endpoint 切片允许跨多个资源分布网络端点。
默认情况下，一旦到达100个 Endpoint，该 Endpoint 切片将被视为“已满”，
届时将创建其他 Endpoint 切片来存储任何其他 Endpoint。

Endpoint 切片提供了附加的属性和功能，这些属性和功能在
EndpointSlices
中有详细描述。

应用协议

FEATURE STATE:

字段提供了一种为每个 Service 端口指定应用协议的方式。
此字段的取值会被映射到对应的 Endpoints 和 EndpointSlices 对象。

该字段遵循标准的 Kubernetes 标签语法。
其值可以是 IANA 标准服务名称
或以域名为前缀的名称，如。

Понимание сети Kubernetes: сервисы +15

10.01.18 06:00

•
olemskoi
•
#346314
•
Хабрахабр

•
Перевод

•

4200

Системное администрирование, Сетевые технологии, DevOps, IT-инфраструктура, Блог компании Southbridge

В первом посте этой серии я рассмотрел, как Kubernetes использует комбинацию виртуальных сетевых устройств и правил маршрутизации. Если отправитель знает IP-адрес пода, комбинация разрешает обмен информацией между подами, запускающимися на разных кластерах. Если вы не знаете, как поды обмениваются информацией, стоит прочитать об этом, перед тем как продолжить чтение статьи.

Сеть подов в кластере – аккуратный материал, но сам по себе он недостаточен для создания долгосрочных систем, поскольку поды в Kubernetes эфемерны. В качестве конечной точки можно использовать IP-адрес пода, но нет гарантии, что при следующем воссоздании пода адрес останется прежним. Его смена может произойти по любой причине.

Вероятно, вы знаете, что это старая проблема, и у нее есть стандартное решение: направить трафик через обратный прокси-сервер/балансировщик нагрузки. Клиенты подключаются к прокси, а прокси отвечает за ведение списка здоровых серверов для пересылки запросов.

Существует несколько требований к прокси-серверу:

долговечность и устойчивость к сбоям;
наличие списка серверов, которые прокси-сервер может направлять;
возможность определять, здоров ли сервер и может ли он отвечать на запросы.
Инженеры Kubernetes решили эту проблему элегантным способом. Он основывается на возможностях платформы для доставки по трем приведенным требованиям и начинается с типа ресурса, называемого сервисом.

Зачем нужен Kubernetes

Платформа создавалась с учетом наработок в управлении удаленными проектами с масштабными рабочими нагрузками. Поэтому изначально в ней применяются продвинутые технологии, которые давно заменили принципы физического и даже виртуального развертывания систем. Контейнерное построение считается «облегченным» вариантом виртуальных машин.

Причины популярности Kubernetes:

Развертываемые приложения отделены от инфраструктуры для повышения безопасности.
Разработка и тестирование работают одинаково на локальном компьютере и в облаке.
Контейнеры свободно переносятся между Ubuntu, CoreOS, RHEL и другими системами.
Происходит изоляция ресурсов с прогнозированием производительности.

Вместо монолитного стека одной выделенной машины, приложения разбиваются на независимые друг от друга микросервисы с возможностью динамического развертывания и управления. За счет такого подхода ресурсы используются более грамотно. Приложения наблюдают не только за метриками операционной системы, а еще и другими программами и оборудованием.

Services

Службы позволяют обеспечить сетевую доступность для развертываний. Существует несколько типов сервисов:

ClusterIP — сопоставление адреса с deployments для подключений внутри кластера Kubernetes.
NodePort — для внешней публикации развертывания.
LoadBalancer — сопоставление через внешний балансировщик.
ExternalName — сопоставляет службу по имени (возвращает значение записи CNAME).

Мы рассмотрим первые два варианта.

Привязка к Deployments

Попробуем создать сопоставления для ранее созданного развертывания:

kubectl expose deploy web-deploy —type=ClusterIP —port=80

* где web-deploy — deployment, который мы развернули с помощью манифеста. Публикация ресурса происходит на внутреннем порту 80. Обращаться к контейнерам можно внутри кластера Kubernetes.

Для создания сопоставления, с помощью которого можно будет подключиться к контейнерам из внешней сети выполняется командой:

kubectl expose deploy web-deploy —type=NodePort —port=80

* данная команда отличается от команды выше только типом NodePort — для данному deployment будет сопоставлен порт для внешнего подключения, который будет вести на внутренний (в нашем примере, 80).

Просмотр

Чтобы посмотреть созданные нами службы, вводим:

kubectl get services

Мы можем увидеть что-то на подобие:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-deploy NodePort 10.111.229.132 <none> 80:30929/TCP 21s

* в данном примере указано, что у нас есть служба типа NodePort, а к сервису можно подключиться по порту 30929.

Можно попробовать открыть браузер и ввести http://<IP-адрес мастера>:30929 — мы должны увидеть нужную нам страницу (в наших примерах, либо NGINX, либо Apache).

Посмотреть список сервисов с указанием селектором можно командой:

kubectl get services -o wide

Удаление

Удаляем созданную службу командой:

kubectl delete services web-deploy

* в данном примере будет удалена служба для развертывания web-deploy.

Удалить все службы можно командой:

kubectl delete services —all

Манифест

Как в случае с подами и развертываниями, мы можем использовать манифест-файлы. Рассмотрим небольшой пример.

vi manifest_service.yaml

apiVersion: v1
kind: Service
metadata:
name: web-service
labels:
app: web_server
owner: dmosk
description: web_server_for_site
spec:
selector:
project: myweb
type: NodePort
ports:
— name: app-http
protocol: TCP
port: 80
targetPort: 80
— name: app-smtp
protocol: TCP
port: 25
targetPort: 25

* в данном примере мы создадим службу, которая будем связываться с развертыванием по лейболу project: myweb.

Deploy реального приложения в кластер

Давайте теперь на реальном примере попробуем что-то запустить в кластере kubernetes. Я предлагаю для этого использовать демо магазин носков из этого репозитория — https://github.com/microservices-demo/microservices-demo. Там есть длиннющий yaml файл, который содержит в себе все необходимое (deployments, service и т.д.) для запуска магазина. Магазин состоит из множества компонентов, так что мы на практике убедимся, как легко и быстро можно деплоить сложные приложения в кластер.

Магазин настроен на работе в отдельном namespace — sock-shop. Его предварительно надо создать.

# kubectl create namespace sock-shop

Запускаем деплой всего проекта одной командой.

# kubectl apply -n sock-shop -f "https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yaml"

Наблюдать за поднятием подов можно командой в реальном времени.

# kubectl get pods -n sock-shop -w

После того, как они все станут Running можно проверять работу. В этом проекте не используется ingress, поэтому чтобы понять, как подключиться к магазину, надо провести небольшое расследование. Для начала посмотрим запущенные service.

# kubectl get service -n sock-shop -o wide

Нас интересует тип NodePort, так как к нему можно подключаться из вне. Видим, что порт используется 30001 и имя приложения front-end. Посмотрим, где оно запущено.

# kubectl get pod -n sock-shop -o wide

Этот pod запущен на kub-node-2. Посмотрим ее ip.

# kubectl get node -o wide

Ее ip адрес — 10.1.4.33. Значит для проверки магазина надо идти по урлу http://10.1.4.33:30001/

Вот он, наш магазин. Для удобства, можем сами доделать доступ через ingress по доменному имени. Настраиваем конфиг ingress.

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-sock
  namespace: sock-shop
spec:
  rules:
  - host: sock-shop.cluster.local
    http:
      paths:
      - backend:
          serviceName: front-end
          servicePort: 80

Не забывайте указывать нужный namespace и правильное имя сервиса, для которого настраиваем ingress. Применяем конфиг.

# kubectl apply -f ingress-sock.yaml

Смотрим, что получилось.

# kubectl get ingress -n sock-shop -o wide
NAME           HOSTS                     ADDRESS     PORTS   AGE
ingress-sock   sock-shop.cluster.local   10.1.4.39   80      29s

Редактируем файл hosts и идем в браузер проверять.

Поздравляю, ваш кластер работает, а вы теперь администратор кластера Kubernetes и инженер yaml файлов У вас теперь будет большая дружба с лапшеподобным синтаксисом. Идите к руководству и требуйе прибавки к зарплате минимум на 30%.

Процесс установки Kubernetes

При выборе автоматической установки вникать в детали не понадобится, но требуется выделить достаточное количество системных ресурсов, чтобы платформа работала бесперебойно. Например, при небольшом количестве контейнеров и простой взаимосвязи достаточно 1-2 процессорных ядер, 2-4 Гб оперативки и двух виртуальных машин, выполняющих функции Master и Worker Node.

Инсталляция на Ubuntu

Проще всего воспользоваться одной из готовых реализаций – Minikube или Kubespray. Если нужно установить Kubernetes на сервер с операционной системой Ubuntu вручную, понадобятся права суперпользователя. Начнем с установки Docker для узла. Перечень команд для этого выглядит следующим образом:

apt-get update

apt-get install -y docker.io

При необходимости организовать создание контейнеров более новых версий перечень команд будет несколько иным:

apt-get update

apt-get install -y \

apt-transport-https \

ca-certificates \

curl \

software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add –

add-apt-repository \

         "deb  https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \

         $(lsb_release -cs) \

         stable"

apt-get update

apt-get install -y docker-ce docker-ce-cli containerd.io

Docker для одного узла установлен. Следующий шаг – установка модулей kubeadm (создание и настройка кластеров), kubelet (их запуск на хостах), kubectl (настройка компонентов, входящих в кластер). Для этого вводятся следующие команды:

apt-get update && apt-get install -y apt-transport-https software-properties-common

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

add-apt-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

apt-get update

apt-get install -y kubelet kubeadm kubectl

systemctl enable kubelet && systemctl start kubelet

Инсталляция на CentOS

При установке на операционную систему CentOS любой версии нужно выполнить ряд требований. Так, понадобится минимум 3 машины (1 главный, 2 рабочих узла), которые подключены к общей сети или интернету. Здесь также вся работа проводится в учетной записи sudo или root. Процедура проводится, как и в случае с Ubuntu, через консоль.

Команды для установки Docker:

yum install -y docker

systemctl enable docker && systemctl start docker

Компоненты Kubernetes (kubeadm, kubelet, kubectl) инсталлируются так:

cat <<EOF > /etc/yum.repos.d/kubernetes.repo



name=Kubernetes

baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64

enabled=1

gpgcheck=1

repo_gpgcheck=1

gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

EOF

setenforce 0

yum install -y kubelet kubeadm kubectl

systemctl enable kubelet && systemctl start kubelet

После ввода команд (при отсутствии ошибок) можно приступать к настройке платформы. Процесс включает инициализацию кластера, создание CNI, добавление узлов Nodes и получение токена для авторизации.

Discovering services

Kubernetes supports 2 primary modes of finding a — environment
variables and DNS.

Environment variables

When a is run on a , the kubelet adds a set of environment variables
for each active . It supports both Docker links
compatible variables (see
)
and simpler and variables,
where the Service name is upper-cased and dashes are converted to underscores.

For example, the Service which exposes TCP port 6379 and has been
allocated cluster IP address 10.0.0.11 produces the following environment
variables:

This does imply an ordering requirement — any that a wants to
access must be created before the itself, or else the environment
variables will not be populated. DNS does not have this restriction.

DNS

An optional (though strongly recommended) cluster
add-on is a DNS server. The
DNS server watches the Kubernetes API for new and creates a set of
DNS records for each. If DNS has been enabled throughout the cluster then all
should be able to do name resolution of automatically.

For example, if you have a called in Kubernetes
a DNS record for is created.
which exist in the should be able to find it by simply doing
a name lookup for . which exist in other must
qualify the name as . The result of these name lookups is the
cluster IP.

Kubernetes also supports DNS SRV (service) records for named ports. If the
has a port named with protocol , you
can do a DNS SRV query for to discover the port
number for .