[DevOps, Kubernetes] k0s: Kubernetes в одном бинарном файле (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В нашей новой переводной статье даем краткий обзор на новый дистрибутив Kubernetes. Надеемся, статья окажется интересной для читателей Habr'a.
Пару дней назад друг рассказал мне о новом дистрибутиве Kubernetes от Mirantis под названием k0s. Все мы знаем и любим K8s, не так ли? Нас также покорил K3s, легкий Kubernetes, разработанный Rancher Labs и переданный CNCF некоторое время назад. Пришло время открыть для себя новый дистрибутив k0s!
После краткого знакомства с k0s мы создадим кластер из трех нод, выполнив следующие действия:
- Подготовка трех виртуальных машин (Multipass в действии)
- Установка k0s на каждой из них
- Настройка простого файла конфигурации кластера k0s
- Инициализация кластера
- Получение доступа к кластеру
- Добавление рабочих узлов
- Добавление пользователя
Что такое k0s?
k0s — это новейший дистрибутив Kubernetes. Текущий релиз — 0.8.0. Он был опубликован в декабре 2020 года, а первый коммит всего проекта произошел в июне 2020 года.
k0s поставляется как единый двоичный файл без каких-либо зависимостей от ОС. Таким образом, он определяется как дистрибутив Kubernetes с характеристиками zero-friction/zero-deps/zero-cost (легкость конфигурации / отсутствие зависимостей / бесплатный).
Последний релиз k0s:
- Поставляет сертифицированный (получивший аттестацию центра интернет-безопасности) Kubernetes 1.19
- Использует containerd как среду выполнения контейнера по умолчанию
- Поддерживает архитектуры Intel (x86-64) и ARM (ARM64)
- Использует внутрикластерный etcd
- По умолчанию использует сетевой плагин Calico (тем самым активируя сетевые политики)
- Включает контроллер доступа политик безопасности Pod
- Использует DNS с CoreDNS
- Предоставляет метрики кластера через Metrics Server
- Позволяет использовать горизонтальное автомасштабирование подов (HPA).
В будущих релизах появится много крутых функций, в том числе:
- Среда выполнения компактных виртуальных машин (очень жду возможности протестировать эту функцию)
- Обновление кластера с нулевым временем простоя
- Резервное копирование и восстановление кластера
Впечатляет, не правда ли? Далее мы рассмотрим, как использовать k0s для развертывания кластера из 3 нод.
Подготовка виртуальных машин
Для начала мы создадим три виртуальные машины, каждая из которых будет являться узлом в нашем кластере. В этой статье я пойду быстрым и легким путем и воспользуюсь прекрасным инструментом Multipass (обожаю его) для подготовки локальных виртуальных машин на MacOS.
Следующие команды создают три экземпляра Ubuntu на xhyve. Каждая виртуальная машина имеет 5 ГБ диска, 2 ГБ оперативной памяти и 2 виртуальных процессора (vCPU):
for i in 1 2 3; do
multipass launch -n node$i -c 2 -m 2G
done
Затем мы можем отобразить список виртуальных машин, чтобы убедиться, что все они работают нормально:
$ multipass list
Name State IPv4 Image
node1 Running 192.168.64.11 Ubuntu 20.04 LTS
node2 Running 192.168.64.12 Ubuntu 20.04 LTS
node3 Running 192.168.64.13 Ubuntu 20.04 LTS
Далее мы установим k0s на каждый из этих узлов.
Установка последнего релиза k0s
Последний релиз k0s можно скачать из репозитория GitHub.
У него есть удобный скрипт установки:
curl -sSLf get.k0s.sh | sudo sh
Мы используем этот скрипт, чтобы установить k0s на все наши узлы:
for i in 1 2 3; do
multipass exec node$i --bash -c "curl -sSLf get.k0s.sh | sudo sh"
done
Указанный скрипт устанавливает k0s в /user/bin/k0. Чтобы получить все доступные команды, нужно запустить двоичный файл без аргументов.
Доступные команды k0s
Можем проверить текущую версию:
$ k0s version
v0.8.0
Некоторые команды мы будем использовать и на следующих этапах.
Создание файла конфигурации
Во-первых, необходимо определить файл конфигурации, содержащий информацию, необходимую k0s для создания кластера. На node1 мы можем выполнить команду default-config, чтобы получить полную конфигурацию по умолчанию.
ubuntu@node1:~$ k0s default-config
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
- 192.168.64.11
extraArgs: {}
controllerManager:
extraArgs: {}
scheduler:
extraArgs: {}
storage:
type: etcd
kine: null
etcd:
peerAddress: 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
provider: calico
calico:
mode: vxlan
vxlanPort: 4789
vxlanVNI: 4096
mtu: 1450
wireguard: false
podSecurityPolicy:
defaultPolicy: 00-k0s-privileged
workerProfiles: []
extensions: null
images:
konnectivity:
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent
version: v0.0.13
metricsserver:
image: gcr.io/k8s-staging-metrics-server/metrics-server
version: v0.3.7
kubeproxy:
image: k8s.gcr.io/kube-proxy
version: v1.19.4
coredns:
image: docker.io/coredns/coredns
version: 1.7.0
calico:
cni:
image: calico/cni
version: v3.16.2
flexvolume:
image: calico/pod2daemon-flexvol
version: v3.16.2
node:
image: calico/node
version: v3.16.2
kubecontrollers:
image: calico/kube-controllers
version: v3.16.2
repository: ""
telemetry:
interval: 10m0s
enabled: true
Помимо прочего, это позволяет нам определить:
- Параметры запуска сервера API, диспетчера контроллеров и планировщика
- Хранилище, которое можно использовать для сохранения информации о кластере (etcd)
- Сетевой плагин и его конфигурацию (Calico)
- Версию образов контейнеров с компонентами управления
- Некоторые дополнительные схемы управления, которые следует развернуть при запуске кластера
Мы могли бы сохранить эту конфигурацию в файл и адаптировать ее под свои нужды. Но в этой статье мы воспользуемся очень простой конфигурацией и сохраним ее в /etc/k0s/k0s.yaml.
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
Примечание: Так как мы инициализируем кластер на узле node1, этот узел будет обслуживать сервер API. IP-адрес этого узла используется в api.address и api.sans (альтернативные имена субъектов) в приведенном выше файле конфигурации. Если бы у нас были дополнительные главные узлы и балансировщик нагрузки над ними, мы бы также использовали в настройках api.sans IP-адрес каждого узла и балансировщика нагрузки (или соответствующее доменное имя).
Инициализация кластера
Сначала мы создаем systemd unit на node1 для управления k0s.
[Unit]
Description="k0s server"
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/k0s server -c /etc/k0s/k0s.yaml --enable-worker
Restart=always
Основная команда здесь указана в ExecStart; она запускает сервер k0s с той конфигурацией, которую мы сохранили в наш файл на предыдущем этапе. Мы также указываем параметр --enable-worker, чтобы этот первый главный узел также функционировал как рабочий.
Затем мы копируем этот файл в /lib/systemd/system/k0s.service, перезагружаем systemd и запускаем недавно созданную службу.
ubuntu@node1:~$ sudo systemctl daemon-reload
ubuntu@node1:~$ sudo systemctl start k0s.service
Ради любопытства можно проверить процессы, запущенные сервером k0s:
ubuntu@node1:~$ sudo ps aux | awk ‘{print $11}’ | grep k0s
/usr/bin/k0s
/var/lib/k0s/bin/etcd
/var/lib/k0s/bin/konnectivity-server
/var/lib/k0s/bin/kube-controller-manager
/var/lib/k0s/bin/kube-scheduler
/var/lib/k0s/bin/kube-apiserver
/var/lib/k0s/bin/containerd
/var/lib/k0s/bin/kubelet
Из выходных данных выше мы видим, что все основные компоненты запущены (kube-apiserver, kube-controller-manager, kube-scheduler и т. д.), а также компоненты, общие для главных и рабочих узлов (containerd, kubelet). k0s отвечает за управление всеми этими компонентами.
Теперь мы имеем кластер из 1 ноды. На следующем этапе мы увидим, как получить к нему доступ.
Получение доступа к кластеру
Сначала нам необходимо получить файл kubeconfig, сгенерированный во время создания кластера; он был создан на node1 в /var/lib/k0s/pki/admin.conf. Этот файл нужно использовать для настройки kubectl на локальной машине.
Сначала получаем kubeconfig кластера из node1:
# Get kubeconfig file
$ multipass exec node1 cat /var/lib/k0s/pki/admin.conf > k0s.cfg
Далее заменяем внутренний IP-адрес на внешний IP-адрес node1:
# Replace IP address
$ NODE1_IP=$(multipass info node1 | grep IP | awk '{print $2}')
sed -i '' "s/localhost/$NODE1_IP/" k0s.cfg
Затем выполняем конфигурацию нашего локального клиента kubectl для связи с сервером k0s API:
export KUBECONFIG=$PWD/k0s.cfg
Наверняка одной из первых команд, которые мы запускаем при входе в новый кластер, является та, которая отображает список всех доступных узлов, — давайте попробуем:
$ kubectl get no
NAME STATUS ROLES AGE VERSION
node1 Ready <none> 78s v1.19.4
Здесь нет ничего удивительного. Ведь node1 является не только главным, но и рабочим узлом нашего первого кластера благодаря флагу --enable-worker, который мы указали в команде запуска. Без этого флага node1 был бы только рабочим и не отображался бы в списке узлов здесь.
Добавление рабочих узлов
Чтобы добавить в кластер node2 и node3, сначала нам нужно создать токен соединения из node1 (это довольно распространенный этап, так как он используется в кластерах Docker Swarm и Kubernetes, созданных с помощью kubeadm).
$ TOKEN=$(k0s token create --role=worker)
Вышеуказанная команда генерирует длинный (очень длинный) токен. Используя его, мы можем присоединить к кластеру node2 и node3:
ubuntu@node2:~$ k0s worker $TOKEN
ubuntu@node3:~$ k0s worker $TOKEN
Примечание: В реальном кластере мы бы использовали systemd (или другой супервизор) для управления процессами k0s для рабочих узлов, как мы сделали для главного узла.
Наш трехузловой кластер запущен и работает, в чем мы можем убедиться, отобразив список узлов перечислив узлы еще раз:
$ kubectl get no
NAME STATUS ROLES AGE VERSION
node1 Ready <none> 30m v1.19.4
node2 Ready <none> 35s v1.19.4
node3 Ready <none> 32s v1.19.4
Мы также можем проверить поды, работающие во всех пространствах имен:
Список подов, работающих в кластере во всех пространствах имен
Здесь следует отметить несколько моментов:
- Как обычно, мы видим поды kube-proxy, поды сетевых плагинов (на основе Calico), а также под для CoreDNS.
- Поды api-server, scheduler и controller-manager не отображаются в этом списке, поскольку они выполняются как обычные процессы, а не внутри подов.
Добавление пользователя
Версия k0s 0.8.0 содержит подкоманду user. Это позволяет создать kubeconfig для дополнительного пользователя/группы. Например, следующая команда создает для нового пользователя файл kubeconfig с названием demo, который находится внутри имитированной группы (imaginary group) с названием development.
Примечание: В Kubernetes пользователи и группы управляются администратором вне кластера, то есть в K8s нет ресурса «пользователь-не-группа».
$ sudo k0s user create demo --groups development > demo.kubeconfig
Для лучшего понимания мы извлечем сертификат клиента из этого файла kubeconfig и декодируем его из представления base64:
$ cat demo.kubeconfig | grep client-certificate-data | awk '{print $2}' | base64 --decode > demo.crt
Затем мы используем команду openssl чтобы получить содержимое сертификата:
ubuntu@node1:~$ openssl x509 -in demo.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
71:8b:a4:4d:be:76:70:8a:...:07:60:67:c1:2d:51:94
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = kubernetes-ca
Validity
Not Before: Dec 2 13:50:00 2020 GMT
Not After : Dec 2 13:50:00 2021 GMT
Subject: O = development, CN = demo
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:be:87:dd:15:46:91:98:eb:b8:38:34:77:a4:99:
da:4b:d6:ca:09:92:f3:29:28:2d:db:7a:0b:9f:91:
65:f3:11:bb:6c:88:b1:8f:46:6e:38:71:97:b7:b5:
9b:8d:32:86:1f:0b:f8:4e:57:4f:1c:5f:9f:c5:ee:
40:23:80:99:a1:77:30:a3:46:c1:5b:3e:1c:fa:5c:
- Свойство issuer — это kubernetes-ca, который является центром сертификации нашего кластера k0s.
- Subject — это O = development, CN = demo; эта часть важна, так как именно здесь появляется имя и группа пользователя. Так как сертификат подписан центром сертификации кластера, подключаемый модуль на api-server может аутентифицировать пользователя/группу по общему имени (CN) и организации (O) в теме сертификата.
Сначала мы даем команду kubectl использовать контекст, определенный в этом новом файле kubeconfig:
$ export KUBECONFIG=$PWD/demo.kubeconfig
Затем еще раз отображаем список узлов перечисляем узлы кластера:
$ kubectl get no
Error from server (Forbidden): nodes is forbidden: User “demo” cannot list resource “nodes” in API group “” at the cluster scope
Это сообщение об ошибке было ожидаемым. Даже если api-server идентифицировал пользователя (сертификат, отправленный вместе с запросом пользователя, был подписан центром сертификации кластера), он не имеет права выполнять какие-либо действия в кластере.
Дополнительные права можно легко добавить, создав Role/ClusterRole и привязав их к пользователю при помощи RoleBinding/ClusterRoleBinding, но эту задачу я оставляю в качестве упражнения для читателя.
Заключение
k0s определенно стоит рассмотреть. Такой подход, когда единый двоичный файл управляет всеми процессами, очень интересен.
В данной статье представлен только краткий обзор k0s, но я обязательно буду отслеживать его развитие и посвящу будущие статьи этому новому и перспективному дистрибутиву Kubernetes. Некоторые из будущих функций кажутся действительно многообещающими, и я с нетерпением жду возможности их протестировать.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Luc Juggery
===========Похожие новости:
- [Системное администрирование, Карьера в IT-индустрии, DevOps] После DevOps: как стать SRE и устроиться на работу в Google
- [Open source, Сетевые технологии, Kubernetes] Tigera запускает новый учебный портал Tigera Academy — бесплатную платформу для обучения и сертификации по Calico
- [Системное администрирование, Серверное администрирование, DevOps, Kubernetes] Понимание вертикального автомасштабирования подов в Kubernetes (перевод)
- [Настройка Linux, Разработка под Linux] Сборка и установка Linux пакетов в российских сертифицированных ОС
- [Разработка под iOS, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android, DevOps] Да кто такой этот ваш Mobile DevOps?
- [Серверное администрирование, Amazon Web Services, DevOps, Облачные сервисы] Как защититься от неожиданных счетов за AWS (перевод)
- [Системы сборки, DevOps] «Нюансы» использования TeamCity
- [Тестирование IT-систем, Разработка мобильных приложений, IT-инфраструктура, Разработка под Android, DevOps] VirtualBox — Запуск Android эмулятора в виртуальной среде для тестирования Android проекта
- [SQL, Apache, DevOps, Data Engineering] Наши грабли — залог вашего успеха. Кейсы DevOps и SQL-команд
- [Тестирование IT-систем, Программирование, Kubernetes] Тестирование инфраструктуры как кода Terraform: анализ модульных тестов и сквозной разработки путем тестирования поведен (перевод)
Теги для поиска: #_devops, #_kubernetes, #_kubernetes, #_devops, #_blog_kompanii_timeweb (
Блог компании Timeweb
), #_devops, #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:32
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В нашей новой переводной статье даем краткий обзор на новый дистрибутив Kubernetes. Надеемся, статья окажется интересной для читателей Habr'a.
Пару дней назад друг рассказал мне о новом дистрибутиве Kubernetes от Mirantis под названием k0s. Все мы знаем и любим K8s, не так ли? Нас также покорил K3s, легкий Kubernetes, разработанный Rancher Labs и переданный CNCF некоторое время назад. Пришло время открыть для себя новый дистрибутив k0s!  После краткого знакомства с k0s мы создадим кластер из трех нод, выполнив следующие действия:
Что такое k0s? k0s — это новейший дистрибутив Kubernetes. Текущий релиз — 0.8.0. Он был опубликован в декабре 2020 года, а первый коммит всего проекта произошел в июне 2020 года. k0s поставляется как единый двоичный файл без каких-либо зависимостей от ОС. Таким образом, он определяется как дистрибутив Kubernetes с характеристиками zero-friction/zero-deps/zero-cost (легкость конфигурации / отсутствие зависимостей / бесплатный). Последний релиз k0s:
В будущих релизах появится много крутых функций, в том числе:
Впечатляет, не правда ли? Далее мы рассмотрим, как использовать k0s для развертывания кластера из 3 нод. Подготовка виртуальных машин Для начала мы создадим три виртуальные машины, каждая из которых будет являться узлом в нашем кластере. В этой статье я пойду быстрым и легким путем и воспользуюсь прекрасным инструментом Multipass (обожаю его) для подготовки локальных виртуальных машин на MacOS. Следующие команды создают три экземпляра Ubuntu на xhyve. Каждая виртуальная машина имеет 5 ГБ диска, 2 ГБ оперативной памяти и 2 виртуальных процессора (vCPU): for i in 1 2 3; do multipass launch -n node$i -c 2 -m 2G done Затем мы можем отобразить список виртуальных машин, чтобы убедиться, что все они работают нормально: $ multipass list Name State IPv4 Image node1 Running 192.168.64.11 Ubuntu 20.04 LTS node2 Running 192.168.64.12 Ubuntu 20.04 LTS node3 Running 192.168.64.13 Ubuntu 20.04 LTS Далее мы установим k0s на каждый из этих узлов. Установка последнего релиза k0s Последний релиз k0s можно скачать из репозитория GitHub. У него есть удобный скрипт установки: curl -sSLf get.k0s.sh | sudo sh Мы используем этот скрипт, чтобы установить k0s на все наши узлы: for i in 1 2 3; do multipass exec node$i --bash -c "curl -sSLf get.k0s.sh | sudo sh" done Указанный скрипт устанавливает k0s в /user/bin/k0. Чтобы получить все доступные команды, нужно запустить двоичный файл без аргументов.  Доступные команды k0s Можем проверить текущую версию: $ k0s version v0.8.0 Некоторые команды мы будем использовать и на следующих этапах. Создание файла конфигурации Во-первых, необходимо определить файл конфигурации, содержащий информацию, необходимую k0s для создания кластера. На node1 мы можем выполнить команду default-config, чтобы получить полную конфигурацию по умолчанию. ubuntu@node1:~$ k0s default-config apiVersion: k0s.k0sproject.io/v1beta1 kind: Cluster metadata: name: k0s spec: api: address: 192.168.64.11 sans: - 192.168.64.11 - 192.168.64.11 extraArgs: {} controllerManager: extraArgs: {} scheduler: extraArgs: {} storage: type: etcd kine: null etcd: peerAddress: 192.168.64.11 network: podCIDR: 10.244.0.0/16 serviceCIDR: 10.96.0.0/12 provider: calico calico: mode: vxlan vxlanPort: 4789 vxlanVNI: 4096 mtu: 1450 wireguard: false podSecurityPolicy: defaultPolicy: 00-k0s-privileged workerProfiles: [] extensions: null images: konnectivity: image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent version: v0.0.13 metricsserver: image: gcr.io/k8s-staging-metrics-server/metrics-server version: v0.3.7 kubeproxy: image: k8s.gcr.io/kube-proxy version: v1.19.4 coredns: image: docker.io/coredns/coredns version: 1.7.0 calico: cni: image: calico/cni version: v3.16.2 flexvolume: image: calico/pod2daemon-flexvol version: v3.16.2 node: image: calico/node version: v3.16.2 kubecontrollers: image: calico/kube-controllers version: v3.16.2 repository: "" telemetry: interval: 10m0s enabled: true Помимо прочего, это позволяет нам определить:
Мы могли бы сохранить эту конфигурацию в файл и адаптировать ее под свои нужды. Но в этой статье мы воспользуемся очень простой конфигурацией и сохраним ее в /etc/k0s/k0s.yaml. apiVersion: k0s.k0sproject.io/v1beta1 kind: Cluster metadata: name: k0s spec: api: address: 192.168.64.11 sans: - 192.168.64.11 network: podCIDR: 10.244.0.0/16 serviceCIDR: 10.96.0.0/12 Примечание: Так как мы инициализируем кластер на узле node1, этот узел будет обслуживать сервер API. IP-адрес этого узла используется в api.address и api.sans (альтернативные имена субъектов) в приведенном выше файле конфигурации. Если бы у нас были дополнительные главные узлы и балансировщик нагрузки над ними, мы бы также использовали в настройках api.sans IP-адрес каждого узла и балансировщика нагрузки (или соответствующее доменное имя). Инициализация кластера Сначала мы создаем systemd unit на node1 для управления k0s. [Unit] Description="k0s server" After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/bin/k0s server -c /etc/k0s/k0s.yaml --enable-worker Restart=always Основная команда здесь указана в ExecStart; она запускает сервер k0s с той конфигурацией, которую мы сохранили в наш файл на предыдущем этапе. Мы также указываем параметр --enable-worker, чтобы этот первый главный узел также функционировал как рабочий. Затем мы копируем этот файл в /lib/systemd/system/k0s.service, перезагружаем systemd и запускаем недавно созданную службу. ubuntu@node1:~$ sudo systemctl daemon-reload ubuntu@node1:~$ sudo systemctl start k0s.service Ради любопытства можно проверить процессы, запущенные сервером k0s: ubuntu@node1:~$ sudo ps aux | awk ‘{print $11}’ | grep k0s /usr/bin/k0s /var/lib/k0s/bin/etcd /var/lib/k0s/bin/konnectivity-server /var/lib/k0s/bin/kube-controller-manager /var/lib/k0s/bin/kube-scheduler /var/lib/k0s/bin/kube-apiserver /var/lib/k0s/bin/containerd /var/lib/k0s/bin/kubelet Из выходных данных выше мы видим, что все основные компоненты запущены (kube-apiserver, kube-controller-manager, kube-scheduler и т. д.), а также компоненты, общие для главных и рабочих узлов (containerd, kubelet). k0s отвечает за управление всеми этими компонентами. Теперь мы имеем кластер из 1 ноды. На следующем этапе мы увидим, как получить к нему доступ. Получение доступа к кластеру Сначала нам необходимо получить файл kubeconfig, сгенерированный во время создания кластера; он был создан на node1 в /var/lib/k0s/pki/admin.conf. Этот файл нужно использовать для настройки kubectl на локальной машине. Сначала получаем kubeconfig кластера из node1: # Get kubeconfig file $ multipass exec node1 cat /var/lib/k0s/pki/admin.conf > k0s.cfg Далее заменяем внутренний IP-адрес на внешний IP-адрес node1: # Replace IP address $ NODE1_IP=$(multipass info node1 | grep IP | awk '{print $2}') sed -i '' "s/localhost/$NODE1_IP/" k0s.cfg Затем выполняем конфигурацию нашего локального клиента kubectl для связи с сервером k0s API: export KUBECONFIG=$PWD/k0s.cfg Наверняка одной из первых команд, которые мы запускаем при входе в новый кластер, является та, которая отображает список всех доступных узлов, — давайте попробуем: $ kubectl get no NAME STATUS ROLES AGE VERSION node1 Ready <none> 78s v1.19.4 Здесь нет ничего удивительного. Ведь node1 является не только главным, но и рабочим узлом нашего первого кластера благодаря флагу --enable-worker, который мы указали в команде запуска. Без этого флага node1 был бы только рабочим и не отображался бы в списке узлов здесь. Добавление рабочих узлов Чтобы добавить в кластер node2 и node3, сначала нам нужно создать токен соединения из node1 (это довольно распространенный этап, так как он используется в кластерах Docker Swarm и Kubernetes, созданных с помощью kubeadm). $ TOKEN=$(k0s token create --role=worker) Вышеуказанная команда генерирует длинный (очень длинный) токен. Используя его, мы можем присоединить к кластеру node2 и node3: ubuntu@node2:~$ k0s worker $TOKEN ubuntu@node3:~$ k0s worker $TOKEN Примечание: В реальном кластере мы бы использовали systemd (или другой супервизор) для управления процессами k0s для рабочих узлов, как мы сделали для главного узла. Наш трехузловой кластер запущен и работает, в чем мы можем убедиться, отобразив список узлов перечислив узлы еще раз: $ kubectl get no NAME STATUS ROLES AGE VERSION node1 Ready <none> 30m v1.19.4 node2 Ready <none> 35s v1.19.4 node3 Ready <none> 32s v1.19.4 Мы также можем проверить поды, работающие во всех пространствах имен:  Список подов, работающих в кластере во всех пространствах имен Здесь следует отметить несколько моментов:
Добавление пользователя Версия k0s 0.8.0 содержит подкоманду user. Это позволяет создать kubeconfig для дополнительного пользователя/группы. Например, следующая команда создает для нового пользователя файл kubeconfig с названием demo, который находится внутри имитированной группы (imaginary group) с названием development. Примечание: В Kubernetes пользователи и группы управляются администратором вне кластера, то есть в K8s нет ресурса «пользователь-не-группа». $ sudo k0s user create demo --groups development > demo.kubeconfig Для лучшего понимания мы извлечем сертификат клиента из этого файла kubeconfig и декодируем его из представления base64: $ cat demo.kubeconfig | grep client-certificate-data | awk '{print $2}' | base64 --decode > demo.crt Затем мы используем команду openssl чтобы получить содержимое сертификата: ubuntu@node1:~$ openssl x509 -in demo.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 71:8b:a4:4d:be:76:70:8a:...:07:60:67:c1:2d:51:94 Signature Algorithm: sha256WithRSAEncryption Issuer: CN = kubernetes-ca Validity Not Before: Dec 2 13:50:00 2020 GMT Not After : Dec 2 13:50:00 2021 GMT Subject: O = development, CN = demo Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:be:87:dd:15:46:91:98:eb:b8:38:34:77:a4:99: da:4b:d6:ca:09:92:f3:29:28:2d:db:7a:0b:9f:91: 65:f3:11:bb:6c:88:b1:8f:46:6e:38:71:97:b7:b5: 9b:8d:32:86:1f:0b:f8:4e:57:4f:1c:5f:9f:c5:ee: 40:23:80:99:a1:77:30:a3:46:c1:5b:3e:1c:fa:5c:
Сначала мы даем команду kubectl использовать контекст, определенный в этом новом файле kubeconfig: $ export KUBECONFIG=$PWD/demo.kubeconfig Затем еще раз отображаем список узлов перечисляем узлы кластера: $ kubectl get no Error from server (Forbidden): nodes is forbidden: User “demo” cannot list resource “nodes” in API group “” at the cluster scope Это сообщение об ошибке было ожидаемым. Даже если api-server идентифицировал пользователя (сертификат, отправленный вместе с запросом пользователя, был подписан центром сертификации кластера), он не имеет права выполнять какие-либо действия в кластере. Дополнительные права можно легко добавить, создав Role/ClusterRole и привязав их к пользователю при помощи RoleBinding/ClusterRoleBinding, но эту задачу я оставляю в качестве упражнения для читателя. Заключение k0s определенно стоит рассмотреть. Такой подход, когда единый двоичный файл управляет всеми процессами, очень интересен. В данной статье представлен только краткий обзор k0s, но я обязательно буду отслеживать его развитие и посвящу будущие статьи этому новому и перспективному дистрибутиву Kubernetes. Некоторые из будущих функций кажутся действительно многообещающими, и я с нетерпением жду возможности их протестировать. =========== Источник: habr.com =========== =========== Автор оригинала: Luc Juggery ===========Похожие новости:
Блог компании Timeweb ), #_devops, #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:32
Часовой пояс: UTC + 5