クベドを使用してKubernetes 1.13をインストール
29811 ワード
kubeadmはKubernetes公式に提供されているKubernetesクラスタを迅速にインストールするためのツールで、Kubernetesの各バージョンのリリースに伴って同期的に更新され、kubeadmはクラスタ構成のいくつかの実践を調整し、実験kubeadmを通じてKubernetes公式のクラスタ構成におけるいくつかの新しいベストプラクティスを学ぶことができます.
インストール時間同期ツール
サーバ間の同期
インストールする前に、以下の準備が必要です.3台のCentOS 7ホストは以下の通りです.
各ホストがファイアウォールを有効にしている場合、Kubernetesの各コンポーネントに必要なポートを開く必要がある場合は、Installing kubeadmの「Check required ports」のセクションを参照してください.ここでは簡単に、各ノードでファイアウォールを無効にします.
コマンドを実行して変更を有効にします.
ipvsはカーネルのメインに組み込まれているため、kube-proxyのipvsを開くには、次のカーネルモジュールをロードする必要があります.
すべてのKubernetesノードで次のスクリプトを実行します.
上記のスクリプトで作成した
次に、各ノードに
以上の前提条件が満たされなければ、
古いバージョンのアンインストール
必要なシステムツールをインストールします.
ソフトウェアソース情報を追加するには、次の手順に従います.
yumキャッシュの更新:
Docker-ceのインストール:
Dockerバックグラウンドサービスの起動
テスト実行hello-world
iptables filterテーブルのFOWARDチェーンのデフォルトポリシー(plicy)がACCEPTであることを確認します.
Dockerは1.13バージョンからデフォルトのファイアウォールルールを調整し、iptables filterテーブルのFOWARDチェーンを無効にします.これにより、Kubernetesクラスタ内のノード間Podが通信できなくなります.しかし、ここでdocker 1806をインストールすることで、デフォルトポリシーがACCEPTに戻ったことがわかりました.これはどのバージョンから戻ったのか分かりません.私たちのオンラインバージョンで使用されている1706は手動でこのポリシーを調整する必要があるからです.
次に、各ノードにkubeadmとkubeletをインストールします.
テストアドレス
使用できない場合は、アリミラーにアドレスを置き換える必要があります.
クbeletクbeadmクbectlのインストール
インストール結果から、cri-tools、kubernetes-cni、socatの3つの依存もインストールされていることがわかります.公式にはKubernetes 1.9から0.6.0バージョンにcni依存をアップグレードしています.現在の1.12では、このバージョンsocatはkubeletの依存cri-toolsです.CRI(Container Runtime Interface)コンテナの実行時インタフェースのコマンドラインツールです.
公式には、–configを使用してプロファイルを指定し、プロファイルに元のflagが構成した内容を指定することをお勧めします.詳細については、ここでSet Kubelet parameters via config fileを参照してください.これもKubernetesがダイナミックKubelet構成(Dynamic Kubelet Configuration)をサポートするために行ったもので、Reconfigure a Node’s Kubelet in a Live Clusterを参照してください.
kubeletのプロファイルはjsonまたはyaml形式でなければなりません.詳細はこちらを参照してください.
Kubernetes 1.8はシステムのSwapを閉じることを要求し始め、閉じなければデフォルトの構成ではkubeletは起動できません.
システムをシャットダウンするSwapの方法は以下の通りです.
ここで今回は2台のホスト上で他のサービスを実行するテストに使用するため、swapを閉じると他のサービスに影響を与える可能性があるため、ここでkubeletの構成を変更してこの制限を取り除きます.以前のKubernetesバージョンでは、kubeletの起動パラメータ
kubeadmが配備したkubeletのプロファイル
だからやはり正直にクbeletの起動パラメータ
各ノードの電源を入れてクbeletサービスを開始します.
次にkubeadmを使用してクラスタを初期化し、マスターノードとしてマスターを選択し、マスターで次のコマンドを実行します.
Podネットワークプラグインとしてflannelを選択したので、上記のコマンドは
次のエラーが実行されました.
エラーメッセージは
次のエラーメッセージが表示された場合
なぜなら、docker k 8 sミラーをインポートするこれらのミラーはデフォルトでgoogleではアクセスできないため、dockerhubの公式サイトから必要なミラーをローカルにダウンロードしてミラーのtagを変更してから
再実行init
完了した初期化出力の内容が記録されており、出力された内容に基づいて、Kubernetesクラスタのインストールに必要なキーステップを手動で初期化することが基本的にわかります.次のような重要な内容があります.
最後に、ノードをクラスタに追加するコマンド
クラスタのステータスを確認します.
個のコンポーネントがhealthy状態であることを確認します.
クラスタの初期化で問題が発生した場合は、次のコマンドを使用してクリーンアップできます.
次にflannel network add-onをインストールします.
実行結果
ここで気をつけてymlこのファイルのflannelのミラーは0.10.0、quayです.io/coreos/flannel:v0.10.0-amd64
ノードに複数のNICがある場合は、flannel issues 39701を参照して、現在
kubeadmを使用して初期化されたクラスタは、セキュリティ上の理由でPodがMaster Nodeにスケジューリングされない、すなわちMaster Nodeがワークロードに関与しない.これは、現在のmasterノードmasterが
ここではテスト環境を構築しているので、この汚れを取り除いてmasterをワークロードに参加させます.
このステップは時間がかかりますので、現れるのを辛抱強く待ってください.
の場合、実行
結果は
次に、node 2というホストをKubernetesクラスタに追加します.node 2上のkubeletの起動パラメータにもswapを閉じる必要がある制限が削除されているので、同じように–ignore-preflight-errors=Swapというパラメータが必要です.node 2で実行:
結果
クラスタへの参加に成功し、masterノードで
クラスタからノードを削除する方法クラスタからnode 2を削除する必要がある場合は、masterノードで次のコマンドを実行します.
node 1で実行:
マスターで実行するには、次の手順に従います.
その後、各ノードのkube-proxy podを再起動し、masterノードで実行します.
Using ipvs Proxierがログに印刷され、ipvsモードがオンになっていることを示します.
インストール前の準備
システム構成
各ノード間の時間の同期
インストール時間同期ツール
ntpdateyum install ntpdate -y
サーバ間の同期
ntpdate 0.asia.pool.ntp.org
ホスト名およびDNSの変更の準備
インストールする前に、以下の準備が必要です.3台のCentOS 7ホストは以下の通りです.
# hostname
hostnamectl set-hostname master
hostnamectl set-hostname node1
hostnamectl set-hostname node2
#
reboot
# host hosts ，
# 127.0.0.1 hostname
vi /etc/hosts
192.168.0.121 master
192.168.0.122 node1
192.168.0.123 node2
#
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 master
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.121 master
192.168.0.122 node1
192.168.0.123 node2
ホストファイアウォールの確認
各ホストがファイアウォールを有効にしている場合、Kubernetesの各コンポーネントに必要なポートを開く必要がある場合は、Installing kubeadmの「Check required ports」のセクションを参照してください.ここでは簡単に、各ノードでファイアウォールを無効にします.
systemctl stop firewalld
systemctl disable firewalld
SELINUXを無効にする:
setenforce 0
vi /etc/selinux/config
SELINUX=disabled
vi /etc/sysctl.d/k8s.confファイルを作成し、次の内容を追加します.net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
コマンドを実行して変更を有効にします.
modprobe br_netfilter
sysctl -p /etc/sysctl.d/k8s.conf
kube-proxyオープンipvsの前置条件
ipvsはカーネルのメインに組み込まれているため、kube-proxyのipvsを開くには、次のカーネルモジュールをロードする必要があります.
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack_ipv4
すべてのKubernetesノードで次のスクリプトを実行します.
cat > /etc/sysconfig/modules/ipvs.modules <上記のスクリプトで作成した
/etc/sysconfig/modules/ipvs.modulesファイルは、ノードが再起動した後に必要なモジュールを自動的にロードできることを保証します.lsmod | grep -e ip_vs -e nf_conntrack_ipv4コマンドを使用して、必要なカーネルモジュールが正しくロードされているかどうかを確認します.次に、各ノードに
ipsetパッケージyum install ipsetがインストールされていることを確認する必要がある.ipvsのエージェントルールを簡単に表示するには、管理ツールipvsadm yum install ipvsadmをインストールしたほうがいいです.以上の前提条件が満たされなければ、
kube-proxyの構成がipvsモードをオンにしてもiptablesモードに戻る.dockerのインストール
古いバージョンのアンインストール
yum remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-selinux \
docker-engine-selinux \
docker-engine
必要なシステムツールをインストールします.
yum install -y yum-utils device-mapper-persistent-data lvm2
ソフトウェアソース情報を追加するには、次の手順に従います.
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yumキャッシュの更新:
yum makecache fast
Docker-ceのインストール:
yum -y install docker-ce
Dockerバックグラウンドサービスの起動
systemctl start docker
systemctl enable docker
テスト実行hello-world
docker run hello-world
iptables filterテーブルのFOWARDチェーンのデフォルトポリシー(plicy)がACCEPTであることを確認します.
iptables -nvL
Dockerは1.13バージョンからデフォルトのファイアウォールルールを調整し、iptables filterテーブルのFOWARDチェーンを無効にします.これにより、Kubernetesクラスタ内のノード間Podが通信できなくなります.しかし、ここでdocker 1806をインストールすることで、デフォルトポリシーがACCEPTに戻ったことがわかりました.これはどのバージョンから戻ったのか分かりません.私たちのオンラインバージョンで使用されている1706は手動でこのポリシーを調整する必要があるからです.
Kubernetesの配備にkubeadmを使用
クbeadmとクbeletのインストール
次に、各ノードにkubeadmとkubeletをインストールします.
cat < /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
テストアドレス
https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64が使用可能かどうかcurl https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
使用できない場合は、アリミラーにアドレスを置き換える必要があります.
https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
cat < /etc/yum.repos.d/kubernetes.repo
[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
クbeletクbeadmクbectlのインストール
yum makecache fast
yum install -y kubelet kubeadm kubectl
インストール結果から、cri-tools、kubernetes-cni、socatの3つの依存もインストールされていることがわかります.公式にはKubernetes 1.9から0.6.0バージョンにcni依存をアップグレードしています.現在の1.12では、このバージョンsocatはkubeletの依存cri-toolsです.CRI(Container Runtime Interface)コンテナの実行時インタフェースのコマンドラインツールです.
kubelet –helpを実行すると、元のkubeletのほとんどのコマンドラインflagパラメータがDEPRECATEDによって表示されます.......
--address 0.0.0.0 The IP address for the Kubelet to serve on (set to 0.0.0.0 for all IPv4 interfaces and `::` for all IPv6 interfaces) (default 0.0.0.0) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
......
公式には、–configを使用してプロファイルを指定し、プロファイルに元のflagが構成した内容を指定することをお勧めします.詳細については、ここでSet Kubelet parameters via config fileを参照してください.これもKubernetesがダイナミックKubelet構成(Dynamic Kubelet Configuration)をサポートするために行ったもので、Reconfigure a Node’s Kubelet in a Live Clusterを参照してください.
kubeletのプロファイルはjsonまたはyaml形式でなければなりません.詳細はこちらを参照してください.
Kubernetes 1.8はシステムのSwapを閉じることを要求し始め、閉じなければデフォルトの構成ではkubeletは起動できません.
システムをシャットダウンするSwapの方法は以下の通りです.
swapoff -a
vi /etc/fstabファイルを修正し、SWAPの自動マウントを注記し、free -mを使用してswapが閉じていることを確認します.swappinessパラメータ調整、修正vi /etc/sysctl.d/k8s.conf次の行を追加します.vm.swappiness=0
sysctl -p /etc/sysctl.d/k8s.confを実行して修正を有効にします.ここで今回は2台のホスト上で他のサービスを実行するテストに使用するため、swapを閉じると他のサービスに影響を与える可能性があるため、ここでkubeletの構成を変更してこの制限を取り除きます.以前のKubernetesバージョンでは、kubeletの起動パラメータ
–fail-swap-on=falseによってこの制限を削除しました.Kubernetesは起動パラメータの使用を推奨せず、プロファイルの使用を推奨していることが先に分析されています.ここではプロファイル構成の形式に変更します.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"
# 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
kubeadmが配備したkubeletのプロファイル
–config=/var/lib/kubelet/config.yamlが表示され、実際には/var/lib/kubeletとこのconfig.yamlのプロファイルが作成されていないことを確認します.kubeadm初期化クラスタを実行すると自動的にこのプロファイルが生成されると予想されますが、Swapをオフにしないと、最初の初期化クラスタは失敗するに違いありません.だからやはり正直にクbeletの起動パラメータ
–fail-swap-on=falseを使ってSwapを閉じなければならない制限を取り除きます.修正vi /etc/sysconfig/kubelet、加入:KUBELET_EXTRA_ARGS=--fail-swap-on=false
kubeadm initを使用してクラスタを初期化する
各ノードの電源を入れてクbeletサービスを開始します.
systemctl enable kubelet.service
次にkubeadmを使用してクラスタを初期化し、マスターノードとしてマスターを選択し、マスターで次のコマンドを実行します.
kubeadm init \
--kubernetes-version=v1.13.0 \
--pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.0.121
Podネットワークプラグインとしてflannelを選択したので、上記のコマンドは
–pod-network-cidr=10.244.0.0/16を指定します.次のエラーが実行されました.
[init] Using Kubernetes version: v1.13.0
[preflight] Running pre-flight checks
[WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.0. Latest validated version: 18.06
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR Swap]: running with swap on is not supported. Please disable swap
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
エラーメッセージは
running with swap on is not supported. Please disable swapです.failSwapOn: falseを構成することにしたので、–ignore-preflight-errors=Swapパラメータを再追加してこのエラーを無視し、再実行します.kubeadm init \
--kubernetes-version=v1.13.0 \
--pod-network-cidr=10.244.0.0/16 \
--apiserver-advertise-address=192.168.0.121 \
--ignore-preflight-errors=Swap
次のエラーメッセージが表示された場合
[init] Using Kubernetes version: v1.13.0
[preflight] Running pre-flight checks
[WARNING Swap]: running with swap on is not supported. Please disable swap
[WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.0. Latest validated version: 18.06
[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'
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR ImagePull]: failed to pull image k8s.gcr.io/kube-apiserver:v1.13.0: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[ERROR ImagePull]: failed to pull image k8s.gcr.io/kube-controller-manager:v1.13.0: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[ERROR ImagePull]: failed to pull image k8s.gcr.io/kube-scheduler:v1.13.0: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[ERROR ImagePull]: failed to pull image k8s.gcr.io/kube-proxy:v1.13.0: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[ERROR ImagePull]: failed to pull image k8s.gcr.io/pause:3.1: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[ERROR ImagePull]: failed to pull image k8s.gcr.io/etcd:3.2.24: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[ERROR ImagePull]: failed to pull image k8s.gcr.io/coredns:1.2.6: output: Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
, error: exit status 1
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
なぜなら、docker k 8 sミラーをインポートするこれらのミラーはデフォルトでgoogleではアクセスできないため、dockerhubの公式サイトから必要なミラーをローカルにダウンロードしてミラーのtagを変更してから
kubeadm init kubeadmを実行します.まず、本機に対応するdockerミラーがあるかどうかを確認します.ある場合は、本機のミラーを直接起動します.ない場合は、https://k8s.gcr.io倉庫に関連するミラーをダウンロードする上のプロンプト情報には、必要なミラーの名前とtagが含まれています.プロンプトに必要な名前とtagに基づいてdockerhubからミラーをローカルにダウンロードします.# dockerhub
docker pull mirrorgooglecontainers/kube-apiserver-amd64:v1.13.0
docker pull mirrorgooglecontainers/kube-controller-manager-amd64:v1.13.0
docker pull mirrorgooglecontainers/kube-scheduler-amd64:v1.13.0
docker pull mirrorgooglecontainers/kube-proxy-amd64:v1.13.0
docker pull mirrorgooglecontainers/pause:3.1
docker pull mirrorgooglecontainers/etcd-amd64:3.2.24
docker pull coredns/coredns:1.2.6
# dockerhub tag k8s.gcr.io
docker tag docker.io/mirrorgooglecontainers/kube-apiserver-amd64:v1.13.0 k8s.gcr.io/kube-apiserver:v1.13.0
docker tag docker.io/mirrorgooglecontainers/kube-controller-manager-amd64:v1.13.0 k8s.gcr.io/kube-controller-manager:v1.13.0
docker tag docker.io/mirrorgooglecontainers/kube-scheduler-amd64:v1.13.0 k8s.gcr.io/kube-scheduler:v1.13.0
docker tag docker.io/mirrorgooglecontainers/kube-proxy-amd64:v1.13.0 k8s.gcr.io/kube-proxy:v1.13.0
docker tag docker.io/mirrorgooglecontainers/pause:3.1 k8s.gcr.io/pause:3.1
docker tag docker.io/mirrorgooglecontainers/etcd-amd64:3.2.24 k8s.gcr.io/etcd:3.2.24
docker tag docker.io/coredns/coredns:1.2.6 k8s.gcr.io/coredns:1.2.6
#
docker rmi mirrorgooglecontainers/kube-apiserver-amd64:v1.13.0
docker rmi mirrorgooglecontainers/kube-controller-manager-amd64:v1.13.0
docker rmi mirrorgooglecontainers/kube-scheduler-amd64:v1.13.0
docker rmi mirrorgooglecontainers/kube-proxy-amd64:v1.13.0
docker rmi mirrorgooglecontainers/pause:3.1
docker rmi mirrorgooglecontainers/etcd-amd64:3.2.24
docker rmi coredns/coredns:1.2.6
再実行init
[init] Using Kubernetes version: v1.13.0
[preflight] Running pre-flight checks
[WARNING Swap]: running with swap on is not supported. Please disable swap
[WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.0. Latest validated version: 18.06
[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 "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.121]
[certs] Generating "apiserver-kubelet-client" certificate and key
[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/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [master localhost] and IPs [192.168.0.121 127.0.0.1 ::1]
[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 [master localhost] and IPs [192.168.0.121 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-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 28.005180 seconds
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.13" in namespace kube-system with the configuration for the kubelets in the cluster
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "master" as an annotation
[mark-control-plane] Marking the node master as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: bag6qi.1qc7mfs75d5r1znq
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[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.0.121:6443 --token bag6qi.1qc7mfs75d5r1znq --discovery-token-ca-cert-hash sha256:5c3533240bf14b1aacc33e92ebde929f9e573752b629262fa43db02c4e656b8f
完了した初期化出力の内容が記録されており、出力された内容に基づいて、Kubernetesクラスタのインストールに必要なキーステップを手動で初期化することが基本的にわかります.次のような重要な内容があります.
[kubelet-start] kubelet /var/lib/kubelet/config.yaml
[certificates]
[kubeconfig] kubeconfig
[bootstraptoken] token ， kubeadm join
kubectl ：
```bash
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
最後に、ノードをクラスタに追加するコマンド
kubeadm join 192.168.0.121:6443 --token bag6qi.1qc7mfs75d5r1znq --discovery-token-ca-cert-hash sha256:5c3533240bf14b1aacc33e92ebde929f9e573752b629262fa43db02c4e656b8fが与えられる.クラスタのステータスを確認します.
kubectl get cs
個のコンポーネントがhealthy状態であることを確認します.
クラスタの初期化で問題が発生した場合は、次のコマンドを使用してクリーンアップできます.
kubeadm reset
ifconfig cni0 down
ip link delete cni0
ifconfig flannel.1 down
ip link delete flannel.1
rm -rf /var/lib/cni/
Pod Networkのインストール
次にflannel network add-onをインストールします.
kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
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
ここで気をつけてymlこのファイルのflannelのミラーは0.10.0、quayです.io/coreos/flannel:v0.10.0-amd64
ノードに複数のNICがある場合は、flannel issues 39701を参照して、現在
kube-flannel.ymlで–ifaceパラメータを使用してクラスタホスト内のNICの名前を指定する必要があります.そうしないと、dnsが解析できない可能性があります.kube-flannel.ymlをローカルにダウンロードする必要があります.flanneld起動パラメータに–iface=を追加します.......
containers:
- name: kube-flannel
image: quay.io/coreos/flannel:v0.10.0-amd64
command:
- /opt/bin/flanneld
args:
- --ip-masq
- --kube-subnet-mgr
- --iface=eth1
......
kubectl get pod --all-namespaces -o wideを使用して、すべてのPodがRunning状態であることを確認します.NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
default curl-66959f6557-47582 1/1 Running 2 36h 10.244.0.6 master
kube-system coredns-86c58d9df4-wdh4x 1/1 Running 1 37h 10.244.0.5 master
kube-system coredns-86c58d9df4-zfrm5 1/1 Running 1 37h 10.244.0.7 master
kube-system etcd-master 1/1 Running 2 37h 192.168.0.121 master
kube-system kube-apiserver-master 1/1 Running 2 37h 192.168.0.121 master
kube-system kube-controller-manager-master 1/1 Running 3 37h 192.168.0.121 master
kube-system kube-flannel-ds-amd64-66kns 1/1 Running 1 36h 192.168.0.123 node2
kube-system kube-flannel-ds-amd64-6s7v5 1/1 Running 1 37h 192.168.0.121 master
kube-system kube-flannel-ds-amd64-9j5sj 1/1 Running 1 36h 192.168.0.122 node1
kube-system kube-proxy-4vn59 1/1 Running 1 36h 192.168.0.123 node2
kube-system kube-proxy-fsp2d 1/1 Running 1 36h 192.168.0.121 master
kube-system kube-proxy-qkg7t 1/1 Running 1 36h 192.168.0.122 node1
kube-system kube-scheduler-master 1/1 Running 3 37h 192.168.0.121 master
master nodeワークロードへの参加
kubeadmを使用して初期化されたクラスタは、セキュリティ上の理由でPodがMaster Nodeにスケジューリングされない、すなわちMaster Nodeがワークロードに関与しない.これは、現在のmasterノードmasterが
node-role.kubernetes.io/master:NoScheduleの汚点を打たれたためです.kubectl describe node master | grep Taint
Taints: node-role.kubernetes.io/master:NoSchedule
ここではテスト環境を構築しているので、この汚れを取り除いてmasterをワークロードに参加させます.
kubectl taint nodes master node-role.kubernetes.io/master-
node "master" untainted
DNSのテスト
kubectl run curl --image=radial/busyboxplus:curl -it
このステップは時間がかかりますので、現れるのを辛抱強く待ってください.
[ root@curl-66959f6557-47582:/ ]$
の場合、実行
nslookup kubernetes.default
結果は
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: kubernetes.default
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local
Kubernetesクラスタへのノードの追加
次に、node 2というホストをKubernetesクラスタに追加します.node 2上のkubeletの起動パラメータにもswapを閉じる必要がある制限が削除されているので、同じように–ignore-preflight-errors=Swapというパラメータが必要です.node 2で実行:
kubeadm \
join 192.168.0.121:6443 \
--token bag6qi.1qc7mfs75d5r1znq \
--discovery-token-ca-cert-hash sha256:5c3533240bf14b1aacc33e92ebde929f9e573752b629262fa43db02c4e656b8f \
--ignore-preflight-errors=Swap
結果
[preflight] Running pre-flight checks
[WARNING Swap]: running with swap on is not supported. Please disable swap
[WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.0. Latest validated version: 18.06
[discovery] Trying to connect to API Server "192.168.0.121:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://192.168.0.121:6443"
[discovery] Requesting info from "https://192.168.0.121: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 "192.168.0.121:6443"
[discovery] Successfully established connection with API Server "192.168.0.121:6443"
[join] Reading configuration from the cluster...
[join] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.13" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] 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 "node1" 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.
クラスタへの参加に成功し、masterノードで
kubectl get nodesの結果を実行NAME STATUS ROLES AGE VERSION
master Ready master 36h v1.13.2
node1 Ready 35h v1.13.2
node2 Ready 35h v1.13.2
クラスタからノードを削除する方法クラスタからnode 2を削除する必要がある場合は、masterノードで次のコマンドを実行します.
kubectl drain node1 --delete-local-data --force --ignore-daemonsets
kubectl delete node node1
node 1で実行:
kubeadm reset
ifconfig cni0 down
ip link delete cni0
ifconfig flannel.1 down
ip link delete flannel.1
rm -rf /var/lib/cni/
マスターで実行するには、次の手順に従います.
kubectl delete node node1
kube-proxyオープンipvs
ConfigMapのkube-system/kube-proxyのconfig.confmode: "ipvs"を変更します.kubectl edit cm kube-proxy -n kube-system
その後、各ノードのkube-proxy podを再起動し、masterノードで実行します.
kubectl get pod -n kube-system | grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'
kubectl get pod -n kube-system | grep kube-proxy
#
kube-proxy-4vn59 1/1 Running 0 100s
kube-proxy-fsp2d 1/1 Running 0 86s
kube-proxy-qkg7t 1/1 Running 0 97s
kubectl logs kube-proxy-4vn59 -n kube-system
#
I0115 08:53:45.580868 1 server_others.go:189] Using ipvs Proxier.
W0115 08:53:45.581086 1 proxier.go:365] IPVS scheduler not specified, use rr by default
I0115 08:53:45.583075 1 server_others.go:216] Tearing down inactive rules.
I0115 08:53:45.614150 1 server.go:464] Version: v1.13.0
I0115 08:53:45.618996 1 conntrack.go:52] Setting nf_conntrack_max to 131072
I0115 08:53:45.619467 1 config.go:202] Starting service config controller
I0115 08:53:45.619474 1 controller_utils.go:1027] Waiting for caches to sync for service config controller
I0115 08:53:45.619482 1 config.go:102] Starting endpoints config controller
I0115 08:53:45.619485 1 controller_utils.go:1027] Waiting for caches to sync for endpoints config controller
I0115 08:53:45.719664 1 controller_utils.go:1034] Caches are synced for service config controller
I0115 08:53:45.719739 1 controller_utils.go:1034] Caches are synced for endpoints config controller
#
Using ipvs Proxierがログに印刷され、ipvsモードがオンになっていることを示します.