イラストで学ぶ Kubernetes

>こちらの記事は、[Sudhakar Rayavaram](https://medium.com/@suDocker) 氏により2019年11月に公開された『 [Know Kubernetes — Pictorially](https://medium.com/tarkalabs/know-kubernetes-pictorially-f6e6a0052dd0) 』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。

私は最近、Kubernetesの内部をより深く理解するための探求を始めました。この記事は私が行った講演のブログ版です。

#コンテナ
Kubernetesを理解しようとする前に、少し時間を使って、コンテナが何であるか、そしてなぜそれらが人気であるのか​​を明確にしましょう。結局のところ、コンテナが何であるかを知らずにコンテナオーケストレータ（Kubernetes）について話しても意味がありません。:)

![](https://miro.medium.com/max/1350/1*lus49PaFI90rVMd23fV86A.png)

「コンテナ」とは…あなたが詰め込んだすべてのものを保持する容器です。当たり前ですね！

アプリケーションコード、依存ライブラリ、および、そのカーネルまでの依存関係などが含まれています。ここで重要な概念は分離です。あなたの物すべてを、それら以外のものから分離し、より制御しやすくします。コンテナによって提供される分離には3つのタイプがあります。

- ワークスペースの分離（プロセス、ネットワーク）
- リソースの分離（CPU、メモリ）
- ファイルシステムの分離（Union File System）

コンテナをダイエット中のVMのようなものと考えてみましょう。それらは無駄が無く、（起動において）高速で小容量です。そして、これはすべてが土台から構築されたわけではありません。代わりに、Linuxシステムに存在するコンストラクト（cgroups、名前空間など）を使用して、その上に素敵な抽象環境を構築します。

これで、コンテナが何であるかがわかりました。なぜそれらが非常に人気があるのか​​は簡単に理解できます。アプリケーションのバイナリ/コードのみを提供する代わりに、アプリケーションの実行に必要な環境全体を、非常に小さなユニットとして構築可能なコンテナによって、実用的に提供することができます。「私のマシンでは動作する」という環境依存問題への完璧な解決策です。

#Kubernetesをいつ使用するか？
すべてがコンテナでうまくいき、ソフトウェア開発者の生活は今ではずっと良くなっています。それでは、なぜ別のテクノロジーであるKubernetesのようなコンテナオーケストレータが必要なのでしょうか？

![](https://miro.medium.com/max/1808/1*QDhBk9xFa77T4n3-5lHIsg.png)

それはあなたがこのような状態（イラスト）になったときに必要です。管理するコンテナが大量にある場合です。

Q：フロントエンドコンテナはどこにあり、それらのうち稼働しているのはいくつですか？
A：難しい質問です。コンテナオーケストレータを使ってください。

Q：フロントエンドコンテナと、新しく作成されたバックエンドコンテナを通信させるにはどうすればよいですか？
A：IPをハードコードしましょう。または、コンテナオーケストレータを使ってください。

Q：ローリングアップグレードはどのように行えばよいですか？
A：各ステップを手作業で行います。または、コンテナオーケストレータを使ってください。

#私がKubernetesを好む理由
Docker Swarm、Mesos、Kubernetesなど、オーケストレータは数多くあります。私の選択はKubernetesです（それゆえにこの記事です）。なぜならKubernetesは…

![](https://miro.medium.com/max/1693/1*eHVk7p4I2LuSnVwvYaHbyw.png)

…レゴブロックのようだからです。大規模環境でのコンテナオーケストレータの実行に必要なコンポーネントを持つだけでなく、さまざまなコンポーネントをカスタムコンポーネントと交換できる柔軟性も備えています。カスタムスケジューラが必要な場合は、差し込むだけです。新しいリソースタイプが必要な場合は、CRD^[1]を書きましょう。また、コミュニティは非常に活発で、ツールを急速に進化させています。
**訳注：[1]: Custom Resource Definition**

#Kubernetesのアーキテクチャ

![](https://miro.medium.com/max/1835/1*xYujRQjcpd-mQbNTwEbukA.png)

すべてのKubernetesクラスターには、2種類のノード（マシン）があります。マスターとワーカーです。その名前が示すように、ワーカーでのペイロード（アプリケーション）の実行において、マスターはクラスターを制御および監視します。

クラスターは１台のマスターノードでも動作します。ただし、高可用性のため推奨は３台です（HAクラスターとして知られています）。

マスターとその構成要素を詳しく見てみましょう。

![](https://miro.medium.com/max/2750/1*qgogo7I03e5kyNWKVWtFYg.png)

**etcd**： kubernetesオブジェクト、それらの現在の状態、アクセス情報、その他のクラスター構成情報に関する、すべてのデータを保存するデータベースです。

**API Server**：クラスターを操作するためのエンドポイントを公開するRESTful APIサーバー。マスターノードとワーカーノードのほぼすべてのコンポーネントは、このサーバーと通信して、各役割を実行します。

**Scheduler**：どのペイロードをどのマシンで実行するべきかを決定する責任を負います。

**Control Manager**：クラスターの状態を監視し（API Serverを呼び出しこのデータを取得）、期待される状態をもたらすためのアクションを実行する制御ループです。

![](https://miro.medium.com/max/2278/1*sHmUG1htz-brFTGPz3HXXQ.png)

**kubelet**：ワーカーノードの心臓です。マスターノードのAPI Serverと通信し、そのノード用にスケジュールされたコンテナを実行します。

**kube Proxy**：IPテーブル/ IPVSを使用してポッドのネットワークニーズを処理します。

**Pod（ポッド）**：すべてのコンテナを実行するkubernetesの働き者です。ポッドで抽象化せずにkubernetes内でコンテナを実行することはできません。ポッドは、kuberenetesにおけるコンテナ間のネットワークに不可欠な機能を追加します。

![](https://miro.medium.com/max/3765/1*c80mIDN0Wz7b2xb5Qfxerw.png)

ポッドには複数のコンテナを含めることができ、これらのコンテナ内で実行されているすべてのサーバーはお互いをローカルホストとして認識できます。これにより、アプリのさまざまな側面を個別のコンテナとして分け、それらをすべて1つのポッドとして、まとめてロードできるので、非常に便利になります。サイドカー、プロキシ、アンバサダーなど、さまざまなニーズに対応するさまざまなポッドパターンがあります。それらについて詳細を学びたい場合は[この記事](https://matthewpalmer.net/kubernetes-app-developer/articles/multi-container-pod-design-patterns.html)をチェックしてください。

ポッドのネットワーキングインターフェースは、同一ノード内、および他のワーカーノード内の異なるポッドとネットワーク連携するためのメカニズムを提供します。

![](https://miro.medium.com/max/2678/1*F2wfrW5zO6Y36Yr_jL014g.png)

また、各ポッドには、kube-proxyがトラフィックをルーティングするために使用する独自のIPアドレスが割り当てられます。そして、このIPアドレスはクラスター内でのみ見えます。

ポッド内にマウントされたボリュームはすべてのコンテナからも見ることができ、これらのボリュームは、ポッド間での非同期的な連携に使われることもあります。

例えば、（Instagramのような）写真をアップロードするアプリの場合では、アップロードされた写真ファイルをボリュームに保存し、同ポッド内の別のコンテナに、このボリューム内の新しいファイルを監視させます。

そして新規ファイルから複数サイズのファイルを作る処理を開始させ、作成されたファイルをクラウドストレージにアップロードすることも可能です。

#コントローラー
kubernetesには、ReplicaSet（レプリカセット）、Replication Controller、Deployment（デプロイメント）、StatefulSet、Service（サービス）などのコントローラーが多数あります。これらは、何らかの方法でポッドを制御するオブジェクトです。重要なものをいくつか見ていきましょう。

#レプリカセット
![](https://miro.medium.com/max/2885/1*CrG3p2FUcjiHhwLyGQzQ2Q.png)
ReplicaSetはポッドの複製が得意

このコントローラーの主な役割は、特定のポッドのレプリカを作成することです。ポッドが何らかの理由で停止した場合に、このコントローラーに通知され、すぐに新しいポッドを作成するアクションにとりかかります。

#デプロイメント

![](https://miro.medium.com/max/2885/1*6qQCQLV8cIBkMY7K4GKrig.png)
デプロイメント（ぼさぼさ髪の奴）はレプリカセットを制御しようとする

デプロイメントは、レプリカを管理するためにレプリカセットを使用する、より高次のオブジェクトです。新規の ReplicaSetはスケールアップさせ、既存の ReplicaSetはスケールダウン（最終的に削除）させることで、ローリングアップグレードを提供します。

#サービス
![](https://miro.medium.com/max/3190/1*oAF5BE2RplGHtGmcC0L5Ew.png)
サービス（イラストのドローンのような奴）は対応するポッドにデータパケットを配信する

サービスは、「パケット」を対応するノードに配布する際に、ロードバランサーとして機能することを主な役割とするコントローラーオブジェクトです。基本的には、ワーカーノード全体で同様のポッド（通常はポッドラベルで識別されます）をグループ化するコントローラー構造です。

「フロントエンド」アプリが「バックエンド」アプリと連携したい場合に、それぞれ実行中のインスタンスが多数存在しているとします。すべてのバックエンドポッドのIPをハードコーディングすることを心配する代わりに、データパケットをバックエンドサービスに送信し、このときバックエンドサービスは適当な負荷分散と転送の方法を決定します。

PS：サービスではすべてのパケットルーティングはIPテーブル/ IPVS / CNIプラグインによって処理されるため、より仮想エンティティライクであることに注意してください。kubernetesエコシステムでのサービスの役割を理解するために、外に出ている実際のエンティティとして考えるのがわかりやすいと思います。

#イングレス
![](https://miro.medium.com/max/2950/1*FEufKCJPNrCwkrJkwtjQWQ.png)
イングレスはすべてのパケットがクラスターへ流れる際に通過するフローティングプラットフォーム

イングレスコントローラーは、外の世界と、クラスター内で実行されているすべてのサービスとが通信を行うための単一の接点です。これにより、セキュリティポリシーの設定、監視、および単一の場所でのロギングも簡単に行えるようになります。

PS：Kubernetesには[DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)、[StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)、[Job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)のような他のコントローラーオブジェクトがたくさんあります。また、Secrets、ConfigMapなどのオブジェクトもあり、これらはアプリケーションのシークレットや設定情報を保存するために使用されます。このブログの内容に基づいて、これらは私の次のブログ投稿で取り上げようと思います。

# 関連記事
- [順を追って学ぶKubernetesのキホン〜ローカル環境でKubernetesクラスターを作成してKubernetesの概念を理解する〜](https://qiita.com/baby-degu/items/ce26507bd954621d6dc5)

# 翻訳協力
Original Author:  **[Sudhakar Rayavaram](https://medium.com/@suDocker)** 
Thank you for letting us share your knowledge! 

この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: @upaldus
翻訳担当: @upaldus
監査担当: @nyorochan
公開担当: @aoharu

# ご意見・ご感想をお待ちしております
今回の記事は、いかがだったでしょうか？
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。
みなさまのメッセージをお待ちしております。