Kubernetes学習の道(一)のKubeadm配備K 8 Sクラスタ
一週間でどのくらいの読書量を超えますか??51に勉強のブログを書き直したかどうか、鉄さんの支持はありますか?
kubeadmを使用してクラスタを配置する
ノード名
ipアドレス
配置の説明
Podセグメント
サービスセグメント
システムの説明
k8s-master
192.168.56.11
docker、kubeadm、kubectl、kubelet
Centos 7.4
k8s-node01
192.168.56.12
docker、kubeadm、kubelet
Centos 7.4
k8s-node02
192.168.56.13
docker、kubeadm、kubelet
Centos 7.4
1、kubernetesソースの構成
ソースをnode 01ノードとnode 02ノードにコピー
2、Masterノードインストールdocker、kubelet、kubeadm、コマンドラインツールkubectl
dockerを起動するには、海外の倉庫でダウンロードできないため、ミラーファイルを自動的にdocker倉庫に依存するミラーファイルをダウンロードする必要があります.kubeadmは、ローカルのプライベート倉庫でミラーファイルを取得することもできます.
3、ミラーをダウンロードしておく
4、kubernetesのMasterノードを配置する
これでKubernetes Masterの導入が完了します.このプロセスには数分かかります.デプロイが完了すると、kubeadmは次のコマンドを生成します.
このkubeadm joinコマンドは、このMasterノードにワークノード(Worker)を追加するためのコマンドで、後でワークノードを配備する際に使用され、記録する必要があります.
また、kubeadmは、Kubernetesクラスタを初めて使用するために必要な構成コマンドを提示します.
これらのコマンドを構成する必要があるのは、Kubernetesクラスタがデフォルトで暗号化された方法でアクセスする必要があるためです.したがって、これらのコマンドは、生成するKubernetesクラスタのセキュリティプロファイルを現在のユーザに保存する.kubeディレクトリでは、kubectlのデフォルトでは、このディレクトリのライセンス情報を使用してKubernetesクラスタにアクセスします.そうしなければ、私たちは毎回export KUBECONFIG環境変数を通じてkubectlというセキュリティプロファイルの場所を教える必要があります.
rootユーザー配置を使用する場合は、exportを使用して環境変数を定義できます.
これで、クラスタの初期化が完了し、kubectl get csを使用してクラスタの健康状態情報を表示できます.
以上の結果から、masterのコンポーネントcontroller-manager、scheduler、etcdは正常な状態にあることがわかります.ではapiserverはどこへ行きましたか?kubectlはapiserverを介して通信し、etcdでクラスタの状態情報を取得するので、apiserverが正常に動作している状態であることを示すクラスタの状態情報を取得することができる.kubectl get nodeを使用してノード情報を取得すると、まだPodネットワークが配備されていないため、masterノードの状態がNotReadyであることがわかります.
5、ネットワークプラグインCNIのインストール
Podネットワークプラグインをインストールし、Pod間の相互通信を保証します.各クラスタにはPodネットワークが1つしかありません.flannelを導入する前に変更するカーネルパラメータは、ブリッジされたIPv 4のトラフィックをiptablesチェーンに転送する必要があります.これはCNIプラグインの実行の前提条件です.
これで、KubernetesのMasterノードはすでに配備が完了し、デフォルトでは、KubernetesのMasterノードはユーザーPodを実行できません.これはKubernetesの汚点メカニズムに属します.
6.KubernetesのWorkerノードを配置する
KubernetesのWorkerノードとMasterノードはほぼ同じで、これはすべてkubeletコンポーネントで実行されます.唯一の違いはkubeadm initの過程でkubeletが起動すると、Masterノードはkube-api-server、kube-scheduler、kube-controller-managerの3つのシステムPodを自動的に実行することです.
したがって、ワークノードの導入は2ステップで完了します.
(1)すべてのWorkerノードで「kubeadm,kubelet,dockerのインストール」を実行する
(2)Masterノードの配備時に生産されたkubeadm join命令の実行
クラスタに参加した後、ノードのステータス情報を表示し、node 01ノードのステータスがNotReadyであることを確認します.node 01ノードにミラーがまだミラーされていないか、ミラーがプルされているためです.ミラーを引き抜くのを待つと、対応するPodが起動します.
7、新たにクラスタを追加したWorkerノード
同様にnodeノードに必要なミラーを予め引き出しておき、ここで間違いを犯したのは、公式の説明によるとtonkenのデフォルト有効時間は24 hであり、時間差によりここのtokenが失効したため、kubeadm token listを使用してtokenを表示することができ、以前に初期化されたtonkenが失効したことが分かった.
では、ここでtokenを再生成する必要があります.生成方法は次のとおりです.
値--discovery-token-ca-cert-hashがない場合は、masterノードで次のコマンドチェーンを実行して取得できます.
このとき、kube joinコマンドを再実行してnode 02をクラスタに追加します.ここで、discovery-token-ca-cert-hashは初期化時の証明書を使用できます.
8、Taint/TaolerationでMasterを調整してPod策略を実行する
前述したように、デフォルトではMasterノードではユーザPodの実行は許可されていません.KubernetesはTaint/Talerationメカニズムを採用している.
その原理は、あるノードに「汚点をつけた」というTaintが付加されると、KubernetesのPodには「潔癖」があるため、すべてのPodがこのノードで実行できないということです.
このノード上で実行できるのは、個々のPod宣言がこの「汚点」、すなわちTolerationを許容できる場合を除きます.
ここで、ノードに「汚点」(Point)を付けるコマンドは、次のとおりです.
このとき、node 1ノードには、foo=bar:NoScheduleというキー値ペア形式のTaintが追加されます.値の中のNoScheduleは、Tolerationがなくてもnode 1で実行されているPodに影響を及ぼさないことを意味します.
では、PodはどのようにTolerationを宣言すればいいのでしょうか.
Podのyamlファイルにspecを配置し、tolerationフィールドを追加するだけです.
このTolerationの意味は、このPodはすべてのキー値ペアがfoo=barであるTaint(operator:“Equal”,“等しい”操作)を許容できることである.
MasterノードのTaintフィールドをkubectl describeで確認できます.
Masterノードのデフォルトにnode-roleが追加されていることがわかります.kubernetes.io/master:NoScheduleのような「汚点」で、キーはnode-role.kubernetes.io/masterで、「値」は指定されていません.
この場合、「Exists」オペレータ(operator:「Exists」、「存在」であればよい)を使用して、このPodがfooをキーとするすべてのPointを許容できることを説明する必要があります.
もちろん、このPointを削除することで、汚点障害の問題を解決することもできます.
「node-role.kubernetes.io/master」というキーの後ろに横線「-」を追加し、「node-role.kubernetes.io/master」をキーとするすべてのTaintを削除することを示します.
これで,kubeadmを用いてk 8 sクラスタを配備することは一時的に一段落した!!!!
kubeadmを使用してクラスタを配置する
ノード名
ipアドレス
配置の説明
Podセグメント
サービスセグメント
システムの説明
k8s-master
192.168.56.11
docker、kubeadm、kubectl、kubelet
10.244.0.0/16 10.96.0.0/12 Centos 7.4
k8s-node01
192.168.56.12
docker、kubeadm、kubelet
10.244.0.0/16 10.96.0.0/12 Centos 7.4
k8s-node02
192.168.56.13
docker、kubeadm、kubelet
10.244.0.0/16 10.96.0.0/12 Centos 7.4
1、kubernetesソースの構成
[root@k8s-master ~]# cd /etc/yum.repos.d/
：https://opsx.alibaba.com/mirror
[root@k8s-master yum.repos.d]# wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # dokcer
[root@k8s-master ~]# cat < /etc/yum.repos.d/kubernetes.repo # kubernetes
> [kubernetes]
> name=Kubernetes
> baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
> enabled=1
> gpgcheck=1
> repo_gpgcheck=1
> gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
> EOF
[root@k8s-master yum.repos.d]# yum repolist # ソースをnode 01ノードとnode 02ノードにコピー
[root@k8s-master yum.repos.d]# scp kubernetes.repo docker-ce.repo k8s-node1:/etc/yum.repos.d/
kubernetes.repo 100% 276 276.1KB/s 00:00
docker-ce.repo 100% 2640 1.7MB/s 00:00
[root@k8s-master yum.repos.d]# scp kubernetes.repo docker-ce.repo k8s-node2:/etc/yum.repos.d/
kubernetes.repo 100% 276 226.9KB/s 00:00
docker-ce.repo 100% 2640 1.7MB/s 00:00 2、Masterノードインストールdocker、kubelet、kubeadm、コマンドラインツールkubectl
[root@k8s-master yum.repos.d]# yum install -y docker-ce kubelet kubeadm kubectl
[root@k8s-master ~]# systemctl start docker
[root@k8s-master ~]# systemctl enable dockerdockerを起動するには、海外の倉庫でダウンロードできないため、ミラーファイルを自動的にdocker倉庫に依存するミラーファイルをダウンロードする必要があります.kubeadmは、ローカルのプライベート倉庫でミラーファイルを取得することもできます.
3、ミラーをダウンロードしておく
master docker pull ， tag
docker pull xiyangxixia/k8s-proxy-amd64:v1.11.1
docker tag xiyangxixia/k8s-proxy-amd64:v1.11.1 k8s.gcr.io/kube-proxy-amd64:v1.11.1
docker pull xiyangxixia/k8s-scheduler:v1.11.1
docker tag xiyangxixia/k8s-scheduler:v1.11.1 k8s.gcr.io/kube-scheduler-amd64:v1.11.1
docker pull xiyangxixia/k8s-controller-manager:v1.11.1
docker tag xiyangxixia/k8s-controller-manager:v1.11.1 k8s.gcr.io/kube-controller-manager-amd64:v1.11.1
docker pull xiyangxixia/k8s-apiserver-amd64:v1.11.1
docker tag xiyangxixia/k8s-apiserver-amd64:v1.11.1 k8s.gcr.io/kube-apiserver-amd64:v1.11.1
docker pull xiyangxixia/k8s-etcd:3.2.18
docker tag xiyangxixia/k8s-etcd:3.2.18 k8s.gcr.io/etcd-amd64:3.2.18
docker pull xiyangxixia/k8s-coredns:1.1.3
docker tag xiyangxixia/k8s-coredns:1.1.3 k8s.gcr.io/coredns:1.1.3
docker pull xiyangxixia/k8s-pause:3.1
docker tag xiyangxixia/k8s-pause:3.1 k8s.gcr.io/pause:3.1
docker pull xiyangxixia/k8s-flannel:v0.10.0-s390x
docker tag xiyangxixia/k8s-flannel:v0.10.0-s390x quay.io/coreos/flannel:v0.10.0-s390x
docker pull xiyangxixia/k8s-flannel:v0.10.0-ppc64le
docker tag xiyangxixia/k8s-flannel:v0.10.0-ppc64le quay.io/coreos/flannel:v0.10.0-ppc64l
docker pull xiyangxixia/k8s-flannel:v0.10.0-arm
docker tag xiyangxixia/k8s-flannel:v0.10.0-arm quay.io/coreos/flannel:v0.10.0-arm
docker pull xiyangxixia/k8s-flannel:v0.10.0-amd64
docker tag xiyangxixia/k8s-flannel:v0.10.0-amd64 quay.io/coreos/flannel:v0.10.0-amd64
node
docker pull xiyangxixia/k8s-pause:3.1
docker tag xiyangxixia/k8s-pause:3.1 k8s.gcr.io/pause:3.1
docker pull xiyangxixia/k8s-proxy-amd64:v1.11.1
docker tag xiyangxixia/k8s-proxy-amd64:v1.11.1 k8s.gcr.io/kube-proxy-amd64:v1.11.1
docker pull xiyangxixia/k8s-flannel:v0.10.0-amd64
docker tag xiyangxixia/k8s-flannel:v0.10.0-amd64 quay.io/coreos/flannel:v0.10.0-amd644、kubernetesのMasterノードを配置する
[root@k8s-master ~]# vim /etc/sysconfig/kubelet # kubelet swap
KUBELET_EXTRA_ARGS="--fail-swap-on=false" # swap
kubelet ， swap ， swap
[root@k8s-master ~]# swapoff -a # swap
[root@k8s-master ~]# kubeadm init --kubernetes-version=v1.11.1 --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12 --ignore-preflight-errors=Swap #
[init] using Kubernetes version: v1.11.1
[preflight] running pre-flight checks
I0821 18:14:22.223765 18053 kernel_validator.go:81] Validating kernel version
I0821 18:14:22.223894 18053 kernel_validator.go:96] Validating kernel config
[WARNING SystemVerification]: docker version is greater than the most recently validated version. Docker version: 18.06.0-ce. Max validated version: 17.03
[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 certificate and key.
[certificates] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.56.11]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[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 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 localhost] and IPs [192.168.56.11 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"
[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 51.033696 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.11" in namespace kube-system with the configuration for the kubelets in the cluster
[markmaster] Marking the node k8s-master as master by adding the label "node-role.kubernetes.io/master=''"
[markmaster] Marking the node k8s-master 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" as an annotation
[bootstraptoken] using token: dx7mko.j2ug1lqjra5bf6p2
[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 192.168.56.11:6443 --token dx7mko.j2ug1lqjra5bf6p2 --discovery-token-ca-cert-hash sha256:93fe958796db44dcc23764cb8d9b6a2e67bead072e51a3d4d3c2d36b5d1007cfこれでKubernetes Masterの導入が完了します.このプロセスには数分かかります.デプロイが完了すると、kubeadmは次のコマンドを生成します.
kubeadm join 192.168.56.11:6443 --token dx7mko.j2ug1lqjra5bf6p2 --discovery-token-ca-cert-hash sha256:93fe958796db44dcc23764cb8d9b6a2e67bead072e51a3d4d3c2d36b5d1007cfこのkubeadm joinコマンドは、このMasterノードにワークノード(Worker)を追加するためのコマンドで、後でワークノードを配備する際に使用され、記録する必要があります.
また、kubeadmは、Kubernetesクラスタを初めて使用するために必要な構成コマンドを提示します.
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/configこれらのコマンドを構成する必要があるのは、Kubernetesクラスタがデフォルトで暗号化された方法でアクセスする必要があるためです.したがって、これらのコマンドは、生成するKubernetesクラスタのセキュリティプロファイルを現在のユーザに保存する.kubeディレクトリでは、kubectlのデフォルトでは、このディレクトリのライセンス情報を使用してKubernetesクラスタにアクセスします.そうしなければ、私たちは毎回export KUBECONFIG環境変数を通じてkubectlというセキュリティプロファイルの場所を教える必要があります.
rootユーザー配置を使用する場合は、exportを使用して環境変数を定義できます.
[root@k8s-master ~]# export KUBECONFIG=/etc/kubernetes/admin.confこれで、クラスタの初期化が完了し、kubectl get csを使用してクラスタの健康状態情報を表示できます.
[root@k8s-master ~]# kubectl get cs
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-0 Healthy {"health": "true"}
[root@k8s-master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master NotReady master 43m v1.11.2以上の結果から、masterのコンポーネントcontroller-manager、scheduler、etcdは正常な状態にあることがわかります.ではapiserverはどこへ行きましたか?kubectlはapiserverを介して通信し、etcdでクラスタの状態情報を取得するので、apiserverが正常に動作している状態であることを示すクラスタの状態情報を取得することができる.kubectl get nodeを使用してノード情報を取得すると、まだPodネットワークが配備されていないため、masterノードの状態がNotReadyであることがわかります.
5、ネットワークプラグインCNIのインストール
Podネットワークプラグインをインストールし、Pod間の相互通信を保証します.各クラスタにはPodネットワークが1つしかありません.flannelを導入する前に変更するカーネルパラメータは、ブリッジされたIPv 4のトラフィックをiptablesチェーンに転送する必要があります.これはCNIプラグインの実行の前提条件です.
[root@k8s-master ~]# cat /proc/sys/net/bridge/bridge-nf-call-iptables
1
[root@k8s-master ~]# cat /proc/sys/net/bridge/bridge-nf-call-ip6tables
1
[root@k8s-master ~]# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/c5d10c8/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 created
[root@k8s-master ~]# kubectl get node # master ， Ready
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 3h v1.11.2これで、KubernetesのMasterノードはすでに配備が完了し、デフォルトでは、KubernetesのMasterノードはユーザーPodを実行できません.これはKubernetesの汚点メカニズムに属します.
6.KubernetesのWorkerノードを配置する
KubernetesのWorkerノードとMasterノードはほぼ同じで、これはすべてkubeletコンポーネントで実行されます.唯一の違いはkubeadm initの過程でkubeletが起動すると、Masterノードはkube-api-server、kube-scheduler、kube-controller-managerの3つのシステムPodを自動的に実行することです.
したがって、ワークノードの導入は2ステップで完了します.
(1)すべてのWorkerノードで「kubeadm,kubelet,dockerのインストール」を実行する
(2)Masterノードの配備時に生産されたkubeadm join命令の実行
[root@k8s-node01 ~]# yum install -y docker kubeadm kubelet
[root@k8s-node01 ~]# systemctl enable dokcer kubelet
[root@k8s-node01 ~]# systemctl start docker
， docker ， ， node 。
[root@k8s-node01 ~]# kubeadm join 192.168.56.11:6443 --token dx7mko.j2ug1lqjra5bf6p2 --discovery-token-ca-cert-hash sha256:93fe958796db44dcc23764cb8d9b6a2e67bead072e51a3d4d3c2d36b5d1007cf
[root@k8s-master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 7h v1.11.2
k8s-node01 NotReady 3h v1.11.2 クラスタに参加した後、ノードのステータス情報を表示し、node 01ノードのステータスがNotReadyであることを確認します.node 01ノードにミラーがまだミラーされていないか、ミラーがプルされているためです.ミラーを引き抜くのを待つと、対応するPodが起動します.
[root@k8s-node01 ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5502c29b43df f0fad859c909 "/opt/bin/flanneld -…" 3 minutes ago Up 3 minutes k8s_kube-flannel_kube-flannel-ds-pgpr7_kube-system_23dc27e3-a5af-11e8-84d2-000c2972dc1f_1
db1cc0a6fec4 d5c25579d0ff "/usr/local/bin/kube…" 3 minutes ago Up 3 minutes k8s_kube-proxy_kube-proxy-vxckf_kube-system_23dc0141-a5af-11e8-84d2-000c2972dc1f_0
bc54ad3399e8 k8s.gcr.io/pause:3.1 "/pause" 9 minutes ago Up 9 minutes k8s_POD_kube-proxy-vxckf_kube-system_23dc0141-a5af-11e8-84d2-000c2972dc1f_0
cbfca066b71d k8s.gcr.io/pause:3.1 "/pause" 10 minutes ago Up 10 minutes k8s_POD_kube-flannel-ds-pgpr7_kube-system_23dc27e3-a5af-11e8-84d2-000c2972dc1f_0
[root@k8s-master ~]# kubectl get pods -n kube-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE
coredns-78fcdf6894-nmcmz 1/1 Running 0 1d 10.244.0.3 k8s-master
coredns-78fcdf6894-p5pfm 1/1 Running 0 1d 10.244.0.2 k8s-master
etcd-k8s-master 1/1 Running 1 1d 192.168.56.11 k8s-master
kube-apiserver-k8s-master 1/1 Running 8 1d 192.168.56.11 k8s-master
kube-controller-manager-k8s-master 1/1 Running 4 1d 192.168.56.11 k8s-master
kube-flannel-ds-n5c86 1/1 Running 0 1d 192.168.56.11 k8s-master
kube-flannel-ds-pgpr7 1/1 Running 1 1d 192.168.56.12 k8s-node01
kube-proxy-rxlt7 1/1 Running 1 1d 192.168.56.11 k8s-master
kube-proxy-vxckf 1/1 Running 0 1d 192.168.56.12 k8s-node01
kube-scheduler-k8s-master 1/1 Running 2 1d 192.168.56.11 k8s-master
[root@k8s-master ~]# kubectl get node # Ready
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 1d v1.11.2
k8s-node01 Ready 1d v1.11.2 7、新たにクラスタを追加したWorkerノード
[root@k8s-node02 ~]# yum install -y docker kubeadm kubelet
[root@k8s-node02 ~]# systemctl enable docker kubelet
[root@k8s-node02 ~]# systemctl start docker同様にnodeノードに必要なミラーを予め引き出しておき、ここで間違いを犯したのは、公式の説明によるとtonkenのデフォルト有効時間は24 hであり、時間差によりここのtokenが失効したため、kubeadm token listを使用してtokenを表示することができ、以前に初期化されたtonkenが失効したことが分かった.
[root@k8s-master ~]# kubeadm token list
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
dx7mko.j2ug1lqjra5bf6p2 2018-08-22T18:15:43-04:00 authentication,signing The default bootstrap token generated by 'kubeadm init'. system:bootstrappers:kubeadm:default-node-token では、ここでtokenを再生成する必要があります.生成方法は次のとおりです.
[root@k8s-master ~]# kubeadm token create
1vxhuq.qi11t7yq2wj20cpe値--discovery-token-ca-cert-hashがない場合は、masterノードで次のコマンドチェーンを実行して取得できます.
[root@k8s-master ~]# openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | sed 's/^.* //'
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78このとき、kube joinコマンドを再実行してnode 02をクラスタに追加します.ここで、discovery-token-ca-cert-hashは初期化時の証明書を使用できます.
[root@k8s-node02 ~]# kubeadm join 192.168.56.11:6443 --token 1vxhuq.qi11t7yq2wj20cpe --discovery-token-ca-cert-hash sha256:93fe958796db44dcc23764cb8d9b6a2e67bead072e51a3d4d3c2d36b5d1007cf
[root@k8s-master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 1d v1.11.2
k8s-node01 Ready 1d v1.11.2
k8s-node02 Ready 2h v1.11.2 8、Taint/TaolerationでMasterを調整してPod策略を実行する
前述したように、デフォルトではMasterノードではユーザPodの実行は許可されていません.KubernetesはTaint/Talerationメカニズムを採用している.
その原理は、あるノードに「汚点をつけた」というTaintが付加されると、KubernetesのPodには「潔癖」があるため、すべてのPodがこのノードで実行できないということです.
このノード上で実行できるのは、個々のPod宣言がこの「汚点」、すなわちTolerationを許容できる場合を除きます.
ここで、ノードに「汚点」(Point)を付けるコマンドは、次のとおりです.
$ kubectl taint nodes node1 foo=bar:NoScheduleこのとき、node 1ノードには、foo=bar:NoScheduleというキー値ペア形式のTaintが追加されます.値の中のNoScheduleは、Tolerationがなくてもnode 1で実行されているPodに影響を及ぼさないことを意味します.
では、PodはどのようにTolerationを宣言すればいいのでしょうか.
Podのyamlファイルにspecを配置し、tolerationフィールドを追加するだけです.
apiVersion: v1
kind: Pod
...
spec:
tolerations:
- key: "foo"
operator: "Equal"
value: "bar"
effect: "NoSchedule"このTolerationの意味は、このPodはすべてのキー値ペアがfoo=barであるTaint(operator:“Equal”,“等しい”操作)を許容できることである.
MasterノードのTaintフィールドをkubectl describeで確認できます.
[root@k8s-master ~]# kubectl describe node k8s-master
Name: k8s-master
Roles: master
.....
Taints: node-role.kubernetes.io/master:NoSchedule
......Masterノードのデフォルトにnode-roleが追加されていることがわかります.kubernetes.io/master:NoScheduleのような「汚点」で、キーはnode-role.kubernetes.io/masterで、「値」は指定されていません.
この場合、「Exists」オペレータ(operator:「Exists」、「存在」であればよい)を使用して、このPodがfooをキーとするすべてのPointを許容できることを説明する必要があります.
apiVersion: v1
kind: Pod
...
spec:
tolerations:
- key: "foo"
operator: "Exists"
effect: "NoSchedule"もちろん、このPointを削除することで、汚点障害の問題を解決することもできます.
$ kubectl taint nodes --all node-role.kubernetes.io/master-「node-role.kubernetes.io/master」というキーの後ろに横線「-」を追加し、「node-role.kubernetes.io/master」をキーとするすべてのTaintを削除することを示します.
これで,kubeadmを用いてk 8 sクラスタを配備することは一時的に一段落した!!!!