Способів установки 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:
Перейдемо до установки 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
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/
Немає коментарів:
Дописати коментар