Развертывание кластера Kubernetes: различия между версиями

Материал из Ru Ikoula wiki
Jump to navigation Jump to search
(Новая страница: «<span data-link_translate_fr_title="Deployer un cluster Kubernetes" data-link_translate_fr_url="Deployer un cluster Kubernetes"></span>:fr:Deployer un cluster...»)
(нет различий)

Версия 16:00, 29 июля 2021

fr:Deployer un cluster Kubernetes
Эта статья является результатом автоматического перевода, выполняемого программного обеспечения. Вы можете посмотреть исходный статьи здесь.

pl:Wdrażanie klastra Kubernetes ja:Kubernetesクラスタのデプロイ zh:部署一个Kubernetes集群 de:Bereitstellen eines Kubernetes-Clusters nl:Een Kubernetes cluster implementeren pt:Implantação de um aglomerado Kubernetes es:Despliegue de un clúster Kubernetes en:Deploying a Kubernetes cluster it:Configurare un cluster Kubernetes fr:Deployer un cluster Kubernetes


Что такое Kubernetes?

Kubernetes это платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами. Он поддерживает декларативное написание конфигурации, но также и автоматизацию. Kubernetes - это большая и быстро развивающаяся экосистема.


Эта процедура позволит вам быстро и легко развернуть кластер с тремя узлами Kubernetes (k8s) Эта процедура позволит вам быстро и легко развернуть трехузловой кластер из трех экземпляров CentOS 7, развернутых в одной сети в передовой зоне.


Один из этих трех экземпляров будет нашим главным узлом, а два других - рабочими узлами. Если говорить кратко, то главный узел - это узел, с которого мы управляем кластером Kubernetes (контейнерным оркестратором) из его API, а рабочие узлы - это узлы, на которых будут запускаться капсулы или контейнеры (в нашем случае Docker).


Мы предположим, что ваши 3 экземпляра CentOS 7 уже развернуты, и у вас есть доступ по ssh к ним, чтобы выполнить команды, которые будут приведены ниже.


Вот конфигурация, которую мы имеем в нашем примере и которая будет использоваться в качестве примера на протяжении всей этой процедуры:


Ведущий узел: "k8s-master" / 10.1.1.16
Первый рабочий узел: "k8s-worker01" / 10.1.1.169
Второй рабочий узел: "k8s-worker02" / 10.1.1.87


Руководство по подготовке системы и установке Kubernetes

Следующие действия должны быть выполнены на всех экземплярах (главном и рабочих) от имени root (или с необходимыми правами sudo).


Начните с заполнения файла /etc/hosts на каждом из ваших экземпляров, чтобы они могли разрешать соответствующие имена хостов (обычно это уже происходит в сети с расширенной зоной, где виртуальный маршрутизатор является DNS-резольвером).


В нашем примере это дает следующий файл /etc/hosts на наших трех экземплярах (адаптируйте его с именем и ip ваших экземпляров): 

cat /etc/hosts
127.0.0.1   localhost
::1         localhost

10.1.1.16 k8s-master
10.1.1.169 k8s-worker01
10.1.1.87 k8s-worker02


Включите модуль моста и правила iptables для него с помощью следующих трех команд: 

modprobe bridge
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p /etc/sysctl.conf


Добавьте репозиторий YUM Docker : 

cat <<EOF > /etc/yum.repos.d/docker.repo
[docker-ce-stable]
name=Docker CE Stable - \$basearch
baseurl=https://download.docker.com/linux/centos/7/\$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
EOF


Добавьте репозиторий YUM Kubernetes : 

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF


Установите Docker : 

yum install -y docker-ce


Затем установите необходимые пакеты Kubernetes: 

yum install -y kubeadm kubelet kubectl


Отредактируйте конфигурационный файл кублета systemd (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) конфигурационного файла добавить следующую строку в раздел "[Service]": 

Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"


такой, что : 

cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
*Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs"*
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/sysconfig/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS


Перезагрузите конфигурацию, включите, а затем запустите службы docker и kubelet с помощью следующих трех команд:


systemctl daemon-reload systemctl enable docker kubelet systemctl start docker kubelet </syntaxhighlight>


Отключите системный своп (kubelet не поддерживает своп-память, вы получите ошибку во время предполетных проверок при инициализации кластера через kubeadms, если вы не отключите его): 

swapoff -a


Пожалуйста, не забудьте также закомментировать/удалить строку подкачки в файле /etc/fstab каждого из ваших экземпляров, например : 

#/dev/mapper/vg01-swap  swap            swap    defaults                0       0

Инициализация кластера Kubernetes

Следующие действия должны выполняться только на главном экземпляре узла


Запустите инициализацию кластера Kubernetes с помощью приведенной ниже команды, позаботившись о том, чтобы изменить значение параметра "--apiserver-advertise-address=" на ip-адрес вашего основного экземпляра. 

kubeadm init --apiserver-advertise-address=<ip de votre instance master> --pod-network-cidr=10.244.0.0/16

Примечание: Пожалуйста, не изменяйте сетевой ip "10.244.0.0/16", указанный в параметре "--pod-network-cidr=", поскольку этот параметр позволяет нам указать, что мы собираемся использовать плагин CNI Flannel для управления сетевой частью наших pods.


Вот как должно выглядеть возвращение этой команды при успешной инициализации кластера: 

[root@k8s-master ~]# kubeadm init --apiserver-advertise-address=10.1.1.16 --pod-network-cidr=10.244.0.0/16
[init] using Kubernetes version: v1.12.2
[preflight] running pre-flight checks
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master.cs437cloud.internal kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.1.1.16]
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [k8s-master.cs437cloud.internal localhost] and IPs [10.1.1.16 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[certificates] Generated sa key and public key.
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] this might take a minute or longer if the control plane images have to be pulled
[apiclient] All control plane components are healthy after 32.502898 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.12" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master.cs437cloud.internal as master by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-master.cs437cloud.internal" as an annotation
[bootstraptoken] using token: e83pes.u3igpccj2metetu8
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes master 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/

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

  kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c


Мы выполняем запрошенные операции, чтобы завершить инициализацию нашего кластера:


Мы создаем каталог и файл конфигурации в каталоге нашего пользователя (в нашем случае root): 

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config


Мы развертываем сеть pod Flannel для нашего кластера: 

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created

Примечание: мы сохраним последнюю команду, полученную в результате возврата команды инициализации стороны ("kubeadm join..."), чтобы позже запустить ее на наших рабочих экземплярах для присоединения их к нашему кластеру.


Теперь мы можем выполнить первые проверки нашего кластера с главного экземпляра:

Введите команду "kubectl get nodes", чтобы проверить узлы, присутствующие в настоящее время в вашем кластере: 

[root@k8s-master ~]# kubectl get nodes
NAME                             STATUS   ROLES    AGE   VERSION
k8s-master.cs437cloud.internal   Ready    master   41m   v1.12.2

Примечание: в настоящее время существует только ваш главный узел, что является нормальным, поскольку мы еще не добавили другие узлы в кластер.


Введите команду "kubectl get pods --all-namespaces" для проверки стручков/контейнеров, присутствующих в кластере: 

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
kube-system   coredns-576cbf47c7-fwxj9                                 1/1     Running   0          41m
kube-system   coredns-576cbf47c7-t86s9                                 1/1     Running   0          41m
kube-system   etcd-k8s-master.cs437cloud.internal                      1/1     Running   0          41m
kube-system   kube-apiserver-k8s-master.cs437cloud.internal            1/1     Running   0          41m
kube-system   kube-controller-manager-k8s-master.cs437cloud.internal   1/1     Running   0          41m
kube-system   kube-flannel-ds-amd64-wcm7v                              1/1     Running   0          84s
kube-system   kube-proxy-h94bs                                         1/1     Running   0          41m
kube-system   kube-scheduler-k8s-master.cs437cloud.internal            1/1     Running   0          40m

Примечание: Есть только поды, соответствующие компонентам Kubernetes, необходимым для нашего главного узла (kube-apiserver, etcd, kube-scheduler и т.д.).


Мы можем проверить состояние этих компонентов с помощью следующей команды: 

[root@k8s-master ~]# kubectl get cs
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}

Добавление рабочих узлов в кластер

Действия, которые должны выполняться только на рабочих экземплярах/узлах

На каждом из рабочих экземпляров (не делайте этого на главном экземпляре) выполните команду "kubeadm join ...", указанную в конце инициализации кластера выше: 

[root@k8s-worker01 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
        [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker01.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

[root@k8s-worker02 ~]# kubeadm join 10.1.1.16:6443 --token e83pes.u3igpccj2metetu8 --discovery-token-ca-cert-hash sha256:7ea9169bc5ac77b3a2ec37e5129006d9a895ce040e306f3093ce77e7422f7f1c
[preflight] running pre-flight checks
        [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs ip_vs_rr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.1.1.16:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.1.1.16:6443"
[discovery] Requesting info from "https://10.1.1.16:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.1.1.16:6443"
[discovery] Successfully established connection with API Server "10.1.1.16:6443"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "k8s-worker02.cs437cloud.internal" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

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

Действия, выполняемые с ведущего экземпляра/узла


Проверьте, что ваши рабочие узлы были добавлены в кластер, повторно выполнив команду "kubectl get nodes": 

[root@k8s-master ~]# kubectl get nodes
NAME                               STATUS   ROLES    AGE    VERSION
k8s-master.cs437cloud.internal     Ready    master   46m    v1.12.2
k8s-worker01.cs437cloud.internal   Ready    <none>   103s   v1.12.2
k8s-worker02.cs437cloud.internal   Ready    <none>   48s    v1.12.2

Примечание: Мы видим два рабочих узла (k8s-worker01 и k8s-worker02), поэтому они были добавлены в наш кластер.


Теперь давайте снова выполним команду "kubectl get pods --all-namespaces": 

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
kube-system   coredns-576cbf47c7-fwxj9                                 1/1     Running   0          46m
kube-system   coredns-576cbf47c7-t86s9                                 1/1     Running   0          46m
kube-system   etcd-k8s-master.cs437cloud.internal                      1/1     Running   0          46m
kube-system   kube-apiserver-k8s-master.cs437cloud.internal            1/1     Running   0          46m
kube-system   kube-controller-manager-k8s-master.cs437cloud.internal   1/1     Running   0          46m
kube-system   kube-flannel-ds-amd64-724nl                              1/1     Running   0          2m6s
kube-system   kube-flannel-ds-amd64-wcm7v                              1/1     Running   0          6m31s
kube-system   kube-flannel-ds-amd64-z7mwg                              1/1     Running   3          70s
kube-system   kube-proxy-8r7wg                                         1/1     Running   0          2m6s
kube-system   kube-proxy-h94bs                                         1/1     Running   0          46m
kube-system   kube-proxy-m2f5r                                         1/1     Running   0          70s
kube-system   kube-scheduler-k8s-master.cs437cloud.internal            1/1     Running   0          46m

Примечание: Вы можете видеть, что существует столько подсов/контейнеров "kube-flannel" и "kube-proxy", сколько узлов в нашем кластере.

Развертывание первой капсулы

Мы развернем наш первый под в нашем кластере Kubernetes.


Для простоты мы решили развернуть стручок (без реплик) с именем "nginx" и с использованием образа "nginx": 

[root@k8s-master ~]# kubectl create deployment nginx --image=nginx
deployment.apps/nginx created


Если мы проверим, то эта команда появится в конце команды, перечисляющей стручки нашего кластера: 

[root@k8s-master ~]# kubectl get pods --all-namespaces
NAMESPACE     NAME                                                     READY   STATUS    RESTARTS   AGE
default       nginx-55bd7c9fd-5bghl                                    1/1     Running   0          104s
kube-system   coredns-576cbf47c7-fwxj9                                 1/1     Running   0          57m
kube-system   coredns-576cbf47c7-t86s9                                 1/1     Running   0          57m
kube-system   etcd-k8s-master.cs437cloud.internal                      1/1     Running   0          57m
kube-system   kube-apiserver-k8s-master.cs437cloud.internal            1/1     Running   0          57m
kube-system   kube-controller-manager-k8s-master.cs437cloud.internal   1/1     Running   0          57m
kube-system   kube-flannel-ds-amd64-724nl                              1/1     Running   0          13m
kube-system   kube-flannel-ds-amd64-wcm7v                              1/1     Running   0          17m
kube-system   kube-flannel-ds-amd64-z7mwg                              1/1     Running   3          12m
kube-system   kube-proxy-8r7wg                                         1/1     Running   0          13m
kube-system   kube-proxy-h94bs                                         1/1     Running   0          57m
kube-system   kube-proxy-m2f5r                                         1/1     Running   0          12m
kube-system   kube-scheduler-k8s-master.cs437cloud.internal            1/1     Running   0          57m

Он отображается в верхней части списка в другом пространстве имен, отличном от "kube-system", поскольку не является компонентом, специфичным для работы Kubernetes.


Также можно избежать отображения стручков, специфичных для пространства имен kube-system, выполнив эту же команду без параметра "--all-namespace": 

[root@k8s-master ~]# kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
nginx-55bd7c9fd-vs4fq     1/1     Running   0          3d2h


Чтобы отобразить этикетки : 

[root@k8s-master ~]# kubectl get pods --show-labels
NAME                      READY   STATUS    RESTARTS   AGE    LABELS
nginx-55bd7c9fd-ckltn     1/1     Running   0          8m2s   app=nginx,pod-template-hash=55bd7c9fd


Мы также можем проверить наши развертывания с помощью следующей команды: 

[root@k8s-master ~]# kubectl get deployments
NAME    DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx   1         1         1            1           93m


Итак, у нас есть развернутый и запущенный nginx pod, но он еще не доступен извне. Чтобы сделать его доступным извне, нам нужно раскрыть порт нашего pod, создав сервис (типа NodePort) с помощью следующей команды: 

[root@k8s-master ~]# kubectl create service nodeport nginx --tcp=80:80
service/nginx created


Таким образом, создается наша служба: 

[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        147m
nginx        NodePort    10.108.251.178   <none>        80:30566/TCP   20s

Примечание: Он прослушивает порт 80/tcp и будет доступен/открыт извне на порту 30566/tcp.


Мы можем получить flannel ip нашего pod и имя узла, на котором он в данный момент запущен, с помощью следующей команды: 

[root@k8s-master ~]# kubectl get pods --selector="app=nginx" --output=wide
NAME                    READY   STATUS    RESTARTS   AGE    IP           NODE                               NOMINATED NODE
nginx-55bd7c9fd-vs4fq   1/1     Running   0          174m   10.244.2.2   k8s-worker02.cs437cloud.internal   <none>

Здесь наш nginx pod имеет ip 10.244.2.2 и запущен на нашем узле k8s-worker02.


Вы также можете просто запустить команду или открыть оболочку на нашем nginx pod с помощью следующей команды (очень похожей на команду docker): 

[root@k8s-master ~]# kubectl exec -it nginx-55bd7c9fd-vs4fq -- /bin/bash
root@nginx-55bd7c9fd-vs4fq:/#


Все, что вам нужно сделать, это создать правило балансировки нагрузки в вашей сети Ikoula One Cloud для доступа / обнародования вашего веб-сервера (nginx pod):

- Подключитесь к Облако Икула Один

- перейдите в раздел "Сеть" в левом вертикальном меню

- щелкните на сети, в которой вы развернули свои экземпляры Kubernetes, затем на "View IP Addresses" и на вашем IP-адресе источника NAT и перейдите на вкладку "Configuration".

- нажмите на "Load Balancing" и создайте свое правило, указав имя, публичный порт "80" в нашем случае, частный порт "30566" в нашем случае (см. выше), выбрав алгоритм LB (например, round-robin), такой как :


Инстанция Kubernetes


- отметьте все рабочие экземпляры:


Проверьте рабочие экземпляры kubernetes


Протестируйте доступ к вашему веб-серверу / nginx pod из браузера (через публичный ip вашей сети, на котором вы создали правило LB):


Доступ к вашему веб-серверу


Тот факт, что к вашему nginx pod можно получить доступ с любого из ваших узлов, возможен благодаря компоненту "kube-proxy", который отвечает за направление соединений к узлу (узлам), на котором он запущен (в случае реплик).


Итак, вы только что развернули базовый кластер Kubernetes из 3 узлов с главным и двумя рабочими.

Идти дальше

Вы можете пойти дальше, развернув приборную панель Kubernetes или создав постоянные тома для ваших стручков, увеличив количество рабочих узлов или даже избыточно назначив роль мастера для обеспечения высокой доступности или выделив узлы для определенных компонентов, таких как Etcd, например.


Вот несколько полезных ссылок:


https://kubernetes.io/docs/reference/kubectl/cheatsheet/

https://kubernetes.io/docs/reference/kubectl/docker-cli-to-kubectl/

https://kubernetes.io/docs/concepts/storage/volumes/

https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/

https://kubernetes.io/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/

Источник — https://ru-wiki.ikoula.com/index.php?title=Развертывание_кластера_Kubernetes&oldid=9748