高可用性を備えた Kubernetes をインストールする最も簡単な方法です。

高可用性を備えた Kubernetes をインストールする最も簡単な方法です。

この記事では、HAProxy や Keepalived、Ansible に依存せずに、1 つのコマンドで Kubernetes 高可用性クラスターを構築する方法を説明します。 apiserver の負荷分散はカーネル IPVS を通じて実行され、apiserver の健全性検出が提供されます。アーキテクチャを下の図に示します。

このプロジェクトは sealos と呼ばれ、高可用性インストールを適切にサポートできる、シンプルでクリーン、軽量で安定した Kubernetes インストール ツールを目指しています。実際、強力なものを作るのは難しくありませんが、それを極めてシンプルで柔軟性があり、スケーラブルなものにするのはより困難です。したがって、実装中はこれらの原則に従う必要があります。

設計原則

sealos の特徴と利点:

  • オフラインインストール、個別のツールとリソースパッケージ(バイナリプログラム、構成ファイル、イメージyamlファイルなど)をサポートし、異なるバージョンを異なるオフラインパッケージに置き換えることができます。
  • 証明書の拡張
  • 使いやすさ
  • カスタム構成をサポート
  • カーネル負荷、非常に安定しており、トラブルシューティングが簡単

Ansible を使わないのはなぜですか?

バージョン 1.0 は確かに Ansible を使用して実装されていますが、ユーザーはまず Ansible をインストールする必要があり、Ansible をインストールするには Python といくつかの依存関係をインストールする必要があります。ユーザーの手間を省くために、Ansible はコンテナーに配置されて使用されます。キーレス使用を設定せず、ssh-pass などが必要な場合は、私にとっては満足のいくものではなく、私が望むミニマリストではありません。

そこで、依存関係のないバイナリ ファイル ツールを考案したいと考えました。ファイル配布やリモートコマンドは SDK を呼び出すことで実装されるため、他に依存することはありません。強迫性障害の私はこれでようやく満足しました。

Keepalived と HAProxy を使用しないのはなぜですか?

HAProxyをstatic podで動かす場合、大きな問題はなく、管理も比較的容易です。 Keepalived 用のオープンソース Ansible スクリプトのほとんどは、yum や apt などでインストールされますが、これは非常に制御しにくく、次のような欠点があります。

  • ソースの不整合によりバージョンの不整合が発生する可能性があります。バージョンが一致しないと、構成ファイルも異なる可能性があります。以前、スクリプトが効果的でないことに気付きましたが、その理由がわかりませんでした。後で、それはバージョンによるものだと分かりました。
  • システム上の理由によりインストールできない場合や、依存ライブラリの問題により一部の環境では直接インストールできない場合があります。
  • 私はインターネット上で多くのインストール スクリプトを読みました。多くの検出スクリプトと重み調整方法が間違っています。 HAProxy プロセスが存在するかどうかを直接検出します。実際、API サーバーが正常かどうかを検出する必要があります。 apiserver がダウンすると、HAProxy プロセスが存在していてもクラスターは異常になり、疑似的に高可用性が保たれます。
  • 管理が不便です。 Prometheus を介してクラスターを監視する場合、静的ポッドを直接監視できます。ただし、systemd で実行する場合は、別途監視設定を行う必要があり、再起動も別途開始する必要があります。 Kubelet 統合管理ほどクリーンでシンプルではありません。
  • また、Keepalived が CPU を飽和させる状況もありました。

そこで、この問題を解決するために、コンテナ内で Keepalived を実行しました (コミュニティが提供するイメージは基本的に利用できません)。変革の過程では多くの問題が発生しましたが、幸いなことに最終的には解決されました。

結局のところ、私はそれにうんざりしていたため、HAProxy と Keepalived を削除して、よりシンプルで信頼性の高いソリューションを見つけられないかと考えていましたが、実際にそれを見つけました。

ローカルワークロードに Envoy または Nginx を使用しないのはなぜですか?

高可用性の問題はローカル負荷を通じて解決します。

ローカル負荷を説明すると、各ノードでロード バランサーが起動され、アップストリームは 3 つのマスターです。 IPVS、Envoy、Nginx など、負荷分散方法は多数あります。最終的にカーネル IPVS を使用します。

Envoy のようなロード バランサーを使用する場合は、各ノードでプロセスを実行する必要があり、これによりリソースがさらに消費されるため、望ましくありません。 IPVS は実際には追加のプロセス LVScare も実行しますが、LVScare は IPVS ルールの管理のみを担当します。 kube-proxy と同様に、実際のトラフィックは依然として非常に安定したカーネルを通過するため、処理のためにパケットをユーザー モードに投入する必要はありません。

アーキテクチャ実装に問題があり、Envoy や他のシステムの使用が非常に困難になっています。つまり、参加時に負荷分散が確立されていない場合はスタックしてしまい、kubelet が起動しなくなります。したがって、最初に Envoy を起動する必要があります。つまり、静的ポッドを使用して Envoy を管理することはできません。これは、上記の Keepalived ホストの展開と同じ問題です。静的ポッドを使用すると、相互依存と論理デッドロックが発生します。鶏は卵が先だと言い、卵は鶏が先だと言います。結局、誰も望むものを手に入れることはできない。

IPVS を使用する場合は異なります。参加する前に IPVS ルールを設定し、参加してルールを保護できます。 apiserver にアクセスできなくなると、すべてのノード上の対応する IPVS ルールは自動的にクリアされ、マスターが通常の状態に戻ったときに再度追加されます。

kubeadm をカスタマイズする理由は何ですか?

まず、kubeadm は証明書の有効期限をハードコードしているため、これを 99 年にカスタマイズする必要があります。ほとんどの人は自分で新しい証明書に署名できますが、私たちは個別のツールに依存したくないので、ソースコードを変更するだけです。

次に、参加時に 2 つのことを行う必要があるため、ローカル ロードを実行するときに kubeadm コードを変更するのが最も便利です。 1 つ目は参加前に IPVS ルールを作成すること、2 つ目は静的ポッドを作成することです。 kubeadm をカスタマイズしないと、静的 Pod ディレクトリがすでに存在するというエラーが報告されます。このエラーを無視するのは賢明ではありません。そして、kubeadm は、この機能を実装するための非常に便利な SDK をいくつか提供しています。

これを実行すると、コア機能が kubeadm に統合され、sealos は上位レベルのコマンドを配布および実行するための軽量ツールになります。ノードを追加するときに、kubeadm を直接使用することもできます。

チュートリアル

依存関係をインストールする

  1. Dockerをインストールして起動する
  2. Kubernetesオフラインインストールパッケージをダウンロードする
  3. 最新のsealosバージョンをダウンロード
  4. Kubernetes 1.14.0+ のサポート
  5. サーバーの時間を必ず同期してください

インストール

マルチマスター HA の場合は、次のコマンドを実行します。

  1. $ シールの初期化--master 192.168.0.2 \  
  2. --マスター 192.168.0.3 \  
  3. --マスター 192.168.0.4 \  
  4. --node 192.168.0.5 \  
  5. --user ルート \  
  6. --passwd サーバーのパスワード \  
  7. --バージョン v1.14.1 \  
  8. --pkg-url /root/kube1.14.1.tar.gz  

そして、他には何もありません...はい、高可用性クラスターがインストールされました。混乱していると感じますか?とても簡単で早いです!

単一マスターと複数ノード:

  1. $ シールの初期化--master 192.168.0.2 \  
  2. --node 192.168.0.5 \  
  3. --user ルート \  
  4. --passwd サーバーのパスワード \  
  5. --バージョン v1.14.1 \  
  6. --pkg-url /root/kube1.14.1.tar.gz  

キーレスまたはキーペアを使用します:

  1. $ シールの初期化--master 172.16.198.83 \  
  2. --ノード 172.16.198.84 \  
  3. --pkg-url https://sealyun.oss-cn-beijing.aliyuncs.com/free/kube1.15.0.tar.gz \  
  4. --pk /root/kubernetes.pem # これはSSH秘密鍵ファイルです \  
  5. --バージョン v1.15.0  

パラメータの説明:

  1. --master マスターサーバーアドレスリスト 
  2. --node ノードサーバアドレスリスト 
  3. --user サーバーの SSH ユーザー名 
  4. --passwd サーバーの SSH ユーザーのパスワード 
  5. --pkg-url オフライン パッケージの場所。ローカル ディレクトリに配置することも、http サーバーに配置することもできます。sealos はインストール対象マシンに wget します。  
  6. --version Kubernetes バージョン 
  7. --pk ssh 秘密鍵アドレス。キーレス設定のデフォルト値は/root/.ssh/id_rsaです。  

その他のパラメータ:

  1. --kubeadm-config string kubeadm-config.yaml kubeadm設定ファイル、kubeadm設定ファイルをカスタマイズできます   
  2. --vip 文字列仮想 IP (デフォルトは「10.103.97.2」) は、ローカル ロードの仮想 IP です。変更することはお勧めしません。クラスターの外部からはアクセスできません。  

インストールが正常かどうかを確認します。

  1. $ kubectl ノードを取得
  2. 名前ステータス 役割 年齢 バージョン
  3. izj6cdqfqw4o4o9tc0q44rz マスター準備完了 2m25s v1.14.1
  4. izj6cdqfqw4o4o9tc0q44sz マスター 119s v1.14.1 準備完了
  5. izj6cdqfqw4o4o9tc0q44tz レディマスター 63s v1.14.1
  6. izj6cdqfqw4o4o9tc0q44uz 準備完了 <なし> 38 秒 v1.14.1
  7.  
  8. $ kubectl get pod --all-namespaces  
  9. 名前空間名準備完了 ステータス 再起動 年齢
  10. kube-system calico-kube-controllers-5cbcccc885-9n2p8 1/1 実行中 0 3分1秒
  11. kube-system calico-node-656zn 1/1 実行中 0 93秒
  12. kube-system calico-node-bv5hn 1/1 実行中 0 2分54秒
  13. kube-system calico-node-f2vmd 1/1 実行中 0 3分1秒
  14. kube-system calico-node-tbd5l 1/1 実行中 0 118 秒
  15. kube-system coredns-fb8b8dccf-8bnkv 1/1 実行中 0 3分1秒
  16. kube-system coredns-fb8b8dccf-spq7r 1/1 実行中 0 3分1秒
  17. kube-system etcd-izj6cdqfqw4o4o9tc0q44rz 1/1 実行中 0 2分25秒
  18. kube-system etcd-izj6cdqfqw4o4o9tc0q44sz 1/1 実行中 0 2分53秒
  19. kube-system etcd-izj6cdqfqw4o4o9tc0q44tz 1/1 実行中 0 118 秒
  20. kube-system kube-apiserver-izj6cdqfqw4o4o9tc0q44rz 1/1 実行中 0 2分15秒
  21. kube-system kube-apiserver-izj6cdqfqw4o4o9tc0q44sz 1/1 実行中 0 2m54s
  22. kube-system kube-apiserver-izj6cdqfqw4o4o9tc0q44tz 1/1 実行中 1 47 秒
  23. kube-system kube-controller-manager-izj6cdqfqw4o4o9tc0q44rz 1/1 実行中 1 2分43秒
  24. kube-system kube-controller-manager-izj6cdqfqw4o4o9tc0q44sz 1/1 実行中 0 2分54秒
  25. kube-system kube-controller-manager-izj6cdqfqw4o4o9tc0q44tz 1/1 実行中 0 63 秒
  26. kube-system kube-proxy-b9b9z 1/1 実行中 0 2m54s
  27. kube-system kube-proxy-nf66n 1/1 実行中 0 3分1秒
  28. kube-system kube-proxy-q2bqp 1/1 実行中 0 118 秒
  29. kube-system kube-proxy-s5g2k 1/1 実行中 0 93 秒
  30. kube-system kube-scheduler-izj6cdqfqw4o4o9tc0q44rz 1/1 実行中 1 2分43秒
  31. kube-system kube-scheduler-izj6cdqfqw4o4o9tc0q44sz 1/1 実行中 0 2m54s
  32. kube-system kube-scheduler-izj6cdqfqw4o4o9tc0q44tz 1/1 実行中 0 61 秒
  33. kube-system kube-sealyun-lvscare-izj6cdqfqw4o4o9tc0q44uz 1/1 実行中 0

ノードの追加

まず、join コマンドを取得し、マスター上で実行します。

  1. $ kubeadm トークン作成  --print-join-command  

super kubeadm を使用することもできますが、参加するときに --master パラメータを追加する必要があります。

  1. $ cd kube/shell && init.sh  
  2. $ echo "10.103.97.2 apiserver.cluster.local" >> /etc/hosts # vip を使用 
  3. $ kubeadm join 10.103.97.2:6443 --token 9vr73a.a8uxyaju799qwdjv \    
  4. --マスター 10.103.97.100:6443 \    
  5. --マスター 10.103.97.101:6443 \    
  6. --マスター 10.103.97.102:6443 \    
  7. --ディスカバリートークンCA証明書ハッシュsha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866  

sealos join コマンドを使用することもできます:

  1. $ アザラシ参加  --マスター 192.168.0.2 \  
  2. --マスター 192.168.0.3 \  
  3. --マスター 192.168.0.4 \  
  4. --vip 10.103.97.2 \  
  5. --node 192.168.0.5 \  
  6. --user ルート \  
  7. --passwd サーバーのパスワード \  
  8. --pkg-url /root/kube1.15.0.tar.gz  

カスタム kubeadm 構成ファイルの使用

たとえば、ドメイン名 sealyun.com を証明書に追加するなど、kubeadm 構成ファイルをカスタマイズする必要がある場合があります。

まず、構成ファイル テンプレートを取得する必要があります。

  1. $ sealos config -t kubeadm >> kubeadm-config.yaml.tmpl

次に、kubeadm-config.yaml.tmpl を変更し、sealyun.com を構成に追加します。

  1. APIバージョン: kubeadm.k8s.io/v1beta1
  2. 種類: ClusterConfiguration
  3. kubernetes バージョン: {{.Version}}
  4. コントロールプレーンエンドポイント: "apiserver.cluster.local:6443"  
  5. ネットワーキング:
  6. ポッドサブネット: 100.64.0.0/10
  7. apiサーバー:
  8. certSAN:
  9. - sealyun.com # これは私が追加したものです
  10. - 127.0.0.1
  11. -apiserver.cluster.local  
  12. {{範囲 .マスターズ -}}
  13. - {{.}}
  14. {{終わり-}}
  15. - {{.VIP}}
  16. ---  
  17. APIバージョン: kubeproxy.config.k8s.io/v1alpha1
  18. 種類: KubeProxyConfiguration
  19. モード: "ipvs"  
  20. IPvs:
  21. 除外CIDR:
  22. - 「{{.VIP}}/32」  

注: 他の部分を変更する必要はありません。sealos がテンプレートのコンテンツを自動的に入力します。

最後に、--kubeadm-config を使用して、デプロイ中に構成ファイル テンプレートを指定します。

  1. $ sealos init --kubeadm-config kubeadm-config.yaml.tmpl \  
  2. --マスター 192.168.0.2 \  
  3. --マスター 192.168.0.3 \  
  4. --マスター 192.168.0.4 \  
  5. --node 192.168.0.5 \  
  6. --user ルート \  
  7. --passwd サーバーのパスワード \  
  8. --バージョン v1.14.1 \  
  9. --pkg-url /root/kube1.14.1.tar.gz  

バージョンアップグレード

このチュートリアルでは、バージョン 1.14 から 1.15 へのアップグレードを例に説明します。他のバージョンの原理も同様です。これを理解したら、公式チュートリアルを参照してください。

アップグレードプロセス

  1. kubeadmをアップグレードし、すべてのノードにイメージをインポートします。
  2. コントローラーノードのアップグレード
  3. マスター(コントロールノード)でkubeletをアップグレードする
  4. 他のマスター(制御ノード)をアップグレードする
  5. ノードのアップグレード
  6. クラスターのステータスを確認する

kubeadm のアップグレード

オフライン パッケージをすべてのノードにコピーし、cd kube/shell && sh init.sh を実行します。ここで、kubeadm、kubectl、kubelet のバイナリ ファイルが更新され、より高いバージョンのイメージがインポートされます。

コントローラーノードのアップグレード

  1. $ kubeadm アップグレードプラン 
  2. $ kubeadm アップグレード v1.15.0 を適用

kubelet を再起動します。

  1. $ systemctl kubeletを再起動します

実際、kubelet のアップグレードは非常に単純かつ大まかです。新しいバージョンの kubelet を /usr/bin にコピーし、kubelet サービスを再起動するだけです。プログラムが使用中で上書きが許可されていない場合は、kubelet を停止してからコピーしてください。 kubelet bin ファイルは conf/bin ディレクトリにあります。

他の制御ノードをアップグレードします。

  1. $ kubeadm アップグレードを適用

ノードのアップグレード

ノードを削除します (状況によって異なりますが、必要に応じて直接実行できます)。

  1. $ kubectl ドレイン $NODE --ignore-daemonsets  

kubelet 設定を更新します。

  1. $ kubeadm ノード構成をアップグレード--kubelet-version v1.15.0  

次に、kubelet をアップグレードします。また、バイナリを置き換えて、kubelet サービスを再起動します。

  1. $ systemctl kubeletを再起動します

失われた愛を思い出す:

  1. $ kubectl の $NODE を解除します

確認する

  1. $ kubectl ノードを取得する

バージョン情報が正しければ、アップグレードは基本的に成功します。

kubeadm upgrade apply は何をしますか?

  1. クラスターをアップグレードできるかどうかを確認する
  2. バージョンアップグレード戦略を実行して、どのバージョンをアップグレードできるかを決定します。
  3. 画像が存在するかどうかを確認する
  4. 制御コンポーネントのアップグレードを実行し、失敗した場合はロールバックします。制御コンポーネントは、実際には apiserver、コントローラー マネージャー、スケジューラーなどのコンテナーです。
  5. kube-dns と kube-proxy をアップグレードする
  6. 新しい証明書ファイルを作成し、180日以上経過している場合は古い証明書ファイルをバックアップします。

ソースコードのコンパイル

netlink ライブラリが使用されるため、次の 1 つのコマンドのみを使用してコンテナー内でコンパイルすることをお勧めします。

  1. $ docker run --rm -v $GOPATH/src/github.com/fanux/sealos:/go/src/github.com/fanux/sealos -w /go/src/github.com/fanux/sealos -it golang:1.12.7 go build  

go mod を使用している場合は、ベンダーコンパイルを指定する必要があります。

  1. $ go build -mod ベンダー

アンインストール

  1. $ シールズクリーン \
  2. --マスター 192.168.0.2 \  
  3. --マスター 192.168.0.3 \  
  4. --マスター 192.168.0.4 \  
  5. --node 192.168.0.5 \  
  6. --user ルート \  
  7. --passwd サーバーのパスワード 

シーロス実装原則

実行プロセス

  • オフライン インストール パッケージを sftp または wget 経由でターゲット マシン (マスターとノード) にコピーします。
  • master0 で kubeadm init を実行します。
  • 他のマスターで kubeadm join を実行し、コントロール プレーンを設定します。このプロセスは、他のマスターで etcd を起動し、master0 の etcd とクラスターを形成し、コントロール プレーンのコンポーネント (apiserver、コントローラーなど) を起動します。
  • ノードに参加し、ノード上で IPVS ルールと /etc/hosts を構成します。

ノードは仮想 IP を介して複数のマスターに接続する必要があるため、apiserver へのすべてのリクエストはドメイン名を介してアクセスされます。 apiserver にアクセスするための各ノードの kubelet と kube-proxy の仮想アドレスは異なり、kubeadm は構成ファイルで 1 つのアドレスしか指定できないため、ドメイン名が使用されますが、各ノードによって解決される IP は異なります。 IP アドレスが変更された場合は、解決アドレスを変更するだけで済みます。

ローカルカーネル負荷

このようにして、各ノードはローカル カーネル ロード バランシングを通じてマスターにアクセスできます。

  1. + ----------+ +--------------+ 仮想 URL サーバー: 127.0.0.1:6443  
  2. |母0 |< -----------------------| ipvs ノード |実サーバー:  
  3. + ----------+ |+--------------+ 10.103.97.200:6443  
  4. | 10.103.97.201:6443
  5. + ----------+ | 10.103.97.202:6443  
  6. |マテリアル1 |< -----------+  
  7. + ----------+ |  
  8. |
  9. + ----------+ |  
  10. | mater2 |< ---------------------+  
  11. + ----------+  

IPVS を保護するために、ノード上で LVScare の静的ポッドが開始されます。 apiserver にアクセスできなくなると、すべてのノード上の対応する IPVS ルールは自動的にクリアされ、マスターが通常の状態に戻ったときに再度追加されます。

ノードに次の 3 つの項目を追加すると、直感的にわかります。

  1. $ cat /etc/kubernetes/manifests # ここで、 LVScareの静的ポッドが追加されます
  2. $ ipvsadm -Ln # 作成されたIPVSルールを確認できます
  3. $ cat /etc/hosts #仮想IPアドレス解決を追加しました

kubeadm のカスタマイズ

sealos は kubeadm にほとんど変更を加えず、主に証明書の有効期限を延長し、join コマンドを拡張しました。以下では主に join コマンドの変換について説明します。

まず、マスター アドレス リストを指定するために、join コマンドに --master パラメータを追加します。

  1. lagSet.StringSliceVar() は、
  2. &locallb.LVScare.Masters, "マスター" , []文字列{},
  3. 「ha マスターのリスト、--master 192.168.0.2:6443 --master 192.168.0.2:6443 --master 192.168.0.2:6443」

この方法で、IPVS ロード バランシングを実行するためのマスター アドレス リストを取得できます。

制御ノードでも単一のマスターでもない場合は、IPVS ルールのみを作成します。コントロール ノード上に作成する必要はなく、独自の apiserver に接続するだけです。

  1. data.cfg.ControlPlane == nilの場合{
  2. fmt.Println( "これは制御計画ではありません" )
  3. len(locallb.LVScare.Masters) != 0 の場合 {
  4. locallb.CreateLocalLB(引数[0])
  5. }
  6. }

次に、IPVS を保護するために lvscare 静的ポッドを作成します。

  1. len(locallb.LVScare.Masters) != 0 の場合 {
  2. locallb.LVScareStaticPodToDisk( "/etc/kubernetes/manifests" )
  3. }

そのため、sealos を使用しない場合でも、カスタマイズされた kubeadm を直接使用してクラスターをデプロイできますが、少し面倒です。インストール手順は以下の通りです。

kubeadm 構成ファイル:

  1. APIバージョン: kubeadm.k8s.io/v1beta1
  2. 種類: ClusterConfiguration
  3. kubernetesバージョン: v1.14.0
  4. controlPlaneEndpoint: "apiserver.cluster.local:6443" # apiserver の DNS 
  5. apiサーバー:
  6. certSAN:
  7. - 127.0.0.1
  8. -apiserver.cluster.local  
  9. - 172.20.241.205
  10. - 172.20.241.206
  11. - 172.20.241.207
  12. - 172.20.241.208
  13. - 10.103.97.1 # 仮想URL IP
  14. ---  
  15. APIバージョン: kubeproxy.config.k8s.io/v1alpha1
  16. 種類: KubeProxyConfiguration
  17. モード: "ipvs"  
  18. IPvs:
  19. 除外CIDR:
  20. - "10.103.97.1/32" # このkube-proxyを追加しないとルールがクリーンアップされることに注意してください

master0 で次のコマンドを実行します (vip アドレスが 10.103.97.100 であると仮定)。

  1. $ echo "10.103.97.100 apiserver.cluster.local" >> /etc/hosts # 解析されたアドレスはmaster0です 
  2. $ kubeadm init --config=kubeadm-config.yaml --experimental-upload-certs    
  3. $ mkdir ~/.kube && cp /etc/kubernetes/admin.conf ~/.kube/config  
  4. $ kubectl apply -f https://docs.projectcalico.org/v3.6/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml

master1 で次のコマンドを実行します (vip アドレスが 10.103.97.101 であると仮定)。

  1. $ echo "10.103.97.100 apiserver.cluster.local" >> /etc/hosts #解析されたアドレスはmaster0なので、通常通り参加する
  2. $ kubeadm join 10.103.97.100:6443 --token 9vr73a.a8uxyaju799qwdjv \  
  3. --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 \  
  4. --実験的コントロールプレーン \  
  5. --証明書キー f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07  
  6.  
  7. $ sed "s/10.103.97.100/10.103.97.101/g" -i /etc/hosts # 解析して自分のアドレスに置き換えます。そうしないと、すべてが ma に依存します。

master2 で次のコマンドを実行します (vip アドレスが 10.103.97.102 であると仮定)。

  1. $ echo "10.103.97.100 apiserver.cluster.local" >> /etc/hosts
  2. $ kubeadm join 10.103.97.100:6443 --token 9vr73a.a8uxyaju799qwdjv \  
  3. --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 \  
  4. --実験的コントロールプレーン \  
  5. --証明書キー f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07  
  6.  
  7. $ sed "s/10.103.97.100/10.103.97.102/g" -i /etc/hosts

ノードに参加するときは、--master パラメータを追加してマスター アドレス リストを指定します。

  1. $ echo "10.103.97.1 apiserver.cluster.local" >> /etc/hosts # 仮想 IP に解決する必要があります
  2. $ kubeadm join 10.103.97.1:6443 --token 9vr73a.a8uxyaju799qwdjv \  
  3. --マスター 10.103.97.100:6443 \  
  4. --マスター 10.103.97.101:6443 \  
  5. --マスター 10.103.97.102:6443 \  
  6. --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720  

オフラインパッケージ構造分析

  1. ├── bin #binファイルのバージョンを指定します。必要なのはこの3つだけです。その他のコンポーネントはコンテナ内で実行されます。
  2. │ ├── kubeadm
  3. │ ├── kubectl
  4. │ └── クベレット
  5. ├── 会議
  6. │ ├── 10-kubeadm.conf # このファイルは新しいバージョンでは使用されません。 cgroup ドライバーを検出できるように、シェル内で直接生成します。
  7. │ ├── ダッシュボード
  8. │ │ ├── ダッシュボード管理者.yaml
  9. │ │ └── kubernetes-dashboard.yaml
  10. │ ├── ヒープスター
  11. │ │ §── grafana.yaml
  12. │ │ ├── ヒープスター.yaml
  13. │ │ ├── influxdb.yaml
  14. │ │ └── rbac
  15. │ │ └── heapster-rbac.yaml
  16. │ ├── kubeadm.yaml # kubeadm の設定ファイル
  17. │ ├── kubelet.service # kubelet systemd 設定ファイル
  18. │ ├── ネット
  19. │ │ └── calico.yaml
  20. │ └── プロメサス
  21. ├── images # すべての画像パッケージ
  22. │ └── 画像.tar
  23. └── シェル
  24. ├── init.sh # 初期化スクリプト
  25. └── master.sh # マスタースクリプトを実行する
  • init.sh スクリプトは、bin ディレクトリ内のバイナリ ファイルを $PATH にコピーし、systemd を構成し、スワップやファイアウォールをオフにするなどして、クラスターに必要なイメージをインポートします。
  • master.sh は主に kubeadm init を実行します。
  • conf ディレクトリには、kubeadm 構成ファイル、calico yaml ファイルなどが含まれています。
  • sealos は上記の 2 つのスクリプトを呼び出すため、そのほとんどは互換性があります。スクリプトを微調整することで、異なるバージョン間の互換性を保つことができます。

<<:  セキュリティを犠牲にすることなくDevOpsをクラウドに移行する方法

>>:  最新のクラウド コンピューティング セキュリティのベスト プラクティスを適用する方法

推薦する

クラウドは「エッジ」になっていますか?エッジクラウドコンピューティングがクラウド戦略に与える長期的な影響を分析する

新しい技術用語が継続的に出現することは避けられませんが、現在最も人気のある用語はエッジ コンピューテ...

2022 年に避けるべきクラウド コスト最適化の 6 つの間違いとその修正方法

翻訳者 |李睿校正 |孫淑娟 梁策企業や組織は毎年末に、事業規模の拡大やクラウドコストの削減など、翌...

SEO共有: ウェブサイトのSEOに影響を与えるいくつかのアクション

現在、多くの初心者は、セクションや機能の追加、URL構造の変更など、Webサイトの関連情報の変更に注...

毎日の話題: アリ・マイクロファイナンスの資本構成と2万人の従業員が株式を共有

11月4日のウェブマスターネットワーク(www.admin5.com)によると、アリババは最近、アリ...

エッジコンピューティングの種類と用途

エッジ コンピューティングは、スーパー クラウド コンピューティングの次のステップです。データ需要が...

ネットワーク情報保護に関する決議が可決:国務院は規制を精緻化する

昨日、第11期全国人民代表大会常務委員会第30回会議で投票が行われ、ネットワーク情報の保護強化に関す...

hostyun の月額 18 元の香港 VPS (米国ネイティブ IP、100M 帯域幅、AMD 5950X) の簡単なレビュー

Hostyunは最近、香港のクラウドデータセンターに「[Hong Kong AMD-Puhui]」と...

Java JVM の秘密を解明

この記事では、JVM メモリ モデル、クラス ローダー、GC 回復アルゴリズム、GC コレクターなど...

racknerd: 中秋節 VPS 割引、年間 9.89 ドル、512M メモリ/1 コア/10g SSD/1T トラフィック/ロサンゼルス

racknerd は、ロサンゼルスの multacom データ センター (DC-02) に設置され...

バナー広告のクリック率を向上させる 14 のデザイン提案

インターネットは急速に発展していますが、バナーを使用して商品を宣伝することが依然として最善の方法です...

検索結果で上位にランクインする方法

世界最高のギターのウェブサイトをデザインしている自分を想像してみてください。このサイトには、さまざま...

ウェブマスターがソフト記事リンクを正しく理解する方法の簡単な分析

ウェブマスター業界でソフト記事が人気を博すにつれ、刷新されたソフト記事チェーンも登場しました。新世代...

友好的なリンク交換で見落としがちな重要な指標を分析する: PR出力値

こんな風に感じたことはありませんか。Baidu で何かや質問を検索したとき、返される結果が満足のいく...

トルコのサーバー: zenlayer、イスタンブールデータセンター、30%割引、10Gbpsの帯域幅、カスタム構成のサポート、

Zenlayerはトルコに独自のデータセンターを持ち、トルコのクラウドサーバー、トルコの独立サーバー...

キーワードランキングが不安定な場合の対処法

みなさんこんにちは。私はHongtu Internetです。 2 か月前、下水道ウェブサイトの最適化...