Kubernetes: Создание кластера с помощью kubeadm

Последнее обновление 12.09.2019

Продолжаю серию материалов по kubernetes. Теперь будет рассмотрена процедура создания кластера с использованием утилиты kubdeadm. Обычно для продуктивного развертывания используются такие вещи, как kops или ansible, но для варианта “поиграться\потренироваться” подойдёт и kubeadm.

Перед началом работ, нужно ещё раз убедиться, что все три машины (test-head-1, test-node-1, test-node-2) могут пинговать друг друга.

Для инициализации кластера, на голове test-head-1 нужно выполнить:

kubeadm init --pod-network-cidr=192.168.0.0/16

По умолчанию берется IP-адрес сетевого интерфейса, который связан со шлюзом по умолчанию в ОС. Поэтому команда инициализации была выполнена без параметра –apiserver-advertise-address

Вывод команды получается следующий:

[init] Using Kubernetes version: v1.15.0
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [test-head-1 localhost] and IPs [192.168.10.38 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [test-head-1 localhost] and IPs [192.168.10.38 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [test-head-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.10.38]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 19.507007 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.15" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node test-head-1 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node test-head-1 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: nl9hid.5ik1se5fx4q5v4qo
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following 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:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.10.38:6443 --token nl9hid.5ik1se5fx4q5v4qo \
    --discovery-token-ca-cert-hash sha256:dd411156b3d9eeaa51f640bc5974895701a8340c99aafe89da5b0a0cafbf33bd

Собственно, выше всё написано, что нужно сделать далее:

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

Осталось настроить сеть, чтобы поды могли между собой общаться. Стоит отметить, что сеть не должна пересекаться с уже имеющимися на узлах. В данном вопросе можно использовать различных сетевых провайдеров, например, flannel или calico, которые основаны на CNI (Container Network Interface – некий стандарт для конфигурации сетевых интерфейсов Linux-контейнеров), т.к. этого требуют кластеры, инициализированные с помощью kubeadm. Я выбрал calico и CIDR для подов 192.168.0.0/16, поэтому достаточно выполнить команды ниже без каких-либо изменений. Более подробно тут.

Настройка сети calico :

kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml

Вывод примерно следующий:

[root@test-head-1 ~]# kubectl apply -f https://docs.projectcalico.org/v3.8/manifests/calico.yaml
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
serviceaccount/calico-node created
deployment.apps/calico-kube-controllers created
serviceaccount/calico-kube-controllers created

И наблюдать через watch:

watch -n 2 kubectl get pod --all-namespaces

Выхлоп должен быть такой, где везде статус Running и Ready:

NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-59f54d6bbc-cq98r   1/1     Running   0          4m53s
kube-system   calico-node-htd72                          1/1     Running   0          4m53s
kube-system   calico-node-hvrp4                          1/1     Running   0          4m53s
kube-system   calico-node-sgnrp                          1/1     Running   0          4m53s
kube-system   coredns-5c98db65d4-c7nbc                   1/1     Running   0          12m
kube-system   coredns-5c98db65d4-f9nr8                   1/1     Running   0          12m
kube-system   etcd-test-head-1                           1/1     Running   0          11m
kube-system   kube-apiserver-test-head-1                 1/1     Running   0          11m
kube-system   kube-controller-manager-test-head-1        1/1     Running   0          11m
kube-system   kube-proxy-j9kkv                           1/1     Running   0          12m
kube-system   kube-proxy-jkhts                           1/1     Running   0          7m58s
kube-system   kube-proxy-qwbls                           1/1     Running   0          7m48s
kube-system   kube-scheduler-test-head-1                 1/1     Running   0          11m

Если есть ошибка вида ErrImagePull или CrashLoopBackOff, то наверняка дело в firewalld, который мне пришлось отключить, т.к. не стал разбираться, что ему нужно было открыть:

systemctl stop firewalld

Через некоторое время (плюс-минус 2-3 минуты) поле STATUS меняется и ошибка рассасывается.

А теперь уже можно присоединить ноды, прописав указанный токен из результата выполнения команды инициализации кластера. Выполнять на test-node-1 и test-node-2:

kubeadm join 192.168.10.38:6443 --token nl9hid.5ik1se5fx4q5v4qo \
    --discovery-token-ca-cert-hash sha256:dd411156b3d9eeaa51f640bc5974895701a8340c99aafe89da5b0a0cafbf33bd

И проверить уже на голове, что ноды подцепились, а их статус NotReady:

kubectl get nodes

NAME          STATUS     ROLES    AGE    VERSION
test-head-1   NotReady   master   5m3s   v1.15.0
test-node-1   NotReady   <none>   15s    v1.15.0
test-node-2   NotReady   <none>   5s     v1.15.0

В случае возникновения каких-либо проблем с подключением, в первую очередь стоит проверить firewalld.

Проверить список всех нод:

kubectl get nodes -o wide
NAME          STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION               CONTAINER-RUNTIME
test-head-1   Ready    master   16m   v1.15.0   192.168.10.38   <none>        CentOS Linux 7 (Core)   3.10.0-957.21.3.el7.x86_64   docker://1.13.1
test-node-1   Ready    <none>   11m   v1.15.0   192.168.10.39   <none>        CentOS Linux 7 (Core)   3.10.0-957.21.3.el7.x86_64   docker://1.13.1
test-node-2   Ready    <none>   11m   v1.15.0   192.168.10.37   <none>        CentOS Linux 7 (Core)   3.10.0-957.21.3.el7.x86_64   docker://1.13.1

Проверить список всех подов:

kubectl get pod --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-59f54d6bbc-cq98r   1/1     Running   0          116m
kube-system   calico-node-htd72                          1/1     Running   0          116m
kube-system   calico-node-hvrp4                          1/1     Running   31         116m
kube-system   calico-node-sgnrp                          1/1     Running   0          116m
kube-system   coredns-5c98db65d4-c7nbc                   1/1     Running   0          124m
kube-system   coredns-5c98db65d4-f9nr8                   1/1     Running   0          124m
kube-system   etcd-test-head-1                           1/1     Running   0          123m
kube-system   kube-apiserver-test-head-1                 1/1     Running   0          123m
kube-system   kube-controller-manager-test-head-1        1/1     Running   0          123m
kube-system   kube-proxy-j9kkv                           1/1     Running   0          124m
kube-system   kube-proxy-jkhts                           1/1     Running   0          119m
kube-system   kube-proxy-qwbls                           1/1     Running   0          119m
kube-system   kube-scheduler-test-head-1                 1/1     Running   0          123m

Проверить состояние компонентов кластера:

kubectl get componentstatuses
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-0               Healthy   {"health":"true"}

Проверить состояние кластера:

kubectl cluster-info
Kubernetes master is running at https://192.168.10.38:6443
KubeDNS is running at https://192.168.10.38:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

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

На этом первоначальную настройку кластера Kubernetes можно считать законченной.

Ваш комментарий будет первым

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *