Как да инсталирате Kubernetes с помощта на Kubeadm

Kubernetes беше представен в по-ранна статия „Първи стъпки с Kubernetes на Amazon Web Services (AWS)“. Kubernetes също беше обсъден в друга статия, „Използване на Kubernetes (K8s) на IBM Bluemix“. Kubernetes може да бъде инсталиран на гол метал на почти всяка ОС, включително Fedora, CentOS, Ubuntu и CoreOS за целите на разработката.

Проблемът

Инсталацията на Kubernetes върху гол метал включва изпълнение на няколко команди за настройка на главен възел, работни възли, под мрежа и др.

Решението

Kubernetes 1.4 въвежда нов инструмент, наречен kubeadm за стартиране на клъстер Kubernetes. kubeadm зарежда Kubernetes клъстер с две команди. След инсталиране на Docker, kubectl и kubelet, главният възел може да бъде стартиран с kubeadm init и работни възли, добавени с kubeadm join .

В тази статия ще използваме следната процедура, за да инсталираме и стартираме Kubernetes клъстер и впоследствие да тестваме клъстера:

Стартирайте три нови екземпляра на Ubuntu на Amazon EC2.
На всички екземпляри на Ubuntu инсталирайте Docker, kubeadm, kubectl и kubelet.
От един от екземплярите на Ubuntu инициализирайте Kubernetes Cluster Master със следната команда:
```
kubeadm init
```
Прилагане на мрежовите правила на Calico Pod kubeadm/calico.yaml .
Присъединете се към другите два екземпляра (възли) на Ubuntu с master с kubeadm join --token= .
На главния три възела се изброяват с „kubectl get nodes“.

Изпълнете приложение на master:

kubectl -s http://localhost:8080 run nginx
   --image=nginx
   --replicas=3 --port=80

Избройте шушулките:
```
kubectl get pods -o wide
```
Деинсталирайте клъстера Kubernetes.
```
kubeadm reset
```

Тази статия има следните раздели:

Настройка на средата
Инсталиране на Docker, kubeadm, kubectl и kubelet на всеки хост
Инициализиране на главния
Инсталиране на мрежата Calico Pod
Присъединяване на възли към клъстера
Инсталиране на примерно приложение
Деинсталиране на клъстера
Ограничения
По-нататъшни разработки в kubeadm
Заключение

Настройка на средата

kubeadm инструментът изисква следните машини, работещи на една от Ubuntu 16.04+, HypriotOS v1.0.1+ или CentOS 7, работещи на тях.

Една машина за главния възел
Една или повече машини за работните възли

Необходими са поне 1 GB RAM на всяка от машините. Използвахме три Ubuntu машини, работещи на Amazon EC2, за да стартираме клъстер с един главен възел и два работни възела. Трите Ubuntu машини са показани на Фигура 1.

Фигура 1: Ubuntu машини

Инсталиране на Docker, kubeadm, kubectl и kubelet на всеки хост

В този раздел ще инсталираме Docker, kubelet, kubectl и kubeadm на всяка от трите машини. Инсталираните компоненти са разгледани в Таблица 1.

Компонента	Описание
Docker	Времето за изпълнение на контейнера. Препоръчва се версия 1.11.2 и v1.10.3 и v1.12.1 също са добре. Изисква се на всички машини в клъстера.
kubelet	Основният компонент на Kubernetes, който работи на всички машини в клъстера. Стартира контейнери и шушулки. Изисква се на всички машини в клъстера.
kubectl	Инструментът на командния ред за управление на клъстер. Изисква се само на главния възел, но е полезен, ако е инсталиран на всички възли.
kubeadm	Инструментът за стартиране на клъстер. Изисква се на всички машини в клъстера.

Таблица 1: Компоненти за инсталиране

Получете публичния IP адрес на всяка от трите машини и влезте в SSH на всяка от машините:

ssh -i "docker.pem" [email protected]
ssh -i "docker.pem" [email protected]
ssh -i "docker.pem" [email protected]

Командите за инсталиране на двоичните файлове трябва да се изпълняват като root; следователно, настройте потребителя на root.

sudo su -

Изпълнете следните команди на всяка от машините:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg
   | apt-key add -
cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

Първата команда изтегля необходимите пакети за Kubernetes, както е показано в изхода на фигура 2.

Фигура 2: Изтегляне на пакети за Kubernetes

Командата 2 изтегля списъците с пакети от хранилищата и ги актуализира с най-новите версии на пакетите.

apt-get update

Резултатът е показан на фигура 3.

Фигура 3: Актуализиране на пакети на хранилището

След това инсталирайте Docker:

# Install docker if you don't have it already.
apt-get install -y docker.io

Docker се инсталира, както е показано в командния изход на фигура 4.

Фигура 4: Инсталиране на Docker

И впоследствие инсталирайте kubelet (основен компонент на Kubernetes), kubeadm (инструмент за стартиране), kubectl (инструмент за управление на клъстер) и kubernetes-cni (мрежов плъгин):

apt-get install -y kubelet kubeadm kubectl kubernetes-cni

Резултатът от предходните команди е показан на Фигура 5.

Фигура 5: Инсталиране на kubelet, kubeadm, kubectln и kubernetes-cni

Инициализиране на главния

След това инициализирайте главния, на който се изпълняват etcd базата данни и API сървърът. Kubelet стартира Pods да изпълнява тези компоненти. Изпълнете следната команда, която автоматично открива IP адресите:

kubeadm init

Както е показано в изхода на командата, първо се изпълняват някои проверки преди полета, за да се потвърди състоянието на системата. Впоследствие се генерира главен/токен, който трябва да се използва като ключ за взаимно удостоверяване за работни възли, които искат да се присъединят към клъстера. След това се генерират самоподписан ключ и сертификат на сертифициращ орган, за да се предоставят самоличности на всеки от възлите в клъстера за комуникация с клиентите. Създават се API сървърен ключ и сертификат за API сървъра за комуникация с клиентите. util/kubeconfig се създава файл за kubelet да се свърже с API сървъра и друг util/kubeconfig файлът се създава за администрацията. Впоследствие се създава клиентската конфигурация на API. Резултатът от kubeadm init командата е показана на фигура 6.

Фигура 6: Изпълнява се kubeadm init

Всички компоненти на контролната равнина са готови. Първият възел става готов и се прави тестово внедряване. Основните компоненти на добавките kube-discovery, kube-proxy и kube-dns също се създават, както е показано в изхода на командата на фигура 7. Главният Kubernetes се инициализира успешно. Генерира се команда със следния синтаксис; трябва да се изпълнява на машини (възли), които трябва да се присъединят към клъстера.

kubeadm join -token=<token> <IP Address of the master node>

Предходната команда трябва да бъде копирана и запазена за последваща употреба на работни възли.

Фигура 7: Master Kubernetes е инициализиран

По подразбиране главните възли не са насрочени и са направени така, като се използва „посветеното“ замърсяване. Главният възел може да бъде насрочен със следната команда:

kubectl taint nodes --all dedicated-

kubeadm командата поддържа някои други опции (вижте Таблица 2), които не трябваше да използваме, но може да се използва за отмяна на командата по подразбиране.

Команден параметър	Описание	По подразбиране
`--skip-preflight-checks`	Пропуска проверките преди полета	Извършват се предполетни проверки
`--use-kubernetes-version`	Задава версията на Kubernetes за използване	v1.5.1
`--api-advertise-addresses`	Командата kubeadm init автоматично открива и използва IP адреса на мрежовия интерфейс по подразбиране и го използва за генериране на сертификати за API сървъра. Този конфигурационен параметър може да се използва за отмяна на по подразбиране с един или повече IP адреси, на които API сървърът трябва да бъде валидиран.	Автоматично открива
`--api-external-dns-names`	Този конфигурационен параметър може да се използва за отмяна на мрежовия интерфейс по подразбиране с едно или повече имена на хостове, на които API сървърът трябва да бъде валидиран. Трябва да се използва само един от IP адрес/и или външно DNS име/и.
`--cloud-provider`	Определя доставчик на облак. Облачният мениджър поддържа “aws”, “azure”, “cloudstack”, “gce”, “mesos”, “openstack”, “ovirt”, “rackspace” и “vsphere”. Конфигурацията на облачния доставчик може да бъде предоставена във файла /etc/kubernetes/cloud-config. Използването на доставчик на облак също има предимството да използва постоянни томове и балансиране на натоварването.	Няма автоматично откриване на доставчик на облак
`--pod-network-cidr`	Разпределя мрежови диапазони (CIDR) към всеки възел и е полезен за определени мрежови решения, включително доставчици на фланел и облак.
`--service-cidr`	Отменя подмрежата, която Kubernetes използва за присвояване на IP адреси на Pods. `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` също трябва да бъде променено.	10.96.0.0/12
`--service-dns-domain`	Отменя суфикса на DNS име за присвояване на услуги с DNS имена; има формат `..svc.cluster.local` . `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` също трябва да бъде променено.	`cluster.local`
`--токен`	Указва токена, който да се използва за взаимно удостоверяване между главния и възлите, присъединяващи се към клъстера.	Автоматично генериран

Таблица 2: Опции на командата Kubeadm

Инсталиране на мрежата Calico Pod

За да могат Pods да комуникират помежду си, трябва да бъде инсталирана мрежова добавка на Pod. Calico предоставя конфигурация за инсталиране, хоствана от kubeadm, под формата на ConfigMap на http://docs.projectcalico.org/master/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml, който ще използваме в този раздел, за да инсталираме Pod мрежа. Изпълнете следната команда на главния възел, за да инсталирате Pod мрежата:

kubectl apply -f
   http://docs.projectcalico.org/master/getting-started/
   kubernetes/installation/hosted/kubeadm/calico.yaml

Друга възможност е да изтеглите calico.yaml и копирайте в главния възел:

scp -i "docker.pem" calico.yaml [email protected]:~

След това изпълнете следната команда:

kubectl apply -f calico.yaml

Calico и клъстер с един възел etcd се инсталират, както е показано на фигура 8.

Фигура 8: Инсталиране на Calico Policy

След това избройте всички модули във всички пространства от имена на Kubernetes.

kubectl get pods --all-namespaces

kube-dns Pod трябва да работи, както е изброено на фигура 9.

Фигура 9: Изброяване на модули във всички пространства от имена

Присъединяване на възли към клъстера

В този раздел ще присъединим работни възли към клъстера с помощта на kubeadm join команда, която има следния синтаксис:

kubeadm join --token=<token> <master-ip>

По избор, kubeadm join командата може да се изпълнява с --skip-preflight-checks опция за пропускане на предварителната валидация.

Присъединяването kubeadm командата използва предоставения токен, за да комуникира с API сървъра и да получи сертификата на коренния CA и създава двойка локални ключове. Впоследствие заявка за подписване на сертификат (CSR) се изпраща до API сървъра за подписване и локалният kubelet се конфигурира да се свързва с API сървъра.

Изпълнете kubeadm join команда, копирана от изхода на kubeadm init команда на всяка от машините на Ubuntu, които трябва да се присъединят към клъстера.

Първо, влезте в SSH в екземпляра/ите на Ubuntu:

ssh -i "docker.pem" [email protected]

ssh -i "docker.pem" [email protected]

След това стартирайте kubeadm join команда. Първо се извършват някои проверки преди полета. Предоставеният токен е валидиран. След това се използва откриване на възли. Създава се клиент за откриване на информация за клъстер и се изисква информация от сървъра на API. Получава се информационен обект за клъстер и подписът се проверява с помощта на дадения токен. Установено е, че подписът и съдържанието на информацията за клъстера са валидни и откриването на възела е завършено. Впоследствие се извършва зареждане на възел, при което крайните точки на API https://10.0.0.129:6443 се използват за установяване на връзка. Впоследствие се прави заявка за подписване на сертификат (csr), като се използва API клиент, за да се получи уникален сертификат за възела. След като се получи подписан сертификат от API сървъра, се генерира конфигурационен файл на kubelet. Съобщението „Присъединяването на възел е завършено“, посочено на фигура 10, показва, че възелът се е присъединил към клъстера.

Фигура 10: Присъединяване на възел към клъстера

По същия начин изпълнете същата команда на другата Ubuntu машина. Другият възел също се присъединява към клъстера, както е показано от изхода на Фигура 11.

Фигура 11: Присъединяване на втори възел към клъстер

На главния възел изпълнете следната команда, за да изброите възлите:

kubectl get nodes

Главният възел и двата работни възела трябва да бъдат изброени, както е показано на Фигура 12.

Фигура 12: Изброяване на възли на клъстер на Kubernetes

Инсталиране на примерно приложение

След това ще тестваме клъстера. Изпълнете следната команда, за да стартирате nginx -базиран Pod клъстер, състоящ се от три реплики:

kubectl -s http://localhost:8080 run nginx --image=nginx
   --replicas=3 --port=80

Избройте внедряванията:

kubectl get deployments

Избройте подовете за целия клъстер:

kubectl get pods -o wide

Изложете внедряването като услуга от тип LoadBalancer :

kubectl expose deployment nginx --port=80 --type=LoadBalancer

Избройте услугите:

kubectl get services

Резултатът от предходните команди показва nginx разгръщането беше създадено и трите Pods преминават през двата работни възела в клъстера. Създава се и услуга, наречена „nginx“, както е показано на Фигура 13.

Фигура 13: Изпълнение на клъстер nginx Pod

Копирайте IP адреса на клъстера на услугата. Изпълнете командата curl, за да извикате услугата:

curl 10.0.0.99

HTML маркирането от услугата се извежда, както е показано на Фигура 14.

Фигура 14: Извикване на услугата nginx

Деинсталиране на клъстера

За да деинсталирате клъстера, инсталиран от kubeadm, изпълнете следната команда:

kubeadm reset

Клъстерът се деинсталира, както е показано на Фигура 15.

Фигура 15: Деинсталиране/нулиране на клъстер Kubernetes

Ограничения

kubeadm има няколко ограничения и се препоръчва само за разработка. Ограниченията на kubeadm са както следва;

Поддържат се само няколко ОС:Ubuntu 16.04+, CentOS 7, HypriotOS v1.0.1+.
Не е подходящ за производствена употреба.
Интегрирането на доставчици на облак е експериментално.
Създава се клъстер само с един главен обект с една etcd база данни. Високата наличност не се поддържа, което означава, че главният елемент е единична точка на отказ (SPOF).
Функционалността HostPort и HostIP не се поддържат.
Някои други известни проблеми, когато kubeadm се използва с RHEL/CentOS 7 и VirtualBox.

По-нататъшни разработки в kubeadm

kubeadm е в алфа версия на Kubernetes v 1.5 и е в бета версия след Kubernetes 1.6. Продължават малки корекции и подобрения, направени в kubeadm с всяка нова версия на Kubernetes:

С Kubernetes 1.7 промените в клъстерните вътрешни ресурси, инсталирани с kubeadm, се презаписват при надграждане от v 1.6 до v 1.7.
В Kubernetes 1.8, токенът за стартиране по подразбиране, създаден с kubeadm init става невалиден и се изтрива след 24 часа след създаването, за да се ограничи разкриването на ценните идентификационни данни. Присъединяването kubeadm командата делегира стартирането на TLS на самия kubelet, вместо да внедрява отново процеса. Зареждането KubeConfig файлът се записва в /etc/kubernetes/bootstrap-kubelet-conf с kubeadm join .

Заключение

В тази статия използвахме функцията на инструмента kubeadm, налична след Kubernetes v1.4, за да стартираме Kubernetes клъстер. Първо се инсталират необходимите двоични файлове за Docker, kubectl, kubelet и kubeadm. Впоследствие, kubeadm init командата се използва за инициализиране на главния възел в клъстера. И накрая, кубеадм присъединяването командата се използва за присъединяване на работни възли към клъстера. Примерен nginx приложението се стартира за тестване на клъстера.