K8S関連の知識を徹底的に理解する

その名前は多くの人が知っていると思いますが、Docker との関係を区別できず、何に使用され、どのような問題を解決するのに役立つかを理解していない人も多くいます。今日は詳しく説明します。

K8S、正式名称は kubernetes です。 Kubernetes という単語は、操舵手または航海士を意味するギリシャ語に由来しています。 K8S はその略称で、「ubernete」の 8 文字を「8」に置き換えたものなので、一般的には k8s と呼ばれます。 Docker とは異なり、K8S の作成者は有名な業界大手の Google であり、K8S はまったく新しい発明ではありません。その前身は、Google が 10 年以上にわたって改良を続けてきた Borg システムでした。 K8S は 2014 年 6 月に Google によって正式に発表され、オープンソース化されました。

k8sとdockerの関係とは

Docker の人気が急激に高まり、ますます多くの企業や開発者がビジネスを Docker コンテナ プラットフォームに移行していることは周知の事実です。その結果、多くの人が、自社の業務用の 1 つの Docker コンテナでは現在のニーズをまったく満たすことができないという問題を発見しました。このとき、まず最初に考えるのは、サーバーを追加し、各サーバーに Docker コンテナをインストールすることです。サービスの分割がそれほど多くない場合は、これで現在の問題は解決できます。しかし、マイクロサービスが数百ある場合、従来の方法で Docker を管理するのは非常に困難になります。このとき、すべての Docker コンテナを統一的に管理できるプラットフォームが存在するかどうか疑問に思うかもしれません。はい、k8s はコンテナ サービス用に生まれたポータブルなコンテナ オーケストレーション管理ツールです。ますます多くの企業が k8s を採用しており、現在、k8s はクラウド ビジネス プロセスを支配し、マイクロサービス アーキテクチャなどの一般的なテクノロジーの普及と実装を促進しています。

簡単に言えば、k8s は Docker コンテナを管理するために使用されます。以前は、コンテナを作成するために docker を直接呼び出してコンテナを実行していました。 docker がますます強力になるにつれて、それを維持することが非常に困難になります。現在 30 を超えるサービスがあるとします。コンテナ オーケストレーション ツールを使用しない場合は、各サービスが占めるスペースと、Docker コンテナがデプロイするサービスの数を計算する必要があります。これらは事前に計算する必要があります。ただし、システム トラフィックが増加し続けると、4 GB の実行メモリを 8 GB に調整する必要がある場合があります。その場合、以前のノードだけでは明らかに不十分であり、新しいマシンに手動で展開する必要があります。 k8s を使用する場合は、新しいノードを k8s クラスターに追加するだけで、残りの作業は k8s が行います。

k8sは何ができるのか

バージョンロールバック

どのようなプログラムにもバグがある可能性があることは誰もが知っています。新しくリリースされたプログラムバージョンに問題があることが判明した場合、すぐに元のバージョンにロールバックできます。

サービスの自己修復

K8s にはデフォルトで監視および検査のメカニズムが備わっています。簡単に言えば、サービスのポートを継続的にカールし、ポートがブロックされているか、その他の異常な問題があるかを検出します。コンテナがクラッシュしても、新しいコンテナをすぐに起動できます。

弾性スケーリング

特定のサービスへのトラフィックが多くなり、ノードがビジネス リクエストを正常に処理できなくなった場合は、ポッドの数を動的に調整して容量を拡張できます。特定のサービスへのトラフィックが高くない場合は、ポッドの数を減らして動的な容量拡張を実現できます。さらに、k8s では、たった 1 つのコマンドで容量の拡張と削減を非常に簡単に実現できます。

負荷分散

サービスのトラフィック量が多い場合は、1 つのサービスに対して複数のコンテナを起動するのと同じです。従来の方法だとnginx系の負荷分散ミドルウェアも使わなければなりませんが、k8sを使えばリクエストの負荷分散も自動的に実現できます。

ストレージボリュームのマウント

プロジェクトでファイルを保存するために nfs またはその他のファイル システムを使用する場合は、k8s でストレージ ボリュームを直接作成し、nfs をマウントできます。私たちのサービスはマイクロサービス プロジェクトであり、ファイル ストレージ システムとファイル分析システムは 2 つのサービスであるのが一般的です。この時点で、nfs をマウントすることができ、2 つのサービスは同じファイル システム効果を使用します。

k8sの基本的なアーキテクチャを紹介します

k8s クラスターは主に制御ノード (マスター) と作業ノード (ノード) で構成され、各ノードには異なるコンポーネントがインストールされます。

マスターノードは主にクラスター管理を担当します。マスターノードには次のコンポーネントが含まれています。

• ApiServer: リソース操作の唯一のエントリ ポイントであり、ユーザーが入力したコマンドを受信し、認証、承認、API 登録、検出などのメカニズムを提供します。
• スケジューラ: クラスター リソースのスケジューリングを担当し、事前に決定されたスケジューリング戦略に従って、対応するノードにポッドをスケジュールします。
• ControllerManager: プログラム展開のスケジュール、障害検出、自動拡張、ローリング更新など、クラスターの状態を維持する役割を担います。
• Etcd: クラスター内のさまざまなリソース オブジェクトに関する情報を保存します。

ノードは、コンテナ、つまり動作しているノードの実行環境を提供する役割を担います。

• Kubelet: コンテナのライフサイクルの維持、つまりDockerを制御してコンテナの作成、更新、破棄を担当します。
• KubeProxy: クラスター内でのサービス検出と負荷分散を担当します。
• Docker: ノード上のコンテナのさまざまな操作を担当します

Nginx サービスのデプロイメントを例に、Kubernetes システムのさまざまなコンポーネント間の呼び出し関係を説明します。

1. まず、Kubernetes 環境が起動されると、マスターとノードの両方が独自の情報を etcd データベースに保存することが明らかです。
2. Nginx サービスのインストール要求は、まずマスター ノードの API サーバー コンポーネントに送信されます。
3. API サーバー コンポーネントは、スケジューラ コンポーネントを呼び出して、サービスをインストールするノードを決定します。この時点で、etcd から各ノードの情報を読み取り、特定のアルゴリズムに従って選択し、その結果を API サーバーに通知します。
4. API サーバーは、コントローラー マネージャーを呼び出してノード ノードを呼び出して Nginx サービスをインストールします。
5. 指示を受信すると、Kubelet は Docker に通知し、Docker は Nginx Pod を起動します。 Pod は Kubernetes の最小の動作単位であり、コンテナは Pod 内で実行する必要があります。
6. Nginx サービスが実行されています。 Nginx にアクセスする必要がある場合は、 kube-proxy を使用して Pod のアクセス プロキシを生成する必要があります。このようにして、外部ユーザーはクラスター内の Nginx サービスにアクセスできるようになります。

最後に、k8sのコアコンセプトを見てみましょう。

公式サイトではアーキテクチャ図が公開されている

マスター: クラスター制御ノード。各クラスターには、クラスターの管理と制御を担当するマスター ノードが少なくとも 1 つ必要です。

ノード: ワークロード ノード。マスターはこれらのノード ワーカー ノードにコンテナを割り当て、ノード上の Docker がコンテナの実行を担当します。

Pod : Kubernetes の最小の制御単位。コンテナはすべてポッド内で実行されます。ポッドには 1 つ以上のコンテナーを含めることができます。

コントローラー: コントローラーは、ポッドの起動、ポッドの停止、ポッドの数のスケーリングなど、ポッドを管理するために使用されます。

サービス: 同じタイプの複数のポッドを維持できる、ポッドの外部サービスへの統合された入り口。

ラベル: ポッドを分類するために使用されるラベル。同じタイプのポッドには同じラベルが付きます。

NameSpace : ポッドの動作環境を分離するために使用される名前空間。

一般的な Linux コマンド

ノード情報の表示

 kubectl ノードを取得する

名前空間の作成/削除

 kubectl create ns ${スペース名}
 kubectl delete ns ${スペース名}

k8s でポッドを実行する

Pod は実行中のコンテナのグループです。 Pod は Kubernetes におけるアプリケーションの最小単位です。

例: 3 つのレプリカ、ラベル app=example、イメージ nginx:1.10、ポート 80 を持つ nginx という名前のコンテナ インスタンスを実行します。

 kubectl を実行する nginx --replicas=3 --labels="app=example" --image=nginx:1.10 --port=80

コンテナ内のすべてのポッドを表示する

 kubectl ポッドを取得 -A

ポッドノードのラベル情報を表示する

 kubectl ポッドを取得 --show-labels

指定されたラベルに基づいて特定のポッドに一致します

 kubectl ポッドを取得 -l app=example

ポッド作成の詳細なプロセスを見る

 kubectl describe pod ${ポッド名} -n ${スペース名}

指定されたポッドの情報を表示する

 kubectl get pod ${ポッド名} -n ${スペース名}

ポッドの詳細を表示

 kubectl get pod -o ワイド

ポッド ログを表示するには、docker ログと同様に、サービス ログ自体を実際に表示できます。

 kubectl は ${ポッド名} -n ${スペース名} をログに記録します。

指定した期間にログを出力する

 kubectl は ${ポッド名} を --since=1h でログに記録します。

ログを出力するタイムスタンプを指定する

 kubectl は ${ポッド名} をログに記録します --since-time=2022-12-01T15:00:00Z

コンテナに入る

 kubectl exec -ti ${ポッド名} /bin/bash

サービスコンセプト

Deployment を使用して Pod のグループを作成し、高可用性のサービスを提供できるようになりました。各 Pod には個別の Pod IP アドレスが割り当てられますが、次のような問題があります。

Pod が再構築されると、Pod の IP アドレスが変更されます。

Pod の IP はクラスター内でのみ表示される仮想 IP であり、外部からはアクセスできません。

クラスター内でアクセス可能なサービスを作成する

kubectl expose Deployment xxx --name=サービス名 --type=ClusterIP --port=公開ポート --target-port=クラスター内の Pod を指すポート [-n 名前空間]。

サービスの IP である CLUSTER-IP が生成されます。このアドレスはサービスのライフサイクル中は変更されません。

 kubectl 公開デプロイメント nginx --name=svc-nginx1 --type=ClusterIP --port=80 --target-port=80 -n test

サービスを見る

 kubectl get svg [-n 名前空間] [-o ワイド]

クラスターの外部からアクセス可能なサービスを作成する

kubectl expose デプロイメント xxx --name=サービス名 --type=NodePort --port=公開ポート --target-port=クラスター内のポッドを指すポート [-n 名前空間]

 kubectl expose deploy nginx --name=svc-nginx2 --type=NodePort --port=80 --target-port=80 -n テスト

スケーリング

 kubectl スケール --replicas=5 デプロイメント/my-nginx
 kubectl 編集デプロイメント my-nginx

画像を更新する

デプロイメント内の nginx コンテナ イメージを「nginx:1.9.1」に設定します。

 kubectl イメージの設定 デプロイメント/nginx busybox=busybox nginx=nginx:1.9.1

バージョンロールバック

歴史。

 kubectl ロールアウト履歴デプロイメント ${pod name}

履歴の詳細を表示します。

 kubectl ロールアウト履歴デプロイメント my-nginx--revision=2

ロールバック（前回に戻る）。

 kubectl ロールアウト デプロイメントを元に戻す ${pod name}

ロールバック（指定されたバージョンに戻す）。

 kubectl ロールアウト デプロイメントを元に戻す my-nginx--to-revision=2