kubeadmの動作原理
kubeadmの動作原理
バイナリを使ってk 8 sクラスタを配置したことがあると信じている学生たちは、バイナリを配置するのは難しいことを知っています.少し基礎のある人は配置しても成功の希望があります.そうしないと、他の人のチュートリアルに従って一歩一歩配置するしかありません.配置するときは、このような操作の意味が全然分かりません.問題が発生して手がつけられない.初心者にとって本当に命の無駄ですが、クラスタを配置する簡単な方法はありませんか?この問題は数年前には良い答えがなかったかもしれませんが、今では答えが多すぎます.例えば、kubeadm、rkeなど、今日はkubeadmがクラスタを配置する動作原理を紹介します.
ここではデフォルトでk 8 sの基礎があり、彼らがどのようなコンポーネントで構成されているかを知っています.
クラスタが導入されると、彼の各コンポーネントは実行される必要がある、個別のバイナリファイルであり、現在コンテナ化が発達している時期には、dockerを使用して導入を簡素化することに違いありません.しかし、コンテナ化が導入されると、クbeletをどのようにコンテナ化するかという大きな問題があります.
クbeletはkubernetesプロジェクトがDockerなどのコンテナ実行時を操作するためのコアコンポーネントであることを知っています.各ノードに存在し、コンテナ実行時と付き合う以外に、クbeletはコンテナネットワークを構成し、コンテナデータボリュームを管理する際に、ホストを直接操作する必要があります.
クbelet自体が1つのコンテナで動作している場合、ホストを直接操作するのは面倒になります.ネットワーク構成の場合、kubeletコンテナはNetwork Namespace(--net host)をオンにしないで、ホストのネットワークスタックを直接共有することができます.しかし、クbeletがコンテナ越しのMount Namespaceやファイルシステムを経由してホストのファイルシステムを操作するのは、ちょっと難しいです.
たとえば,ユーザがNFSをコンテナの永続化データボリュームとして使用する場合,kubeletはコンテナをバインドしてマウントする前に,ホストの指定ディレクトリにNFSのリモートディレクトリを先にマウントする必要がある.
しかし、この時問題が来た.現在クbeletはコンテナで実行されているため、この「mount-F nfs」コマンドは、別のMount Namespaceから隔離されていることを意味します.すなわち,kubeletが行ったマウント操作は,ホストに「伝播」されない.
この問題について、setns()システム呼び出しを使用して、ホストのMount Namespaceでこれらのマウント操作を実行することができると言われています.Dockerに-mnt=hostのパラメータをサポートさせるべきだという人もいます.しかし、これまでコンテナでクbeletを実行しても、まだ良い解決策はありません.Kubernetesプロジェクトをコンテナで配置することもお勧めしません.
そこで、上記の問題を解決するために、kubeadmは次の方法を選択しました. kubeletを直接ホストに配置し、コンテナを使用して他のkubernetesコンポーネント を配置します.
したがって、kubeadmを使用してクラスタをインストールする最初のステップは、すべてのマシンにkubeadm、kubelet、kubectlの3つのバイナリファイルを手動でインストールすることです.
centos/Redhatインストール:
注意:この時点でクbeletを起動すると、エラーが表示され、ファイルが不足していることが示唆されます.この時点では気にしないでください.クbeadm initを使用してクラスタを初期化すると正常です.
次に、kubeadmのプロファイルを作成し、クラスタ情報を指定する必要があります.例を挙げる
詳細については、以下を参照してください.https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/
次に
kubeadm initのワークフロー
1,Prefligth Checks検査
kubeadmがまずしなければならないのは、Kubernetesを配備するためにこのマシンが使用できることを確認するための一連の検査作業です.このステップのチェックは、「Preflight Checks」と呼ばれ、後続の面倒を省くことができます.
実は、Preflight Checksには多くの面が含まれています.例えば、 Linuxカーネルのバージョンは3.10以上でなければなりませんか? Linux Cgroupsモジュールが使用可能かどうか 機械のhostnameは標準ですか?Kubernetesプロジェクトでは、マシンの名前とEtcdに格納されているすべてのAPIオブジェクトは、標準的なDNSネーミング(RFC 1123)を使用する必要があります. ユーザーがインストールしたkubeadmとkubeletのバージョンは一致していますか? マシンにKubernetesのバイナリファイルがインストールされていますか? Kubernetesのワークポート10250/10525/10252ポートはすでに占有されていますか? ip、mountなどのLinux命令は存在しますか? Dockerはインストールされていますか? Dockerとkubeletが使用するドライバは同じですか? ....
これらのチェックでは、いくつかのチェック項目は警告をトリガーするだけで、他のチェック項目はエラーとみなされ、問題が解決されない限り、またはユーザーが
2、自己署名証明書の生成
チェックに合格すると、kubeadmはkubernetesが対外的にサービスを提供するために必要な各種証明書と対応するディレクトリを生成します.
ユーザが、
kubernetesが対外的にサービスを提供する場合、「不安全モード」をわざわざオンにしない限り、HTTPSを通じてKube-apiserverにアクセスする必要があります.これには、Kubernetesクラスタの証明書ファイルを構成する必要があります.
kubeadmがKubernetesプロジェクトのために生成した証明書ファイルは、Masterノードの
また,ユーザがkubectlを用いてコンテナログなどのstreaming操作を取得する場合,kube-apiserverを介してkubeletに要求する必要があり,この接続も安全でなければならない.kubeadmがこのステップのために生成したことapiserver-kubelet-client.outファイル、対応する秘密鍵はapiserver-kubelet-clientです.key.
このほか、KubernetesクラスタにはAggregate APIServerなどの特性もあり、専門の証明書も必要ですが、ここでは一つ一つ列挙しません.このファイルを参照してください.https://www.cnblogs.com/shoufu/p/12963081.htmlこれらの証明書をkubeadmに生成させないで、既存の証明書を次の証明書のディレクトリにコピーすることを選択できます.
3,他のコンポーネントがkube-apiserverにアクセスするために必要なプロファイルを生成する
これらのファイルのパスは、/etc/kubernetes/xxxです.conf
これらのファイルには、現在のMasterノードのサーバアドレス、リスニングポートが記録されています.証明書ディレクトリなどの情報.これにより、対応するクライアント(scheduler、kubeletなど)は、対応するファイルを直接ロードし、中の情報を使用してkube-apiserverと安全な接続を確立することができます.
4 MasterコンポーネントのPodプロファイルを生成する
Kubernetesでは、「Static Pod」という特殊な容器起動方法があります.配置するPodのYAMLファイルを指定したディレクトリに配置できます.これにより、このマシンのクbeletが起動すると、自動的にこのディレクトリをチェックし、すべてのPod YAMLファイルをロードし、このマシンで起動します.
この点からもKubernetesプロジェクトにおけるkubeletの地位は非常に高く,設計上は完全に独立したコンポーネントであり,他のMasterコンポーネントは補助的なシステムコンテナのように見える.
その後、kubeadmはkubeletを呼び出してこのymlファイルを実行し、Masterコンテナが起動すると、kubeadmは
その後、kubeadmはクラスタにbootstrap tokenを生成します.その後,このtokenを持つ限り,kubeletとkubadmがインストールされたノードはいずれもkubeadm joinを介してこのクラスタに参加することができる.
このtokenの値と使い方は、kubeadm init終了後に印刷されます.
tokenが生成されると、kubeadmはca.crtなどのMasterノードの重要な情報をコンフィグMapでEtcdに保存し、後続の導入ノードで使用します.このConfigMapの名前はcluster-infoです.
kubeadm initの最後のステップは、デフォルトのプラグインをインストールすることです.Kubernetesのデフォルトkube-proxyとDNSの2つのプラグインはインストールする必要があります.これらは、クラスタ全体のサービス発見およびDNS機能を提供するためにそれぞれ使用される.実は、この2つのプラグインも2つのコンテナミラーにすぎないので、kubeadmはKubernetesクライアントで2つのPodを作成すればいいだけです.
kubeadm joinのワークフロー
この流れは実はとても簡単で、kubeadm initがbootstrap tokenを生成した後、kubeletとkubeadmをインストールした任意のマシンでkubeadm joinを実行することができます.
しかし、なぜkubeadm joinを実行するにはこのようなtokenが必要なのでしょうか.
どのマシンもKubernetesクラスタのノードになるには、クラスタのkube-apiserverに登録する必要があります.しかし、apiserverと付き合うには、このマシンが対応する証明書ファイル(CAファイル)を取得しなければなりません.しかし、ワンタッチでインストールできるように、Masterノードに手動でファイルをコピーさせることはできません.
したがって、kubeadmは、少なくとも1回の「不安全モード」のアクセスをkube-apiserverに開始し、ConfigMapに保存されているcluster-info(APIServerのライセンス情報を保存している)を取得する必要があります.bootstrap tokenは、このプロセスのセキュリティ検証の役割を果たしています.
cluster-infoのkube-apiserverのアドレス、ポート、証明書があれば、kubeletは「セキュリティモード」でapiserverに接続でき、新しいノードの導入が完了します.
次に、他のノードでこのコマンドを繰り返すだけでいいです.
具体的なインストールについては、次の文書を参照してください.
参考:極客時間張磊のkubernetesコラム
：
：2020-06-04
w x：y18163201バイナリを使ってk 8 sクラスタを配置したことがあると信じている学生たちは、バイナリを配置するのは難しいことを知っています.少し基礎のある人は配置しても成功の希望があります.そうしないと、他の人のチュートリアルに従って一歩一歩配置するしかありません.配置するときは、このような操作の意味が全然分かりません.問題が発生して手がつけられない.初心者にとって本当に命の無駄ですが、クラスタを配置する簡単な方法はありませんか?この問題は数年前には良い答えがなかったかもしれませんが、今では答えが多すぎます.例えば、kubeadm、rkeなど、今日はkubeadmがクラスタを配置する動作原理を紹介します.
ここではデフォルトでk 8 sの基礎があり、彼らがどのようなコンポーネントで構成されているかを知っています.
クラスタが導入されると、彼の各コンポーネントは実行される必要がある、個別のバイナリファイルであり、現在コンテナ化が発達している時期には、dockerを使用して導入を簡素化することに違いありません.しかし、コンテナ化が導入されると、クbeletをどのようにコンテナ化するかという大きな問題があります.
クbeletはkubernetesプロジェクトがDockerなどのコンテナ実行時を操作するためのコアコンポーネントであることを知っています.各ノードに存在し、コンテナ実行時と付き合う以外に、クbeletはコンテナネットワークを構成し、コンテナデータボリュームを管理する際に、ホストを直接操作する必要があります.
クbelet自体が1つのコンテナで動作している場合、ホストを直接操作するのは面倒になります.ネットワーク構成の場合、kubeletコンテナはNetwork Namespace(--net host)をオンにしないで、ホストのネットワークスタックを直接共有することができます.しかし、クbeletがコンテナ越しのMount Namespaceやファイルシステムを経由してホストのファイルシステムを操作するのは、ちょっと難しいです.
たとえば,ユーザがNFSをコンテナの永続化データボリュームとして使用する場合,kubeletはコンテナをバインドしてマウントする前に,ホストの指定ディレクトリにNFSのリモートディレクトリを先にマウントする必要がある.
しかし、この時問題が来た.現在クbeletはコンテナで実行されているため、この「mount-F nfs」コマンドは、別のMount Namespaceから隔離されていることを意味します.すなわち,kubeletが行ったマウント操作は,ホストに「伝播」されない.
この問題について、setns()システム呼び出しを使用して、ホストのMount Namespaceでこれらのマウント操作を実行することができると言われています.Dockerに-mnt=hostのパラメータをサポートさせるべきだという人もいます.しかし、これまでコンテナでクbeletを実行しても、まだ良い解決策はありません.Kubernetesプロジェクトをコンテナで配置することもお勧めしません.
そこで、上記の問題を解決するために、kubeadmは次の方法を選択しました.
したがって、kubeadmを使用してクラスタをインストールする最初のステップは、すべてのマシンにkubeadm、kubelet、kubectlの3つのバイナリファイルを手動でインストールすることです.
centos/Redhatインストール:
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
yum -y install kubectl-1.14.0
yum -y install kubelet-1.14.0
yum -y install kubeadm-1.14.0
systemctl enable kubelet # ， 注意:この時点でクbeletを起動すると、エラーが表示され、ファイルが不足していることが示唆されます.この時点では気にしないでください.クbeadm initを使用してクラスタを初期化すると正常です.
次に、kubeadmのプロファイルを作成し、クラスタ情報を指定する必要があります.例を挙げる
cat > kubeadm-config.yaml <詳細については、以下を参照してください.https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm-init/
次に
kubeadm initを使用してMasterノードを配置できます.kubeadm initのワークフロー
1,Prefligth Checks検査
kubeadmがまずしなければならないのは、Kubernetesを配備するためにこのマシンが使用できることを確認するための一連の検査作業です.このステップのチェックは、「Preflight Checks」と呼ばれ、後続の面倒を省くことができます.
実は、Preflight Checksには多くの面が含まれています.例えば、
これらのチェックでは、いくつかのチェック項目は警告をトリガーするだけで、他のチェック項目はエラーとみなされ、問題が解決されない限り、またはユーザーが
--ignore-preflight-errors=<list-of-errors>パラメータを指定しない限りkubeadmを終了します.2、自己署名証明書の生成
チェックに合格すると、kubeadmはkubernetesが対外的にサービスを提供するために必要な各種証明書と対応するディレクトリを生成します.
ユーザが、
--cert-dirによって構成された証明書ディレクトリ(デフォルトでは/etc/kubernetes/pki)を介して独自のCA証明書および/または鍵を提供した場合、このステップはスキップされる.kubernetesが対外的にサービスを提供する場合、「不安全モード」をわざわざオンにしない限り、HTTPSを通じてKube-apiserverにアクセスする必要があります.これには、Kubernetesクラスタの証明書ファイルを構成する必要があります.
kubeadmがKubernetesプロジェクトのために生成した証明書ファイルは、Masterノードの
/etc/kubernetes/pkiディレクトリの下に配置されます.このディレクトリの下で、最も主要な証明書ファイルはca.crtと対応する秘密鍵ca.keyです.また,ユーザがkubectlを用いてコンテナログなどのstreaming操作を取得する場合,kube-apiserverを介してkubeletに要求する必要があり,この接続も安全でなければならない.kubeadmがこのステップのために生成したことapiserver-kubelet-client.outファイル、対応する秘密鍵はapiserver-kubelet-clientです.key.
このほか、KubernetesクラスタにはAggregate APIServerなどの特性もあり、専門の証明書も必要ですが、ここでは一つ一つ列挙しません.このファイルを参照してください.https://www.cnblogs.com/shoufu/p/12963081.htmlこれらの証明書をkubeadmに生成させないで、既存の証明書を次の証明書のディレクトリにコピーすることを選択できます.
/etc/kubernetes/pki/ca.{crt,key}
[root@zsf-test pki]# tree
.
├── apiserver.crt
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
├── apiserver.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── ca.crt
├── ca.key
├── etcd
│ ├── ca.crt
│ ├── ca.key
│ ├── healthcheck-client.crt
│ ├── healthcheck-client.key
│ ├── peer.crt
│ ├── peer.key
│ ├── server.crt
│ └── server.key
├── front-proxy-ca.crt
├── front-proxy-ca.key
├── front-proxy-client.crt
├── front-proxy-client.key
├── sa.key
└── sa.pub3,他のコンポーネントがkube-apiserverにアクセスするために必要なプロファイルを生成する
これらのファイルのパスは、/etc/kubernetes/xxxです.conf
ls /etc/kubernetes/*.conf
/etc/kubernetes/admin.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/scheduler.confこれらのファイルには、現在のMasterノードのサーバアドレス、リスニングポートが記録されています.証明書ディレクトリなどの情報.これにより、対応するクライアント(scheduler、kubeletなど)は、対応するファイルを直接ロードし、中の情報を使用してkube-apiserverと安全な接続を確立することができます.
4 MasterコンポーネントのPodプロファイルを生成する
Kubernetesでは、「Static Pod」という特殊な容器起動方法があります.配置するPodのYAMLファイルを指定したディレクトリに配置できます.これにより、このマシンのクbeletが起動すると、自動的にこのディレクトリをチェックし、すべてのPod YAMLファイルをロードし、このマシンで起動します.
この点からもKubernetesプロジェクトにおけるkubeletの地位は非常に高く,設計上は完全に独立したコンポーネントであり,他のMasterコンポーネントは補助的なシステムコンテナのように見える.
cd /etc/kubernetes/manifests
├── etcd.yaml
├── kube-apiserver.yaml
├── kube-controller-manager.yaml
└── kube-scheduler.yamlその後、kubeadmはkubeletを呼び出してこのymlファイルを実行し、Masterコンテナが起動すると、kubeadmは
localhost:6443/healthzというMasterコンポーネントの健康診断urlを検査し、Masterコンポーネントが完全に動作するのを待つ.その後、kubeadmはクラスタにbootstrap tokenを生成します.その後,このtokenを持つ限り,kubeletとkubadmがインストールされたノードはいずれもkubeadm joinを介してこのクラスタに参加することができる.
このtokenの値と使い方は、kubeadm init終了後に印刷されます.
tokenが生成されると、kubeadmはca.crtなどのMasterノードの重要な情報をコンフィグMapでEtcdに保存し、後続の導入ノードで使用します.このConfigMapの名前はcluster-infoです.
kubeadm initの最後のステップは、デフォルトのプラグインをインストールすることです.Kubernetesのデフォルトkube-proxyとDNSの2つのプラグインはインストールする必要があります.これらは、クラスタ全体のサービス発見およびDNS機能を提供するためにそれぞれ使用される.実は、この2つのプラグインも2つのコンテナミラーにすぎないので、kubeadmはKubernetesクライアントで2つのPodを作成すればいいだけです.
kubeadm joinのワークフロー
この流れは実はとても簡単で、kubeadm initがbootstrap tokenを生成した後、kubeletとkubeadmをインストールした任意のマシンでkubeadm joinを実行することができます.
しかし、なぜkubeadm joinを実行するにはこのようなtokenが必要なのでしょうか.
どのマシンもKubernetesクラスタのノードになるには、クラスタのkube-apiserverに登録する必要があります.しかし、apiserverと付き合うには、このマシンが対応する証明書ファイル(CAファイル)を取得しなければなりません.しかし、ワンタッチでインストールできるように、Masterノードに手動でファイルをコピーさせることはできません.
したがって、kubeadmは、少なくとも1回の「不安全モード」のアクセスをkube-apiserverに開始し、ConfigMapに保存されているcluster-info(APIServerのライセンス情報を保存している)を取得する必要があります.bootstrap tokenは、このプロセスのセキュリティ検証の役割を果たしています.
cluster-infoのkube-apiserverのアドレス、ポート、証明書があれば、kubeletは「セキュリティモード」でapiserverに接続でき、新しいノードの導入が完了します.
次に、他のノードでこのコマンドを繰り返すだけでいいです.
具体的なインストールについては、次の文書を参照してください.
https://zhangguanzhang.github.io/2019/11/24/kubeadm-base-use/#kubeadm%E9%83%A8%E7%BD%B2参考:極客時間張磊のkubernetesコラム