Kubernetes の簡単な紹介と独自のクラスターの構築

このブログの本来の目的は、Kubernetes クラスターをゼロから構築する方法を説明することです。しかし、私はこう考えました。この記事を読んでも、何が得られるのだろう?手順を一つずつ実行するだけですか?私だったら拒否すると思いますので、Kubernetes の簡単な紹介と各ステップの説明を追加しました。スペースと時間の都合上、Kubernetes のよりコアなポッドとサービスのみを紹介しました。

[[399050]]

記事の前半では Kubernetes について簡単に紹介し、後半ではゼロからゆっくりとクラスターを構築する方法を紹介します。

Kubernetesとは

Kubernetes は、2014 年に Google によってオープンソース化された、プロダクション レベルのコンテナ オーケストレーション システム、またはマイクロサービスとクラウド ネイティブ プラットフォームです。Kubernetes は 2014 年にオープンソース化されたばかりですが、実際には Google 社内のコンテナ オーケストレーション システムである Borg のオープンソース バージョンであり、Google 社内で 10 年以上使用されています。ここで、Kubernetes ロゴの起源についてのちょっとしたお話をします。

Kubernetes は 2014 年に Google によって初めて発表されました。その開発と設計は Google の Borg システムから大きな影響を受けており、Kubernetes の主要な貢献者の多くは以前は Borg システムの開発者でした。 Google 社内では、Kubernetes の元のコード名は「スタートレック」のフレンドリーなボーグ族のキャラクターにちなんで「Seven」でした。 Kubernetes ロゴの 7 本スポークのステアリングホイールは、プロジェクトのコード名を表しています。

しかし、Docker のロゴはコンテナを運ぶクジラ、つまり輸送船であり、Kubernetes のロゴは舵であり、Docker (あるいはコンテナ技術) を遠くまで導くことを目指しているという言い伝えもあります。

Kubernetesの簡単な紹介

私は多くの公式記事を読みましたが、それらは本当に公式のものです。公式が言いたいのは、見た後でも見ていないのとほとんど同じで、何も分からないままになる可能性があるということです。

そこで、ドキュメントを読んでもまだ Kubernetes を理解していない人や、まったく理解したことがない人を助けるために、このような記事を書きたいと思いました。では、Kubernetes の本来の定義に戻りましょう。Kubernetes はマイクロサービス フレームワークです。

マイクロサービス フレームワークに関して言えば、業界で最も主流のマイクロサービス フレームワークについて言及する必要があります。よく知っているフレームワークと比較することで、Kubernetes で何ができるかが明確にわかります。現在、主流のマイクロサービス フレームワークとプラットフォームには、Spring Cloud、Dubbo、Kubernetes などがあります。

Spring Cloud は Netflix から、Dubbo は Alibaba から、Kubernetes は Google から提供されています。より直感的に言えば、これら 3 つのフレームワークはマイクロサービス向けのソリューションです。 Kubernetes はコンテナ オーケストレーション システムではないのかと疑問に思う人もいるかもしれません。 Spring Cloud のようなソフトウェア レベルのマイクロサービス フレームワークとどのように比較できますか?

慌てないで、友よ。この概念をゆっくり掘り下げてみましょう。

マイクロサービスを使用する必要がある場合、サービス登録と検出、負荷分散、ログ監視、構成管理、クラスターの自己修復とフォールト トレランス、弾性スケーリングなどの基盤となるインフラストラクチャのサポートが必要であることは誰もが知っています。これらのコンポーネントはすべてマイクロサービスの共通の懸念事項として総称できるため、すべてをリストしたわけではありません。では、これらの機能を提供できる限り、マイクロサービス フレームワークであると言えるのでしょうか?

上記の機能のほとんどは Kubernetes に組み込まれています。したがって、Kubernetes は Docker Swarm に似たコンテナ オーケストレーション システムであると言えますが、Kubernetes にはマイクロサービス ソリューションが組み込まれているため、フル機能のマイクロサービス フレームワークでもあります。

ポッドのコンセプト

Docker Swarm では最小のスケジューリング単位はコンテナですが、Kubernetes では最小のスケジューリング単位は Pod です。では、ポッドとは何でしょうか?

Pod は Kubernetes によって設計されたまったく新しい概念です。英語での本来の意味は、クジラの群れ、またはエンドウ豆のさやです。つまり、Pod は 1 つ以上のコンテナを実行できます。

クラスターでは、Kubernetes は各ポッドにクラスター内の一意の IP アドレスを割り当てます。 Kubernetes では、クラスター内の任意のノード上の 2 つの Pod 間の直接通信をサポートするために、基盤となるネットワークが必要になるためです。これらのコンテナは、現在の Pod のファイル システムとネットワークを共有します。これらのコンテナを共有できる理由は、Pod 内に Pause というルート コンテナがあり、残りのユーザー業務コンテナはこのルート コンテナの IP とボリュームを共有しているためです。したがって、これらのコンテナは localhost を介して通信できます。

なぜルート コンテナの概念を導入する必要があるのか​​と疑問に思う人もいるかもしれません。ルートコンテナがない場合、複数のコンテナが Pod に導入されたときに、どのコンテナのステータスを使用して Pod のステータスを判別すればよいですか?そのため、業務とは関係がなく障害が発生しにくい一時停止コンテナをルートコンテナとして導入し、ルートコンテナのステータスを利用してコンテナ全体のステータスを表す必要があります。

Spring Cloud やマイクロサービスに精通している人なら誰でも、マイクロサービスにおける最大のタブーは単一ポイントの出現であることを知っています。

したがって、通常は同じサービスに対して 2 つ以上のインスタンスをデプロイします。 Kubernetes では、複数の Pod レプリカがデプロイされ、外部サービスを提供するために Pod クラスターが形成されます。

前述したように、Kubernetes は各 Pod に一意の IP アドレスを提供し、クライアントは各 Pod の一意の IP + コンテナ ポートを介して特定の Pod にアクセスする必要があります。このように、クライアントが呼び出しアドレスをハードコードすると、サーバーは負荷分散を実行できなくなります。さらに、Pod を再起動すると IP アドレスが変更されます。クライアントが再起動されるたびに、IP の変更をクライアントに通知する必要があるということですか?

この問題を解決するには、サービスという概念を導入する必要があります。

サービス

サービスは Kubernetes のコア リソース オブジェクトの 1 つであり、上記の問題を解決するために使用されます。個人的には、Swarm のサービス コンセプトと大きな違いはないと思います。

サービスが作成されると、Kubernetes は ClusterIP と呼ばれるクラスター内の一意の IP を割り当てます。ClusterIP はサービスのライフサイクル全体を通じて変更されません。このように、Docker Swarm と同様の操作を使用して、ClusterIP からサービス名への DNS ドメイン名のマッピングを確立できます。

ClusterIP は ping できない仮想 IP アドレスであり、Kubernetes クラスター内でのみ使用されることに注意してください。

サービスは、基盤となるポッドのアドレス指定プロセスからクライアントを保護します。そして、kube-proxy プロセスは、特定のスケジューリング アルゴリズムによって決定される特定の Pod にサービスに対するリクエストを転送します。このようにして、負荷分散が実現されます。

サービスはどのようにしてポッドを見つけるのでしょうか?これには、もう 1 つのコア概念であるラベルの導入が必要です。

ラベル

ラベルは基本的にキーと値のペアであり、具体的な値はユーザーによって決定されます。ラベルは、ポッドまたはサービスに追加できるタグです。要約すると、ラベルとラベル付けされたリソースの間には 1 対多の関係が存在します。

たとえば、上記の Pod に role=serviceA というラベルを付ける場合、Service のラベル セレクターにラベルを追加するだけで済みます。このようにして、サービスはラベルセレクターを通じて同じラベルを持つポッドレプリカセットを見つけることができます。

次に、Kubernetes の他のコアコンセプトについて簡単に紹介します。

レプリカセット

上記では複数の Pod をデプロイすることについて説明しました。それは何についてですか? Kubernetes にはもともと Replication Controller という概念がありましたが、現在は Replica Set に徐々に置き換えられています。 RSは次世代RCとも呼ばれます。簡単に言えば、レプリカ セットは予想されるシナリオを定義し、クラスター内の Pod コピーの数が常に予想される値を満たすことを保証します。

クラスターは作成されると、現在稼働中のポッドの数を定期的にチェックします。それ以上ある場合、クラスターは一部のポッドを停止します。逆に、数が少ない場合は、いくつかの Pod が作成されます。この方法でどのような問題を回避できるでしょうか?サービスで 2 つのインスタンスが実行されていて、そのうちの 1 つが予期せずクラッシュしたとします。レプリカの数を 2 に設定すると、クラスターは自動的にポッドを作成し、クラスター内で常に 2 つのポッドが実行されるようになります。

Kubernetes について私が言いたいことはこれだけです。それでは、クラスターの構築に移りましょう。

Kubernetes構築の準備

どのブログ投稿から始めればいいのか分かりません。私はこのような純粋な TODO タイプのブログ投稿を書く気はあまりありませんが、自分で試してみたところ、私のブログはこれまで見た中で最もシンプルなものであることがわかりました。

私が見たいくつかのインストールは多くの状況に分かれていますが、初心者が見ると混乱する可能性があります。したがって、次のインストールは少々ハードコアなものになるでしょう。状況がどうであれ、状況は一つだけ、シャトル一つで設置するだけで完了です。

• システムバージョン Ubuntu 18.04
• Kubernetes バージョン v1.16.3
• Docker バージョン v19.03.5
• フランネルバージョン v0.11.0

私に言わせれば、記事をどのマシンも読まなかったら、独自のクラスターを持つことができるのでしょうか?

準備

まず、以下の状況が成り立つと仮定します。

マシン: 2～3 台の物理マシンまたは仮想マシン

システム: Ubuntu 18.04 と国内ソースが置き換えられました

上記が当てはまらない場合は、この記事はここで終了します。ご視聴ありがとうございました。

[[399051]]

Dockerをインストールする

いろいろな状況を紹介する必要はありません。マシンに直接ログインし、たとえば install_docker.sh というシェル スクリプトを作成します。コードは次のとおりです。

 sudo apt-getアップデート 
 sudo apt-get install -y apt-transport-https ca-certificates
 curl gnupg-agent ソフトウェアプロパティ共通
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-キー 追加-
 sudo apt-キーフィンガープリント 0EBFCD88
 sudo add -apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"  
 sudo apt-getアップデート 
 sudo apt-get -y インストール docker-ce docker-ce-cli containerd.io

次に、sh install_docker.sh を実行し、コマンドが完了するまで待ってから、Docker がインストールされているかどうかを確認します。 docker + Enter と入力するだけです。

Kubernetesをインストールする

同様に、install_k8s.sh などの新しいシェル スクリプトを作成します。シャトルコードは次のとおりです。

 sudo curl -s https://packages.cloud.google.com/apt/doc/apt-key .gpg | sudo apt -キー 追加-
 sudo apt-getアップデート 
 cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
 deb https://apt.kubernetes.io/kubernetes-xenial main
終了
sudo apt-get install -y kubelet kubeadm kubectl --allow-unauthenticated  

次に、sh install_k8s.sh を実行し、コマンドが完了するまで待ってから、Kubernetes がインストールされているかどうかを確認します。 kubectl + Enter と入力するだけです。

スワップを閉じる

設置作業をしている古い友人を遅らせないように、まずシャトルを配ってください。なぜ閉鎖されているのかについては後ほどお話しします。

• 一時的にシャットダウンするには、sudo swapoff -a コマンドを直接使用しますが、再起動後に有効になります。これにより、Kubernetes が適切に実行されなくなります。
• 永久に閉じるには、一度だけ実行することをお勧めします。 sudo vim /etc/fstab は swap.img の行をコメントアウトして保存します。

では、スワップとは何でしょうか?これはシステムのスワップ パーティションであり、仮想メモリと考えることができます。システムメモリが不足している場合は、ハードディスク領域の一部がメモリとして仮想化されて使用されます。では、Kubernetes はなぜこれをオフにする必要があるのでしょうか?下の図からメモリとハードディスクのアクセス速度の違いがわかります。

一般に、パフォーマンス上の理由から、スワップを有効にしないことが必要です。 Kubernetes は、すべてのサービスがクラスターまたはノードの CPU およびメモリの制限を超えないことを望んでいます。

マスターノードを初期化する

この時点で準備は完了しており、Kubernetes マスター ノードのインストールを開始し、マスター ノードとして機能するマシンにログインできます。

ホスト名の設定

いつものように、最初にコマンドを与え、次になぜそれを設定する必要があるのか​​を説明します。

sudo hostnamectl set-hostname マスターノード

ホスト名をカスタマイズすると、後でクラスター内のノードを表示するときに、各ノードの名前に Kubernetes によって自動的に生成された名前が表示されなくなり、表示しやすくなり、覚えやすくなります。たとえば、他のノード ノードで master-node を slave-node-1 または worker-node-2 に変更すると、次の効果が得られます。

クラスターを初期化する

マシン上で次のコマンドを実行します。

 sudo kubeadm init --pod-network-cidr=10.244.0.0/16  

次に、ギターを手に取って、コマンドが実行されるのを待ちます。

ここでは特別な注意を払う必要があります。このコマンドを実行すると、kubeadm join を含むコマンドが出力されます。これを保存する必要があります。

おそらく次のようになります:

• kubeadm join yourIPaddress:6443 --token yourTOKEN --discovery-token-ca-cert-hash sha256:yourCAcertificatehash

名前が示すように、このコマンドは他のノードをクラスターに参加させるために使用され、トークンには時間制限があり、有効期限は通常 86400000 ミリ秒です。

失敗した場合は、再生成する必要があります。本当に保存しておらず、再度失敗した場合...まだ 2 つの解決策があります。コマンドが保存されている場合は、これら 2 つの対策をスキップします。

トークン。 Kubeadm トークン リスト コマンドを使用して取得します。

ca-cert.コマンドを実行

openssl x509 -pubkey - /etc/kubernetes/pki/ca.crt内| openssl rsa -pubin -outform der 2>/dev/ null | openssl dgst -sha256 -hex | 's/^.* //' をsed します 

取得します。

一般ユーザーでも実行可能

次のコマンドを実行するだけです:

 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config

主にトラブル回避のため、コントロールノード上でkubectlなどのコマンドを実行する際は毎回sudoを使用する必要はありません。

ネットワーク通信プラグインのインストール

次のコマンドを実行して、ネットワーク プラグイン Flannel をインストールします。

 sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Flannel がインストールされていない場合、先ほど初期化したマスター ノードは NOT_READY ステータスになることがわかります。インストール後、 kubectl get nodes コマンドを使用してすべてのノードのステータスを表示できます。 kubectl get pods --all-namespaces を使用して、現在のクラスター内のすべての Pod のステータスを表示することもできます。ここで注意すべき点は、次のステップは、マスターノードが READY になり、すべてのポッドのステータスが RUNNING になった後にのみ実行できるということです。

ネットワーク プラグインをインストールする理由は何ですか?

これは、Kubernetes ではクラスター内のすべてのノード間の Pod ネットワークが相互接続されている必要があるためです。つまり、Flannel では、クラスター内の異なるノード上のコンテナーが現在のクラスター内で一意の仮​​想 IP アドレスを持つことができるようになります。このようにして、ノード間のポッド間の直接通信が可能になります。

このようにして、複雑なネットワーク通信は、2 つの IP アドレス間の通信に簡単に変換されます。これは主に仮想レイヤー 2 ネットワークを通じて実現されます。このノード上の Pod は別のノード上の Pod と直接通信し、最終的にはノードの物理ネットワーク カードを介して流出するようです。

スレーブノードがクラスターに参加する

この時点で、単一ポイント クラスターが構築されました。ここで必要なのは、別の準備したサーバーにログインすることです (私の場合は 2 台だけですが、3 台または 4 台ある場合は、このセクションを数回繰り返します)。

ホスト名の設定

次のコマンドを実行します。

 sudo hostnamectl set -hostname スレーブノード

現在のノードはマスターではないため、ホスト名は slave-node に設定されます。

クラスターへの参加

ここがポイントです。前のセクションで生成された kubeadm join コマンドを実行するだけです。実行が完了したら、マスターノードで kubectl get nodes コマンドを使用して、スレーブノードがクラスターに参加したことを確認できます。

スレーブノードに対する操作はありません。