目次
1. パブリック クラウドの種類の説明: IAAS、PAAS、SAAS
2. Kubernetes が必要な理由と、Kubernetes で何ができるのですか?
導入
Kubernetes とはどういう意味ですか? なぜ K8S とも呼ばれるのでしょうか?
Kubernetes という名前はギリシャ語に由来しており、「操舵手」または「航海士」を意味します。K8sとは、「ubernete」の8文字を「8」に置き換えた略称です。
Kubernetes は、コンテナ化されたワークロードとサービスを管理するための移植可能で拡張可能なオープン ソース プラットフォームで、宣言的な構成と自動化を容易にします。Kubernetes には、大規模かつ急速に成長するエコシステムがあります。Kubernetesd のサービス、サポート、ツールは広く利用可能です
1. K8Sの由来
1. パブリック クラウドの種類の説明: IAAS、PAAS、SAAS
クラウド コンピューティングの概念では、パブリック クラウドを IAAS (Infra Structure as a Service)、PAAS (Platform as a Service)、SAAS (Software as a Service) の 3 つのレベルに分けることができます。
-
IAAS: サービスとしてのインフラストラクチャ。
Infrastructure-as-a-Service (IAAS)、中国で最高のサービスは Alibaba Cloud -
Platform-as-a-Service (PAAS) はミドルウェアとも呼ばれ、PAAS 企業は、仮想サーバーやオペレーティング システムなど、オンラインでアプリケーションを開発および配布するためのさまざまなソリューションを提供します。
大手 PAAS プロバイダーには、Google App Engine、Microsoft Azure、Force.com、Heraku、Engine Yard などが含まれます。
中国で最も優れているのは Sina Cloud です。 -
SAAS: サービスとしてのソフトウェア。
Software-as-a-Service (SAAS) の例としては、Google Apps、Dropbox、Salesforce、Cisco WebEx、Concur、GoToMeeting などがあります。より良いのは
Microsoft Office 365 です。
2. リソースマネージャーの誕生
上記のパブリック クラウドを用意した後、そのリソースを管理する必要があるため、リソース マネージャーが誕生しました: MESOS – Docker Swarm – Kubernetes
2.1 メソス
MESOS: Mesos は、Apache が所有するオープンソースの分散リソース管理フレームワークで、分散システムのカーネルと呼ばれ、その後 twitter で広く使用されました。
Twitter は Mesos の最大の顧客でもありますが、2019 年 5 月頃に Twitter は MESOS を使用せず Kubernetes に切り替えることを発表し、この時点で Mesos は徐々に排除されました。
2.2 Docker Swarm
Docker Swarm は非常に軽量なクラスター管理ツールで、サイズはわずか数十 MB です。
Swarm は Docker が公式に提供しているクラスタ管理ツールで、主な機能は複数の Docker ホストを全体として抽象化し、それらの Docker ホスト上のさまざまな Docker リソースを 1 つの入り口から一元管理することです。
ただし、Swarm は Kubernetes に似ており、軽量であるため、Kubernetes よりも機能が少なくなっています。
2019 年 7 月頃、Alibaba Cloud は Docker Swarm を選択リストから削除すると発表しました。これは、近い将来、Docker Swarm も Mesos と同様に徐々に排除されることを意味します。
2.3 Kubernetes
Kubernetes は、コンテナ化されたワークロードとサービスを管理するための移植可能で拡張可能なオープン ソース プラットフォームで、宣言的な構成と自動化を容易にします。Kubernetes には、大規模かつ急速に成長するエコシステムがあります。Kubernetesd のサービス、サポート、ツールは広く利用可能です
コンテナ化されたアプリケーションを自動的にデプロイ、スケーリング、管理するためのオープンソース システム。
K8S は、複数のコンテナ化されたプログラム (docker など) の自動運用と保守を担当するクラスターであり、豊富なエコロジー マシンを備えたコンテナ オーケストレーション フレームワーク ツールであることがわかります。
2. Kubernetes が必要な理由と、Kubernetes で何ができるのですか?
コンテナは、アプリケーションをパッケージ化して実行するための優れた方法です。実稼働環境では、アプリケーションを実行するコンテナを管理し、ダウンタイムが発生しないようにする必要があります。たとえば、1 つのコンテナーに障害が発生した場合は、別のコンテナーを起動する必要があります。システムがこの動作を処理できればもっと簡単ではないでしょうか?
これが、Kubernetes がこれらの問題を解決する方法です。Kubernetes は、分散システムを復元力をもって実行するためのフレームワークを提供します。Kubernetes は、スケーリング要件、フェイルオーバー、デプロイメント モードなどを処理します。
K8S は Google のオープンソース コンテナ クラスタ管理システムであり、Docker などのコンテナ テクノロジに基づいて、コンテナ化されたアプリケーションの展開と運用、リソース スケジューリング、サービス ディスカバリ、動的スケーリングなどの一連の完全な機能を提供し、大規模なアプリケーションの効率を向上させます。コンテナクラスター管理の利便性。その主な機能は次のとおりです。
- Docker などのコンテナー テクノロジーを使用して、アプリケーションをパッケージ化し、インスタンス化し、実行します。
- クラスター内のマシン間でコンテナーを実行および管理します。
- マシン間の Docker コンテナ間の通信の問題を解決します。
- K8S の自己修復メカニズムにより、コンテナ クラスターは常にユーザーが期待する状態で実行されます。
3. Kubernetesの特徴
- 自動スケーリング: コマンドや UI を使用するか、CPU 使用率に基づいてアプリケーション インスタンスを自動的かつ迅速に拡張および縮小して、アプリケーション ビジネスの同時実行ピーク時に高可用性を確保し、ビジネスのピークが低いときにリソースをリサイクルして最小限のコストでサービスを実行します。
- 自己修復: ノードに障害が発生した場合は、障害が発生したコンテナを再起動し、予想されるコピー数を確保するために置き換えおよび再デプロイします。ヘルスチェックに失敗したコンテナを強制終了し、オンライン サービスが中断されないように準備が整うまでクライアント要求を処理しません。
- サービス検出と負荷分散: K8S は、複数のコンテナに統合されたアクセス入口 (内部 IP アドレスと DNS 名) を提供し、関連するすべてのコンテナの負荷分散を行うため、ユーザーはコンテナ IP の問題を考慮する必要がありません。
- 自動リリース (デフォルトのローリング リリース モード) とロールバック: K8S はローリング戦略を使用してアプリケーションを更新し、すべての Pod を同時に削除するのではなく、一度に 1 つの Pod を更新します。更新プロセス中に問題が発生した場合、変更は次のようになります。アップグレードがビジネスに影響を及ぼさないようにするためにロールバックされました。
- 一元化された構成管理とキー管理: 機密データをミラーに公開することなく機密データとアプリケーション構成を管理し、機密データのセキュリティを向上させ、一般的に使用される一部の構成を K8S に保存してアプリケーションの使用を容易にします。
- ストレージ オーケストレーション: 外部ストレージをサポートし、外部ストレージ リソースをオーケストレーションし、ローカル ストレージ、パブリック クラウド (AWS など)、またはネットワーク ストレージ (NFS、Glusterfs、Ceph) からの外部ストレージ システムをクラスター リソースとしてマウントします。部分的な使用が大幅に向上します。ストレージ使用の柔軟性。
- タスクのバッチ処理と実行: バッチ データの処理と分析のシナリオを満たす、ワンタイム タスクとスケジュールされたタスクを提供します。
k8s は、Docker を裸で実行する際のいくつかの問題点を解決します。
- 単一マシン上で使用できますが、効率的にクラスタ化することはできません。
- コンテナの数が増えると管理コストが増加する
- 効果的な災害復旧および自己修復メカニズムがない
- 事前に設定されたオーケストレーション テンプレートがなければ、迅速かつ大規模なコンテナ スケジューリングを実現できません
- 統合された構成管理センター ツールはありません
- コンテナのライフサイクルを管理するツールがない
- グラフィカルな運用保守管理ツールがない
4. Kubernetes アーキテクチャ
K8S はマスター/スレーブ デバイス モデル (マスター/スレーブ アーキテクチャ) に属します。つまり、マスター ノードはクラスターのスケジューリング、管理、運用と保守を担当し、スレーブ ノードはクラスター内のコンピューティング ワークロード ノードです。 。
K8Sでは一般にメインノードをマスターノード、スレーブノードをワーカーノードと呼び、各ノードにはマスターからワークロードが割り当てられます。
マスター コンポーネントはクラスター内の任意のコンピューターで実行できますが、マスター ノードは別のサーバーを占有することをお勧めします。マスターはクラスター全体の頭脳であるため、マスターが配置されているノードがダウンするか使用できなくなると、すべての制御コマンドが無効になります。マスターに加えて、K8S クラスター内の他のマシンはワーカー ノードと呼ばれ、ノードがダウンすると、そのノード上のワークロードはマスターによって自動的に他のノードに転送されます。
| コンポーネント | 効果 |
| マスターノード | — |
| アピサーバー | すべてのサービスへのアクセス |
| コントローラーマネージャー | プリセット テンプレートに基づいてポッドを作成し、ポッドやその他のリソースの必要な数のコピーを維持する責任を負います。 |
| スケジューラー | ポッドのスケジュール設定と、事前選択戦略および優先戦略を通じてポッドを割り当てるための最適なノードの選択を担当します。 |
| etcd | K8S クラスターの重要な情報の保存を担当する分散キーバリュー データベース (永続性) |
| 作業ノードノード | — |
| キュベレット | apiserver と通信して現在のノードのリソース使用状況とステータスを報告し、apiserver の指示を受け入れ、コンテナ エンジンと対話してコンテナのライフサイクル管理を実装します。 |
| 代理でした | ポッドのネットワーク プロキシをノード ノードに実装し、ネットワーク ルールと 4 層の負荷分散ルールを維持し、サービス マッピング アクセスを実装するために iptables または ipvs にルールを記述する責任を負います。 |
| コンテナランタイムドッカー | コンテナを実行し、ローカル コンテナの作成と管理を担当します。 |
1. K8Sのワークフロー
まず、運用保守担当者は、kubectl コマンドライン ツールを使用して API サーバーにリクエストを送信します。リクエストを受信した後、API サーバーはそれを etcd に書き込みます。API サーバーは、コントローラー マネージャーにポッドの作成を依頼します。コントローラーマネージャーは API を使用してポッドを作成します。サーバーは etcd でユーザーのデフォルト情報を読み取り、API サーバーを通じてスケジューラーを見つけて、新しく作成されたポッドに最適なノードを選択します。スケジューラは、事前選択および最適化戦略を使用して、API サーバーを通じて etcd ストレージ センターに保存されているノードのメタ情報、残りのリソースなどに基づいて最適なノードを選択します。
スケジューラーがノードを決定すると、API サーバー経由でノード上の kubele に渡され、ポッド リソースが作成されます。Kubele はコンテナ エンジンを呼び出して対話的にポッドを作成し、同時に API 経由でポッド監視情報を etcd に保存します。サーバ。
ユーザーが kube-proxy のロードと転送を通じてアクセスする場合、対応する pod にアクセスする
ときにポッド リストの作成を決定するのはコントローラー マネージャーであり、kubelet とコンテナー エンジンがすべてその作業を担当します。
2. K8S作成Podプロセス
kubectlはポッドを作成します（送信時にjsonに変換されます）
- まず、auth (認証) によって認証され、API サーバーに渡されて処理されます。
- APIサーバーがリクエスト情報をetcdに送信します。
- スケジューラーとコントローラーマネージャーは API サーバーを監視 (リッスン) し、リクエストをリッスンします。
- スケジューラーとコントローラーマネージャーがリクエストをリッスンした後、スケジューラーはノードノード情報の取得を含むリストを API サーバーに送信します -->
- このとき、APIサーバーはetcdからバックエンドノード情報を取得し、取得後スケジューラーで監視し、スケジューラーで事前選択とスコアリングを行い、最終的に結果をAPIサーバーに送信します。 。
- このとき、API Serverもコントローラーマネージャーによって監視されており、コントローラーマネージャーはリクエストに応じてPodの構成情報(どのコントローラーが必要か)を作成し、コントローラーリソースをAPIサーバーに渡します。
- このとき、API サーバーは対応するノードの kubelet (エージェント) にリストを送信します。
- kubelet エージェントは、K8S を介してコンテナのインターフェイス (containerd など) と対話します。それが docker コンテナであると仮定すると、kubelet は dockershim および runc インターフェイスを介して docker デーモン docker-server と対話し、対応するコンテナを作成し、対応するポッド。
- Kubelet はまた、メトリック サーバーを使用してこのノードのすべてのステータス情報を収集し、それを API サーバーに送信します。最後に、API サーバーはストレージのためにリストを etcd に送信します (最終的に、API サーバーは etcd 内のデータを維持します)。
簡易版
1. kubectl を json に変換し、api-server に Pod 作成リクエストを送信
2. api-server がリクエスト情報を etcd に記録
3. Scheduler が api-server で処理されたリクエストを監視し、適用4. API サーバーが
etcd からバックエンド ノード情報を取得した後、スケジューラに提供します
5. スケジューラは事前選択とスコアリングを実行し、結果を API サーバーに送信します。 6.コントローラー
マネージャーは、API サーバーによって処理されたリクエスト情報を監視し、送信します。 必要なコントローラーリソースが API サーバーに与えられます。 7.
API サーバーは、ノードノードの kubelet に接続します。
8. kubelet は、リソースを使用してポッドを作成し、統計情報を API サーバーに返します。
9. API サーバーは情報を etcd に記録します。