Kubernetesクラスタのデプロイ

提供: Japanese Ikoula Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

ro:Implementarea unui cluster Kubernetes ru:Развертывание кластера Kubernetes pl:Wdrażanie klastra Kubernetes fr:Deployer un cluster 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 は大規模で急速に成長しているエコシステムです。


この手順では、3ノードのクラスターを迅速かつ簡単に導入することができます。 キューブネーズ（k8sこの手順では、フォワードゾーンの同一ネットワーク内に配置された3台のCentOS 7インスタンスから、3ノードのクラスターを迅速かつ容易に展開することができます。


この3つのインスタンスのうち1つがマスターノード、残りの2つがワーカーノードとなります。簡単にまとめると、マスターノードはKubernetesクラスター（コンテナオーケストレーター）をAPIから管理するノードで、ワーカーノードはポッドやコンテナ（ここではDocker）が実行されるノードです。


ここでは、3台のCentOS 7インスタンスがすでにデプロイされており、後述のコマンドを実行するためにsshアクセスが可能であることを前提とします。


ここでは、この手順の中で例として使用している設定を紹介します。


ノードマスター："k8s-master" / 10.1.1.16
ファーストノードワーカー："k8s-worker01" / 10.1.1.169
2台目のノードワーカー："k8s-worker02" / 10.1.1.87


システム準備とKubernetesインストールのチュートリアル

以下の操作は、すべてのインスタンス（マスターとワーカー）に対して、root（または必要なsudo権限）で行う必要があります。


まず、各インスタンスの/etc/hosts ファイルを入力して、それぞれのホスト名を解決できるようにします（通常、仮想ルーターが DNS リゾルバであるアドバンスドゾーンネットワークでは、すでにそうなっています）。


この例では、3つのインスタンスで次のような/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


以下の3つのコマンドで、ブリッジモジュールとそのための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 kubeletの設定ファイルを編集します。 (/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


設定をリロードし、以下の3つのコマンドで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

注：「--pod-network-cidr=」パラメータで示されるネットワークIP「10.244.0.0/16」は変更しないでください。このパラメータは、CNI Flannelプラグインを使用してポッドのネットワーク部分を管理することを示すためのものです。


クラスタの初期化に成功した場合、このコマンドのリターンは次のようになります。 

[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

note: サイドの初期化コマンドの戻り値である最後のコマンド（"kubeadm join..."）は、後でWorkerインスタンスに実行してクラスタに参加させるために残しておきます。


これで、マスター・インスタンスからクラスタの最初のチェックを行うことができます。

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

Remark : 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」のポッド/コンテナは、クラスタ内のノード数と同じ数だけ存在することがわかります。

第1ポッドの展開

を展開する予定です。 ポッドを、私たちの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

Kubernetesの運用に特化したコンポーネントではないため、「kube-system」とは異なる名前空間でリストの一番上に表示されます。


また、「--all-namespace」パラメータを指定せずに同じコマンドを実行することで、kube-systemの名前空間に特化したポッドを表示しないようにすることも可能です。 

[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ポッドをデプロイして起動しましたが、まだ外部からアクセスできません。外部からアクセスできるようにするには、次のコマンドでサービス（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で利用可能/公開されます。


次のコマンドで、ポッドのフランネルIPと、現在実行中のノードの名前を取得できます。 

[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ポッドのIPは10.244.2.2で、ノードk8s-worker02上で動作しています。


また、以下のコマンドでnginxポッド上でコマンドを実行したり、シェルを開いたりすることもできます（dockerコマンドと非常によく似ています）。 

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


あとは、イコラ・ワンクラウドのネットワーク上にロードバランシングルールを作成し、Webサーバー（nginxポッド）にアクセス／公開するだけです。

- に接続します。 クラウド・イコラ・ワン

- 左の縦長のメニューから「ネットワーク」に進みます。

- Kubernetesインスタンスをデプロイしたネットワークをクリックし、「IPアドレスの表示」をクリックして、NATソースIPを選択し、「設定」タブに移動します。

- ロードバランシング」をクリックし、名前、パブリックポート「80」、プライベートポート「30566」（上記参照）、LBアルゴリズム（ラウンドロビンなど）を選択して、ルールを作成します。


Kubernetes インスタンス


- は、すべてのワーカーインスタンスにチェックを入れます。


kubernetesワーカーインスタンスの確認


ブラウザからWebサーバー/nginxポッドへのアクセスをテストします（LBルールを作成したネットワークのパブリックIP経由）。


お客様のウェブサーバーへのアクセス


nginxポッドがどのノードからでもアクセスできるのは、「kube-proxy」コンポーネントのおかげです。


マスターと2つのワーカーを持つ3ノードの基本的なKubernetesクラスターをデプロイしたところです。

さらに進む

さらに、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://ja-wiki.ikoula.com/index.php?title=Kubernetesクラスタのデプロイ&oldid=11014」から取得