Translate

вівторок, 8 березня 2022 р.

Kubernetes. Part II: Setup Cluster With Kubeadm. Plugins

Після ознайомлення з теорією можна перейти і до практичної частини. Цього разу установимо кластер Kubernetes на bare-metal, тобто звичайні віртуальні машини чи залізні сервера, що не входять до існуючих IAAS платформ.

Способів установки Kubernetes кластеру існує дуже багато. Всі ці перераховані варіанти різної актуальності, необхідно дивитись і перевіряти все уважно, щоб не витратити зайвого часу на марні спроби. Найбільш популярні способи:

  • minikube чи kind. Найпростіший спосіб установки Kubernetes на власний локальний PC. Буде корисний людям, котрі хочуть приступити до вивчення Kubernetes, не втрачаючи купу часу на його більш повноцінну установку, чи локального тестування роботи додатків, що потреують цього середовища.
  • kubeadm. Офіційний, доволі мануальний спосіб. Підтримує установку на звичайні bare-metal сервера чи віртуальні машини, що працюють під управлінням OS Linux. Наразі kubeadm також підтримує створення HA (High Availability) Master інсталяцій.
  • kops. Призначений для розгортання Kubernetes на AWS, для чого використовує API-виклики платформи. Написаний на мові Go. Як зазначено на github сторінці проекту, робота kops з GCE, OpenStack та DigitalOcean перебуває в статусі бета, а в майбутньому також планується підтримка інших хмарних платформ. Також підтримує розгортання HA Master конфігурацій.
  • kubespray. Це набір Ansible плейбуків для розгортання Kubernetes на платформах AWS, GCE, Azure, OpenStack, vSphere, bare-metal машинах і т.п. Має найбільш обширний список підтримки дистрибутивів Linux. Також підтримує установку HA Master конфігурацій. Це community-проект, детальніше про нього можна прочитати за посиланням.
  • K0s. Установка K8s по ssh але, на відміну від Kubespray, без залучення Ansible. Написаний на мові Go компанією Mirantis. Я йому присвятив окрему статтю в блозі, де і можна ознайомитись із деталями.
  • Варіанти, що пропонують провайдери хостингів чи клауди. На зразок AWS Elastic Kubernetes Service (EKS) чи Google Kubernetes Engine (GKE). Мабуть найпростіший варіант, котрий в тому числі найпростіший в обслуговуванні.
  • Та багато-багато інших варіантів

У цій статті ми розгорнемо власний кластер Kubernetes за допомогою утиліти kubeadm. Це буде не HA інсталяція (тобто не production-ready варіант) на основі операційної системи Ubuntu 20.04, що в свою чергу працюватиме в системі віртуалізації VirtualBox. Перелік адрес хостів та їх доменів наступний:

k8s-m-a  192.168.1.45
k8s-s-a    192.168.1.48
k8s-s-b    192.168.1.49

Як рекомендує офіційна документація, кожній віртуальній машині варто виділити як мінімум 2ГБ оперативної пам’яті і 2 ядра, інакше може не вистачити місця для запуску додатків.

Kubernetes використовує Docker у якості runtime для запуску контейнерів, тому спочатку його необхідно встановити на всі вузли:

$ sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io

Вкажемо який драйвер будемо використовувати для cgroups:

$ echo '{"exec-opts": ["native.cgroupdriver=systemd"]}' >> /etc/docker/daemon.json
$ systemctl restart docker

Варто також загадати, що Docker було оголошено як deprecated, тому схоже ліпше користуватись іншими CRI на зразок CRI-O, Containerd.

Проінсталюємо kubectl. Це утиліта управління кластером і необхідна вона лише там, де будуть виконуватись сервісні команди. Проте, можливо, вона не буде зайвою і на всіх вузлах кластеру:

# curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

# chmod +x ./kubectl
# mv ./kubectl /usr/local/bin/kubectl


За наступним посиланням можна знайти також kubectl для Mac та Windows.

Тепер проінсталюємо kubeadm (пакет, завдяки якому збирається кластер) та kubelet. Вони необхідні на всіх вузлах кластеру:

# apt-get update
# apt-get install -y apt-transport-https
# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

# echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list

# apt-get update
# apt-get install -y kubelet kubeadm

Установка kubelet та kubeadm нічим не складніша і для CentOS.

Control Plane (раніше його називали Master) - це вузол, на якому будуть запущені всі компоненти контролю кластера: etcd, kube-apiserver, kube-controller-manager та інші. У нашому випадку вони всі працюватимуть на одному вузлі. Ініціалізуємо майстер:

root@k8s-m-a:~# kubeadm init --pod-network-cidr=10.30.0.0/24
...

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join 192.168.1.45:6443 --token ttt5y5.3ln3rz1eom0aq4un --discovery-token-ca-cert-hash sha256:9b558b78fa5346f42a9a0d98db58e8ae1d3db3a44c6c2cac23c88ac4ec6bc225

Далі, як видно із виводу останньої команди, необхідно скопіювати налаштування admin.conf на всі вузли, з яких є необхідність управління кластером:

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

Установити плагін для реалізації оверлейної мережі для зв'язку pod-to-pod чи pod-to-services. Я скористався Calico плагіном:

$ curl https://docs.projectcalico.org/manifests/calico.yaml -O
$ kubectl apply -f calico.yaml

Деталі щодо установки інших плагінів та їх перелік доступний в офіційній документації Kubernetes. Тут можна почитати про їхні особливості та продуктивність роботи.

Наразі нам нічого не заважає приступити до підключення нод (воркерів) до вже працюючого майстра. Тому по черзі підключемо сервери k8s-s-a та k8-s-b. Значення токену беремо з попереднього виводу kubeadm init:

# kubeadm join 192.168.1.45:6443 --token ttt5y5.3ln3rz1eom0aq4un --discovery-token-ca-cert-hash sha256:9b558b78fa5346f42a9a0d98db58e8ae1d3db3a44c6c2cac23c88ac4ec6bc225

Виведемо список вузлів, що входять в кластер:

root@k8s-m-a:~# kubectl get nodes
NAME      STATUS   ROLES                  AGE     VERSION
k8s-m-a   Ready    control-plane,master   5d      v1.23.4
k8s-s-a   Ready    <none>                 4d23h   v1.23.4
k8s-s-b   Ready    <none>                 4d22h   v1.23.4

Та інформацію по кластеру:

# kubectl cluster-info
Kubernetes control plane is running at https://192.168.1.45:6443
CoreDNS is running at https://192.168.1.45:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.



TEST APP: SOCK SHOP


Здається, кластер наразі працює. Запустимо тестовий додаток Sock Shop, щоб в цьому пересвідчитись на прикладі. Створимо новий namespace:

# kubectl create namespace sock-shop
namespace "sock-shop" created


Скориставшись готовим описом Kubernetes об'єктів complete-demo.yaml, задеплоїмо додаток:

# kubectl apply -n sock-shop -f "https://github.com/microservices-demo/microservices-demo/blob/master/deploy/kubernetes/complete-demo.yaml?raw=true"
namespace/sock-shop configured
deployment.apps/carts created
service/carts created
deployment.apps/carts-db created
service/carts-db created
deployment.apps/catalogue created
service/catalogue created
deployment.apps/catalogue-db created
service/catalogue-db created
deployment.apps/front-end created
service/front-end created
deployment.apps/orders created
service/orders created
deployment.apps/orders-db created
service/orders-db created
deployment.apps/payment created
service/payment created
deployment.apps/queue-master created
service/queue-master created
deployment.apps/rabbitmq created
service/rabbitmq created
deployment.apps/session-db created
service/session-db created
deployment.apps/shipping created
service/shipping created
deployment.apps/user created
service/user created
deployment.apps/user-db created
service/user-db created

Звісно це не миттєва операція, і, можливо, варто буде трохи зачекати.

Завдяки опції nodePort: 30001 сервісу front-end можна перевірити роботу додатку в браузері, якщо перебувати в тій же мережі, що і вузли кластеру:


Пересвідчитись в цьому також можна через kubectl:

# kubectl -n sock-shop get svc front-end
NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
front-end   NodePort   10.105.253.84   <none>        80:30001/TCP   4m16

Додаток Sock Shop доступний також і для інших платформ контейнеризації та оркестрації. Його можна використовувати як приклад для розробки мікросервісів.


CONTAINER RESOURCE MONITORING (metrics-server/prometheus/alertmanager/grafana)

 
Базову інформацію про використання ресурсів може надати аддон metrics-server, котрий відповідальний за опитування Kubelet на кожному вузлі. Проте загалом metrics-server має використовуватись лише для потреб автоскейлінгу.

Перейдемо до установки metric-server:

$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Після цього вже можна отримати інформацію по CPU/RAM на вузлах:

$ kubectl top node
NAME      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
k8s-m-a   168m         8%     1535Mi          66%       
k8s-s-a   92m          4%     763Mi           32%       
k8s-s-b   99m          4%     1051Mi          45%

Та подах:

$ kubectl top pod

Для потреб моніторингу варто використовувати kube-state-metrics та Prometheus/Alertmanager/Grafana стек. Установлюється все наступним чином:

$ git clone git clone https://github.com/prometheus-operator/kube-prometheus.git
$ cd kube-prometheus/

$ kubectl create -f manifests/setup
$ kubectl create -f manifests/

Варто зачекати деякий час для завантаження і запуску контейнерів:

$ kubectl get pods -n monitoring
NAME                                   READY   STATUS    RESTARTS   AGE
alertmanager-main-0                    2/2     Running   0          90s
alertmanager-main-1                    2/2     Running   0          90s
alertmanager-main-2                    2/2     Running   0          90s
blackbox-exporter-7d89b9b799-tlwl2     3/3     Running   0          2m41s
grafana-5577bc8799-b2bns               1/1     Running   0          2m40s
kube-state-metrics-d5754d6dc-9qq4x     3/3     Running   0          2m40s
node-exporter-56j7n                    2/2     Running   0          2m40s
node-exporter-cd2b7                    2/2     Running   0          2m40s
node-exporter-ndsmj                    2/2     Running   0          2m40s
prometheus-adapter-6998fcc6b5-gsmtz    1/1     Running   0          2m39s
prometheus-adapter-6998fcc6b5-mwczw    1/1     Running   0          2m39s
prometheus-k8s-0                       2/2     Running   0          90s
prometheus-k8s-1                       2/2     Running   0          90s
prometheus-operator-59647c66cf-c9sds   2/2     Running   0          2m39s

$ kubectl get svc -n monitoring
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
alertmanager-main       ClusterIP   10.97.134.111    <none>        9093/TCP,8080/TCP            5m3s
alertmanager-operated   ClusterIP   None             <none>        9093/TCP,9094/TCP,9094/UDP   3m52s
blackbox-exporter       ClusterIP   10.105.221.115   <none>        9115/TCP,19115/TCP           5m3s
grafana                 ClusterIP   10.107.189.218   <none>        3000/TCP                     5m2s
kube-state-metrics      ClusterIP   None             <none>        8443/TCP,9443/TCP            5m2s
node-exporter           ClusterIP   None             <none>        9100/TCP                     5m2s
prometheus-adapter      ClusterIP   10.103.137.102   <none>        443/TCP                      5m2s
prometheus-k8s          ClusterIP   10.100.10.148    <none>        9090/TCP,8080/TCP            5m2s
prometheus-operated     ClusterIP   None             <none>        9090/TCP                     3m52s
prometheus-operator     ClusterIP   None             <none>        8443/TCP                     5m1s

Побачити веб-панелі Prometheus/Alertmanager/Grafana можна за допомогою 'kubectl port-forward' чи змінивши тип сервіса кожного із цих додатків на NodePort, проте не варто використовувати patch для production середовищ:

$ kubectl --namespace monitoring patch svc prometheus-k8s -p '{"spec": {"type": "NodePort"}}'
service/prometheus-k8s patched

$ kubectl --namespace monitoring patch svc alertmanager-main -p '{"spec": {"type": "NodePort"}}'
service/alertmanager-main patched

$ kubectl --namespace monitoring patch svc grafana -p '{"spec": {"type": "NodePort"}}'
service/grafana patched

$ kubectl -n monitoring get svc  | grep NodePort
alertmanager-main       NodePort    10.97.134.111    <none>        9093:32691/TCP,8080:30388/TCP   11m
grafana                 NodePort    10.107.189.218   <none>        3000:30930/TCP                  11m
prometheus-k8s          NodePort    10.100.10.148    <none>        9090:30576/TCP,8080:30671/TCP   11m




Звісно, можна також скористатись Ingress-ом чи LoadBalancer-сервісом, але це вже зовсім інші історія.



KUBERNETES DASHBOARD


Це один із додатків, що працює в окремому просторі імен kube-system. Його установка досить тривіальна:

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created


Перевіримо чи працюють відповідні поди:

$ kubectl get pods -n kubernetes-dashboard
NAME                                         READY   STATUS    RESTARTS   AGE
dashboard-metrics-scraper-799d786dbf-vmhbr   1/1     Running   0          111s
kubernetes-dashboard-546cbc58cd-sdmxl        1/1     Running   0          111s


Щоб переглянути Dashboard необхідно як і раніше перекинути порт через 'kubectl port-forward', або ж змінити тип сервісу на nodePort. Це серед швидких варіантів:
 
$ kubectl --namespace kubernetes-dashboard patch svc kubernetes-dashboard -p '{"spec": {"type": "NodePort"}}'
service/kubernetes-dashboard patched

Для авторизації необхідно надати доступ для перегляду всіх неймспейсів та отримати токен:

$ kubectl create serviceaccount dashboard -n default

$ kubectl create clusterrolebinding dashboard-admin -n default --clusterrole=cluster-admin --serviceaccount=default:dashboard

$ kubectl get secret $(kubectl get serviceaccount dashboard -o jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64 --decode
eyJhbGciOiJSUzI1NiIsImtpZCI6InlWYVBVOERpZVJpVUJxbE9JMy1NaF9q...8G2Qw_vcMIN05UD94-32s7eInP1Q2425PM8A9fKiLnwWvTpJjnHhA4fetZYm8u4c8znxjmDFcN6wVOVMguW2fafoui_aIFPwHLHNw0L0BlopNX8AqrX7QsqctXFiCT6C02Gt4Tj303ioVf2baGt2ENyE1JUasmCwraBRv-94figJ48BDcZ0Q

Після чого можна авторизуватись по порту nodePort:


 

ВАЖЛИВО. Kubernetes - досить молодий продукт, що зазнає значних оновлень з кожним релізом. Як наслідок, останні версії Dashboard можуть дещо інакше встановлюватись, доступ до них може відбуватись по іншому посиланню та ін. У разі помилок ліпше за все звернутись до офіційного репозиторію програми https://github.com/kubernetes/dashboard. Насправді це стосується усієї процедури установки Kubernetes через Kubeadm.

На цьому все. У наступній статті ми познайомимость ближче з одиницями Kubеrnetes та побачимо як вони організовані.

Посилання:
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

Немає коментарів:

Дописати коментар