Kubernetes入門：開発者、スタートアップ、そしてその先へ

Kubernetes(クーバネティス、k8sと略されることも)という言葉を聞いたことがあるかもしれません。求人情報、テック系ポッドキャスト、あるいはDevOpsに詳しい友人から、まるで万能の秘訣のように語られるのを聞いたことがあるかもしれません😅。重要そうだけど…ちょっと謎めいていますよね。

では、Kubernetesとは一体何なのでしょうか？なぜこれほど普及しているのでしょうか？そして、あなたは気にかけるべきなのでしょうか？

この記事では、Kubernetesをわかりやすく解説します。専門用語や難解な技術用語は使いません。Kubernetesとは何か、どのようにして生まれたのか、そして特に多くのユーザーを抱える巨大なアプリケーションを構築・運用するチームにとって、なぜこれほど重要になったのかを学びます。

Kubernetesが登場する前の状況を振り返り（ネタバレ：ひどい状況でした）、Kubernetesが解決するために設計された実際の問題を見ていきましょう。

最終的には、Kubernetesの目的を理解するだけでなく、Kubernetesクラスタ上にシンプルなアプリケーションをデプロイする方法も知ることができます。

読み終える頃には、「Kubernetesという言葉をよく聞くけど…」から「へえ、なんとなく分かってきたぞ！」に変わるでしょう 😄

目次

• Kubernetesとは？
• Kubernetes登場前のアプリケーションデプロイ
• Kubernetesが解決する問題 🧠
• Kubernetesの仕組み – Kubernetes環境のコンポーネント 🧑‍🔧
• Kubernetesワークロード 🛠️ – Pod、Deployment、Serviceなど
• play-with-k8sでデモ環境にKubernetesクラスタを作成する方法
• Kubernetesクラスタにアプリケーションをデプロイする方法
• ✅ ビジネスでKubernetesを使用する利点
• 😬 Kubernetesを使用するデメリット
• ユースケース：Kubernetesを使用すべき時（とそうでない時）
• 結論
• さらに詳しく学ぶ 📚
• 著者について 👨‍💻

Kubernetesとは？

大規模なソフトウェアプラットフォーム、例えば銀行アプリを構築していると想像してください。このアプリには、ユーザー登録、入金、出金、支払いなど、多くの機能が必要です。これらの機能は非常に大きく複雑であるため、別々のアプリケーションに分割する方が簡単です。これらの個々のアプリケーションはマイクロサービスと呼ばれます。

マイクロサービスとは何でしょうか？マイクロサービスは、より大きなプラットフォームを作成するために連携する小さな構成要素のようなものだと考えてください。例えば、次のようなマイクロサービスがあるかもしれません。

• ユーザー登録のためのマイクロサービス
• 入金処理のためのマイクロサービス
• 支払い処理のためのマイクロサービス
• その他多数！

ユーザーにとっては、一つのスムーズで統一された銀行アプリのように見えるかもしれません。しかし、舞台裏では、多数の小さなアプリが連携してすべてが実行されています。

しかし、ここで問題が発生します…

このようなマイクロサービスが数十（あるいは数百）もある場合、その管理は悪夢となります。次のような作業が必要になるかもしれません。

• それぞれ個別にデプロイする
• それぞれ個別に監視する (クラッシュしたり、ロードが多すぎて遅くならないようにするため)
• トラフィックの急増に合わせて、一つずつ拡張する (より多くのユーザーを処理できるようにするため)

銀行アプリのユーザー数が突然数百万人に増えた場合、各マイクロサービスを調整および更新して、スムーズに実行し続ける必要があります。😖 これは大変な作業であり、何か問題が発生した場合、深刻な事態に陥ります。

ここでKubernetesの登場です！🚀

Kubernetesは、これらすべてのマイクロサービスを管理する、非常に効率的なマネージャーのようなものです。Kubernetesは、次のことを支援するプラットフォームです。

• デプロイを自動化する (アプリを起動して実行する)
• マイクロサービスを拡張する (ユーザーのトラフィックの増減に応じて、必要に応じて大きくしたり小さくしたりする)
• マイクロサービスを監視する (その状態を監視する)
• 信頼性を確保する (マイクロサービスが壊れたり失敗した場合、k8sがすぐにそれを置き換える)

簡単に言うと、Kubernetesは、すべての小さなマイクロサービスを編成し、アプリへのトラフィック量に関係なく、それらがスムーズに連携して実行されるようにします。オーケストラを指揮する指揮者のように、舞台裏のすべてを処理するため、マイクロサービスが混乱することなく連携できます。

Kubernetes登場前のアプリケーションデプロイ

Kubernetesが登場する前は、ソフトウェアチーム、特に多数のマイクロサービスで構成されたアプリケーションをデプロイする際には、かなり苦労を強いられていました。

一般的な方法の1つは、分散システム構成を使用することでした。それは次のようなものでした。

各マイクロサービス（ユーザー登録、支払い、入金など）が個別のサーバー（物理コンピューターまたは仮想マシン）にインストールされていると想像してください。これらの各サーバーは慎重に準備する必要がありました。

• マイクロサービス自体をインストールする必要がありました。
• マイクロサービスに必要なソフトウェア依存関係（プログラミング言語、ライブラリー、ツールなど）もインストールする必要がありました。
• すべてを各サーバーで手動で構成する必要がありました。

そして、これらすべてのサーバーは相互に通信する必要がありました。場合によっては、公衆インターネット経由でやり取りしたり、VPNなどのプライベートネットワーク経由でやり取りしたりする必要がありました。

大変そうですよね？😮 その通りでした！アップデートの管理、バグの修正、トラフィックの急増時のスケールアップ、クラッシュを防ぐことは、開発者やシステム管理者にとって完全な頭痛の種になる可能性がありました。😖

そしてコンテナが登場 🚢

痛みを（少し）軽減する、よりモダンなソリューションは、コンテナを使用することでした。

では、コンテナとは何でしょうか？

コンテナは、マイクロサービス用のお弁当箱のようなものだと考えてください。マイクロサービスとそのサポートツールをサーバーに直接インストールする代わりに、コード、設定、ソフトウェアライブラリーなど、必要なものをすべて、１つにまとまったコンテナに詰め込みます。コンテナがどこへ行っても、マイクロサービスはまったく同じように実行されます。驚くことはありません！

Dockerなどのツールを使用すると、これが非常に簡単になります。マイクロサービスがコンテナに詰め込まれたら、次の場所にデプロイできます。

• 単一のサーバー
• 複数のサーバー
• または、AWS Elastic Beanstalk、Azure App Service、Google Cloud Run などのクラウドプラットフォーム

Kubernetesが解決する問題 🧠

当初コンテナが登場したとき、開発者は金鉱を掘り当てたように感じました。

マイクロサービスをきちんとした小さなコンテナにパッケージ化して、どこでも実行できました。サーバーごとに同じソフトウェアを何度もインストールする必要はありません。DockerやDocker Composeのようなツールは、小規模なプロジェクトではスムーズでした。

しかし、現実は？そこで混乱が生じました。

コンテナ管理の頭痛の種が拡大💡

マイクロサービスが数個しかない場合は、ストレスをあまり感じるこなく、手動でコンテナをデプロイおよび管理できます。しかし、アプリが成長し始め、突然数十個または数百個ものマイクロサービスを持つようになった場合、管理は困難になります。

• 各コンテナを手動でデプロイする必要がありました。
• クラッシュした場合に再起動する必要がありました。
• より多くのユーザーが殺到し始めたら、1つずつスケールする必要がありました。

DockerとDocker Composeは、小規模な遊び場やスタートアップには最適でしたが、トラフィックが大量に流入するエンタープライズアプリケーションには適していませんでした。

大きな助けとなったクラウド管理サービス...ただし、限界も 🧑‍💻

AWS Elastic Beanstalk、Azure App Service、Google Code Engineのようなクラウドサービスは、近道を提供してくれました。サーバーを設定することを気にせずに、コンテナをデプロイできました。

次のことができました。

• 各コンテナを独自の管理されたクラウドインスタンスにデプロイする。
• トラフィックに基づいて自動的にスケールする。

しかし、大きな頭痛の種がいくつかありました。

📦 マイクロサービスをグループ化するのが煩わしく、高価だった

コンテナを環境 (「テスト」または「本番」など) ごと、またはチーム (「財務」または「人事」など) ごとに整理することができました。しかし、新しいマイクロサービスごとに、通常、独自のクラウドインスタンスが必要でした。たとえば、すべてのコンテナに対して、個別のAzure App ServiceまたはElastic Beanstalk環境が必要でした。

想像してみてください。

• 各App Serviceインスタンスのコストは月に約50ドルです。
• 10個のマイクロサービスがあるとします。
• 月に500ドルになります...ほとんど使用されていなくてもです。💸 まずい！

Kubernetes: よりスマート、より軽量、より柔軟 💪

Kubernetesを使用すると、マイクロサービスごとに個別のサーバーを起動する必要はありません。1つまたは2つのサーバー (VM) から始めることができます。Kubernetesは、利用可能な領域とリソースに基づいて、どのコンテナをどこに配置するかを自動的に決定します。

ストレスも無駄もありません！💡

🧑‍🍳 Kubernetesではすべてをカスタマイズできます

• 各マイクロサービスコンテナにリソースを割り当てることができます。 👉 例: 軽量な「支払い」マイクロサービスがある場合は、0.5 vCPUと512MBのメモリを割り当てることができます。リソース消費量の多い「データ分析」マイクロサービスがある場合は、2 vCPUと4GBのメモリを割り当てることができます。

• マイクロサービスごとに最小インスタンス数を設定できます。 👉 例: 「ログイン」サービスのコピーを常に2つ以上実行したい場合 (1つが失敗した場合にアプリが中断しないようにするため)、Kubernetesは常に2つのライブコピーが実行されていることを確認します。

• コンテナを好きなようにグループ化できます。 👉 チーム (財務、人事、DevOps) 別、または環境 (テスト、ステージング、本番) 別にグループ化できます。Kubernetesを使用すると、このグループ化が非常にクリーンで論理的になります。

• 個々のコンテナを自動的にスケーリングできます。 👉 より多くのユーザーがアプリにあふれた場合、Kubernetesは負荷がかかっているコンテナのみの追加のコピー (「レプリカ」と呼ばれる) を作成できます。必要のないコンテナでリソースを無駄にすることはありません。

• サーバーもスケーリングできます。 👉 トラフィックが増加すると、Kubernetesは環境 (クラスターと呼ばれる) 内のサーバー (VM) の数を自動的に増やすことができます。したがって、それぞれ30ドルの2つのVM (月額60ドル) から始めて、必要に応じてKubernetesにサーバーを追加させることができます。クラウド管理サービスの場合のように、月額500ドルのような高い固定コストに縛られることはありません。

また、Kubernetesはどこでも同じように動作します。コンテナをAWS、Google Cloud、Azure、または自分のラップトップにデプロイしても、Kubernetesは気にしません。構成は変わりません。

Elastic BeanstalkやAzure App Serviceのような管理サービスと比較してみてください。これらのサービスはプラットフォームに縛られているため、後で切り替えるのが非常に困難になります。

✅ 要するに、Kubernetesは時間とお金を節約し、多くの頭痛の種を取り除いてくれます。単一のクラウドプロバイダーに縛られることなく、また手作業に溺れることなく、マイクロサービスを実行、スケーリング、編成できます。

Kubernetesの仕組み – Kubernetes環境のコンポーネント 🧑‍🔧

マイクロサービスを数十（または数百！）も手動で実行することは、たくさんのボールをジャグリングしているようなものです。いくつか落としてしまうことは避けられません。

そのため、Kubernetesが作成されました。しかし…実際にはどのようにしてこの魔法を実現しているのでしょうか？まず、技術的な定義 (シンプルかつシャープ – インタビューに最適) から分解し、次に一般ユーザー向けのアナロジー (頭に残るように！) で分解しましょう。

1️⃣ クラスター 🏰

Kubernetesクラスターは、Kubernetesが実行されているマシン (物理またはクラウドベース) の設定全体です。これは、コンテナ化されたアプリケーションをデプロイおよび管理するために連携する、1つ以上のマスターノードとワーカーノードで構成されています。

Kubernetesクラスターは、遊び場全体であると考えてください。これは、すべてのマイクロサービスが生息し、成長し、一緒に遊ぶ環境です。

クラスターは、次の2種類のコンピューター（ノードと呼ばれる）で構成されています。

• マスターノード（最近では、コントロールプレーンと呼ばれることが多い）
• ワーカーノード

2️⃣ マスターノード (コントロールプレーン) 👑

マスターノードは、Kubernetesの頭脳のようなものです。クラスター全体を管理および調整し、どのアプリアプリケーションをどこで実行するかを決定し、状態を監視し、必要に応じてスケールを変更します。

これは、クラスター全体のボスのようなものです。アプリケーションを直接実行することはありません。代わりに、次のことを行います。

• ワーカーノードを監視する
• どのマイクロサービス (コンテナ) をどこに配置するかを決定する
• すべてがスムーズかつ公平に実行されるようにする

工場の管理者のようなものだと考えられます。管理者は、マシンに何をするか、いつ開始するか、いつ停止するか、次のパッケージをどこに送信するかを指示します。

マスターノード内には、実際の作業を処理する、いくつかの賢いミニコンポーネントがあります。

3️⃣ APIサーバー 💌

APIサーバーは、Kubernetesへの正面玄関です。ユーザーとシステムの間の通信を処理し、コマンドを受け取り、クラスターに供給します。

これは、あなた (またはあなたのチーム) がKubernetesに指示を与える場所です。新しいアプリをデプロイする場合でも、既存のアプリをスケーリングする場合でも、最初にAPIサーバーに「話しかけ」ます。これは、フロントでリクエストを送信するようなものです。APIサーバーは、リクエストを適切な人 (またはマシン) に渡します。

4️⃣ スケジューラー 📅

スケジューラーは、利用可能なリソースとニーズに基づいて、ポッド（アプリケーション）をワーカーノードに割り当てます。

新しいマイクロサービスを起動するようにKubernetesに依頼したと想像してください。スケジューラーは、次のことを確認します。

• どのワーカーノードに十分なスペースがありますか？
• どのノードに十分なメモリとCPUがありますか？
• どの場所でこのサービスが最も適切に実行されますか？

スケジューラーは決定を行い、マイクロサービスを最適な場所に割り当てます。賢いでしょう？

5️⃣ コントローラーマネージャー 🎛️

コントローラーマネージャーは、クラスターを監視するコントローラーを実行し、システムの実践状態が望ましい状態と一致することを確認します。

このコンポーネントは、システムを鷹のように監視します。Kubernetesに「常に実行されている支払いマイクロサービスのコピーを3つ欲しい」と指示したとしましょう。

それらの1つがクラッシュした場合、コントローラーマネージャーはそれを認識し、新しいものをスピンアップして自動的に置き換えます。これにより、現実が常に計画と一致していることが保証されます。

6️⃣ etcd 📚

etcdはKubernetesのメモリーです。クラスターデータが保存される分散キー値ストアです。構成ファイル、状態、およびメタデータです。

すべてのルール、記録、および計画が書き留められているノートブックを想像してください。etcdがないと、Kubernetesはすべてを忘れてしまいます。

7️⃣ ワーカーノード 💪

ワーカーノードは、実際のアプリケーションコンテナを実行するサーバーであり、クラスター内で負荷の高い作業を行います。

これらは、マイクロサービスが実際に存在し、実行されるマシンです。マスターノードは命令を出しますが、ワーカーノードは負荷の高い作業を行います。コンテナを実行します！

各ワーカーノードには、マイクロサービスを管理するためのいくつかのヘルパーがあります。

• Kubelet
• Kube Proxy

8️⃣ Kubelet 📢

Kubeletは各ワーカーノードに存在するエージェントであり、コンテナが正常で、正常に実行されていることを確認します。

マスターノードの指示をリッスンします。マスターノードが「このコンテナを実行してください！」と言うと、Kubeletがそれを実現し、実行し続けます。問題が発生した場合、Kubeletはマスターノードにレポートを送信します。

9️⃣ Kube Proxy 🚦

Kube Proxyはネットワークトラフィックを処理し、ポッドが相互に、および外部の世界と通信できることを保証します。

銀行アプリのログインサービスが支払いサービスと通信する必要があると想像してください。Kube Proxyはルーティングを処理し、リクエストが適切な場所に到達するようにします。また、負荷分散も処理するため、単一のマイクロサービスに負荷がかかりすぎることはありません。

したがって、要約すると、次のようになります。

• マスターノードはボスです。タスクを計画、監視、および割り当てます。
• ワーカーノードは、実際の作業を行います。マイクロサービスを実行します。
• etcd、Kubelet、スケジューラー、コントローラーマネージャー、Kube Proxyなどのコンポーネントは、油を差したような機械の部品のように連携して動作します。

Kubernetesは、マイクロサービスを自動的に処理するように設計されています。マイクロサービスを常に稼働させ、スケールアップし、移動し、クラッシュした場合に再起動するため、自分で面倒を見る必要はありません。

Kubernetesワークロード 🛠️ — Pod、Deployment、Serviceなど

Kubernetesワークロードは、アプリケーションの管理と実行に使用するオブジェクトです。これらは、Kubernetesに何を実行するか、どのように実行するかを指示する青写真📐であると考えてください。これは、単一のアプリコンテナ、コンテナのグループ、データベース、またはバッチジョブです。Kubernetesでは、次のワークロードがあります。

1️⃣ Pod

ポッドは、Kubernetesオブジェクトモデルの最小かつ最も単純な単位です。これは、クラスターで実行されているプロセスの単一インスタンスを表し、ストレージとネットワークリソースを共有する1つ以上のコンテナを含めることができます。

ポッドは、連携する必要がある1つ以上のコンテナをラップしたものだと考えてください。これらは同じネットワークIPおよびストレージを共有するため、簡単に通信してデータを共有できます。ポッドは一時的なものです (短時間で存在し、非常に簡単に交換できる)。ポッドが停止した場合、Kubernetesは、ほぼ瞬時に新しいポッドを作成して置き換えることができます。

2つの分散モノリス（フロントエンドとバックエンド**）**に分割されたアプリケーションがあるとします。フロントエンドはポッドAのコンテナで実行され、バックエンドアプリケーションは別のポッドBのコンテナで実行されます。

2️⃣ Deployment

Deploymentは、PodsとReplicaSetsの宣言的な更新を提供します。望ましい状態を記述します。