テクノロジー マネージャー向け Kubernetes 導入ガイド

導入

社内ではKubernetesの話をよく耳にすることがあるかもしれません。 Google 発のこのコンテナ オーケストレーション テクノロジーは現在非常に人気があります。 DevOps であろうと CTO であろうと、このテクノロジーを完全に理解しているかどうかに関係なく、全員がこの話題について話しているようです。この記事を読むと、さらに混乱したり、完全に理解できなかったりする可能性があります。 Kubernetes がすべての問題の解決に役立つことを期待する人もいますが、そうではありません。この記事では、Kubernetes を導入するかどうか、またどの程度導入するかを決める際に役立つ重要な要素をいくつか紹介します。また、Kubernetes を評価して組織に導入するためのステップバイステップのアプローチも紹介します。 Kubernetes は、正しく使用すれば大きなメリットをもたらす優れたテクノロジーです。

[[312753]]

1. ペットから羊へ

> 以前は、サービスはペットのようなもので、管理者が 1 つずつ管理および保守する必要がありました。現在、サーバーは羊のような存在となり、管理者は簡単なコマンドや設定で多数のサーバーを管理できるようになりました。

かつて、システム管理者はホスト名と付箋を使用してサーバーを管理していました。現在、コンピューター室やデータセンターに設置されるべきマシンが Amazon、Microsoft、Google などのパブリック クラウド プロバイダーに取って代わられたため、ワークロードがどのような種類のサーバー上で実行されているかはわかりません。システム管理者は、いつものように、ペットと同じように、パブリック クラウド上で実行されている仮想マシンに名前を付けます。しかし、以前は、営業担当者がサーバーを必要とする場合、システム管理者が数週間を費やし、電話や電子メールで営業担当者と話をしてサーバーを構成する必要がありました。しかし、高性能仮想化とパブリック クラウド API の登場により、単純な API 呼び出しで数秒でマシンを起動できるようになりました。賢明な技術者は、パブリック クラウドはコンピューティングへの高速アクセスを提供するだけでなく、使いやすい RESTful API を提供することで自動化機能も提供することを認識しました。とても美しいですね。

2. インフラストラクチャとしてのコードとDevOps

Chef、Puppet、Ansible、SaltStack テクノロジーの登場により、開発と運用の境界はますます曖昧になっています。これまで、システム管理者がシェル スクリプト以外の言語を使用することはほとんどありませんでしたが、Chef、Puppet、Ansible はすべて成熟したシステム オーケストレーション フレームワークです。 Puppet はドメイン固有言語 (DSL) を使用してシステム管理者がインフラストラクチャ設定の最終状態を定義できるようにします。一方、Chef は Ruby ベースの DSL を使用して、Ruby 言語の表現力を最大限に活用し、インフラストラクチャの最終状態を定義します。これらのテクノロジーにより、宣言型アーキテクチャと命令型アーキテクチャの時代が到来し、ファイル内のコードを通じてサーバー インフラストラクチャの最終状態を定義できるようになり、ソース コードを管理するのと同じようにアーキテクチャのバージョン管理が可能になります。これは、手動でサーバーをセットアップし、ログインしてさまざまなソフトウェアをインストールし、ハードウェア リソース (ネットワーク、ストレージなど) をセットアップすることとは大きく異なります。管理者は、このプロセスをより効率的にするためにいくつかのスクリプトを実行する場合があります。現在では、Chef と Puppet を使用するとシステム構成を集中管理でき、強力な API を通じて多数のサーバーを簡単に管理できます。

3. Dockerの台頭

Docker はコンテナ技術ではありません。 Linux 本来の機能を活用してコンテナを簡単に管理、結合できる強力なツールです。 Linux コンテナは、Linux オペレーティング システムの元の機能 (CGroups、つまりコントロール グループと名前空間) を使用して構築されます。 Docker を使用すると、コンテナの構築と管理が簡単になります。 Docker を使用すると、アプリケーションとそのすべての依存関係を簡単にパッケージ化できます。本物のコンテナと同じように、「発送」がとても簡単になります。このコンテナは、依存関係 (一部は Linux ディストリビューション固有のもの) を事前にインストールしなくても、任意の Linux マシンで実行できます。コンテナ テクノロジーを使用すると、Debian Linux から Nginx、Ubuntu から Python Flask フレームワーク、Alpine から MySQL を実行できます。これらのソフトウェアが一緒にユーザーのアプリケーションを構成し、これらすべてのソフトウェア パッケージが同じ Linux サーバー上で実行されます。要約すると、Docker はコンテナを宣言的に構築するための標準を提供し、Linux サーバー上でコンテナのライフサイクルを実行および管理するためのツールを提供します。 Linux のコンテナ技術をうまく活用し、大きな利便性を提供します。

Puppet と Chef は物理マシンと仮想マシンの構成を管理するのに優れていますが、DevOps ではコンテナを使用してアプリケーションをデプロイすることを好みます。コンテナは急速に標準となり、コンテナには多くのアプリケーション展開ロジックを含めることができるため、残りのビジネス プロセスが簡素化されます。より現代的なコンテナ中心のオーケストレーション システムを使用する時期が来ています。

同時に、急速に発展している別のアプローチである DevOps により、運用担当者が開発者の分野にますます関与するようになりました。エンジニアは、運用担当者はシステムの安定性を望んでいる一方で、開発者はいつでも新しい機能をリリースしたいと考えており、これが安定性に大きな課題をもたらしていることに気付きました。これら 2 つの目標は互いに矛盾し、チーム内で議論を引き起こし、製品の納品速度に直接影響を及ぼしました。そして、開発チームは、自分たちのコードが本番環境でどのような問題を引き起こすかを理解するまで、その問題を修正する努力をしません。実稼働環境は通常、運用保守チームによって処理されるためです。これらの問題を解決するために。チームは新しいアプローチである DevOps を試し始めました。このアプローチは非常にシンプルです。コードを書いた人がそれを本番環境にリリースする責任を負います。その後のシフトも担当します。開発者が新機能をより頻繁にリリースしたい場合は、オペレーターとしてリリースをサポートするために何をする必要があるかを理解する必要があります。強力な API とツールチェーンを備えたクラウドおよびコンテナ テクノロジにより、このアプローチをクラウド運用に組み込むことができます。現在では、DevOps チームはマイクロサービスで構成された大規模なアプリケーションを構築しており、各マイクロサービスは、大規模なアプリケーション全体をテストしてリリースすることなく、個別に開発およびリリースできます。 DevOps を試しているチームは、プログラマーがスクリプト可能なツールや API を通じて簡単に制御できるクラウドとコンテナの可塑性と柔軟性を気に入っているため、マイクロサービス アーキテクチャを使用します。

4. Kubernetesの登場

DevOps とマイクロサービスがコンテナと出会うと、新しいネイティブ オーケストレーション フレームワークが誕生しました。 Kubernetes は、Google の Borg システムに触発され、もともと Google のエンジニアによって構築され、現在は CNCF (Cloud Native Computing Foundation) によって管理されているオープンソースのコンテナ オーケストレーション システムです。コンテナ オーケストレーション プラットフォームとして、Kubernetes はアプリケーションの展開、スケーリング、管理を自動化できます。 Docker などのシステムでもサーバー内のコンテナを管理できますが、Kubernetes はより強力で、コンテナを実行するサーバーまたはノードのクラスターを管理できることが主な機能の 1 つです。同様のフレームワークには、Apache Mesos や Docker Swarm などがあります。しかし、これまでのところ、Kubernetes が明らかに勝者として浮上しています。現在、コンテナ オーケストレーション フレームワークとして Kubernetes を選択することは非常に安全な選択です。

4.1 Dockerだけではない

Kubernetes は Docker によって管理されるコンテナだけでなく、コンテナもオーケストレーションできることは注目に値します。また、ContainerD、Cri-O、RktLet などの Docker のようなシステムによって管理されるコンテナをオーケストレーションすることもできます。これらのシステム用のコンテナを作成して管理できますが、この記事では「コンテナ管理」を指すために「Docker」を使用します。それでは、Kubernetes の最も重要な機能のいくつかを見てみましょう。

4.2 なぜ Kubernetes なのか?

Kubernetes がなぜそれほど重要なのかを理解するには、まず Docker の境界を理解する必要があります。 Docker はサーバー内のコンテナのライフサイクルを簡単に管理できますが、Kubernetes は Docker コンテナを実行している複数のサーバー (つまり、クラスター) を簡単に管理できます。一方、最近では、マイクロサービス アプリケーションは複数のコンテナーで構成されることがよくあります。 Kubernetes は、「アプリケーション デプロイメント」という概念を提供します。これは、アプリケーションを構成し、クラスター上で分散して実行されるコンテナーのグループを指します。コンテナのセットで構成されるアプリケーションを実行したい場合は、Kubernetes に伝えるだけで、Kubernetes はクラスター内のどのノードにコンテナを実行するのに十分なコンピューティング リソースがあるかを判断し、そこにスケジュールします。 Kubernetes は、コンテナに障害が発生した場合にコンテナを再起動し、トラフィックの急増に対応するためにコンテナの数を増やすなど、特定のパラメータに基づいてアプリケーションを拡張することもできます。これが Kubernetes の本質であり、「コンテナ オーケストレーション」と呼ばれるものです。

クラスター上で複数のアプリケーションを実行する場合、Kubernetes は管理を簡素化する他の機能も提供します。アプリケーション構成と証明書の管理が容易になります。 Kubernetes は、あらゆるインフラストラクチャの最も基本的な 3 つのコンポーネントであるストレージ、ネットワーク、コンピューティングなどの他のインフラストラクチャも管理します。

4.3 ホスティング

プライベート クラウド上で Kubernetes をゼロから構築することもできますが、Kubernetes インフラストラクチャを拡張する前に、有料サポートを提供する OpenShift の Kubernetes ディストリビューションを選択することをお勧めします。もちろん、AWS、Azure、GCP のクラスター上に Kubernetes を構築することもできます。 Kubernetes は、クラスター (コンピューティング ノードと呼ばれる) を実行するために連携する複数のコンポーネントで構成されており、各コンポーネントでも Kubernetes が実行されます。任意のパブリック クラウドからマネージド Kubernetes サービスを選択すると、Kubernetes クラスターを形成するために提供される任意のタイプのコンピューティング ノードを選択できます。これはコンテナーの展開に使用できますが、Kubernetes のメイン マスター コンポーネント (「コントロール プレーン」とも呼ばれます) はクラウド サービス プロバイダーによって管理されます。

5. あなたの組織は Kubernetes の導入準備ができていますか?

これはいくつかの要因に依存します。

5.1 パブリック クラウドかプライベート クラウドか?

Kubernetes はパブリック クラウドとプライベート クラウドにデプロイできます。プライベート クラウドでは、理論的には Kubernetes を自分でインストールして保守することもできますが、ベンダー サポートが付属する OpenShift などの提供された Kubernetes ディストリビューションを実行する方が適切です。 Kubernetes はクラウドで生まれた、いわゆる「クラウド ネイティブ」テクノロジーであり、コンピューティング クラスターの管理に最適です。実際、Kubernetes はプライベート クラウドの管理にも最適な選択肢です。

AWS、Azure、GCP などのパブリック クラウドでは、一連のコンピューティング ノード上で Kubernetes を実行できます。たとえば、Kops (一般的なソリューション) を使用して、AWS の EC2 インスタンスに Kubernetes をデプロイできます。ただし、Kubernetes コントロール プレーンの保守作業をクラウド サービス プロバイダーに引き渡すマネージド Kubernetes サービスを選択することを強くお勧めします。これにより、Kubernetes でのワークロードの実行に集中できるようになります。

5.2 プロジェクトにおける Docker の採用の現在のレベルはどの程度ですか?

Kubernetes はエントリーレベルの製品ではなく、コンテナ オーケストレーション プラットフォームです。 Kubernetes 上で実行する予定のアプリケーションがまだコンテナ化されていない場合は、まずこれらのアプリケーションが本番環境の Docker 上で十分にテストされていることを確認する必要があります。後ほど、これを段階的に実装する簡単な戦略を紹介します。 Docker は広く採用され、ツールも成熟しており、Docker は誇大宣伝の段階をはるかに超えていると言っても過言ではありません。組織の IT 戦略がどれほど「慎重」であったとしても、Docker を導入することに大きなリスクはありません。 Docker と Kubernetes を適切に組み合わせると、サーバーの使用率を大幅に向上させることができます。したがって、この問題は検討する価値がある。

5.3 組織内の DevOps 文化はどの程度成熟していますか?

強力な DevOps 文化とは、開発者が開発したサービスを本番環境で実行する責任を持ち、生産性を向上させるために常に自動化を求めていることを意味します。特に、アプリケーションまたはサービスがマイクロサービス アーキテクチャに基づいている場合、つまり、異なるチームがそれぞれ異なるマイクロサービスを独立して実行する必要がある場合、Kubernetes はこの状況に非常に適しており、社内で迅速に導入できます。一方、Kubernetes はモノリシックなワークロードも非常にうまく実行できます。ここで重要な点は、開発チームと運用チームという 2 つの別々のチームがあり、運用チームがまったく新しいデプロイメント方法で作業し、開発チームがコンテナ化とアプリケーション構成のためのビルド システムに適応するために作業している場合、両方のチームがこれを実現するためにあまり努力しない可能性があるということです。

5.4 組織内に Kubernetes を理解している従業員が十分にいますか?

Kubernetes を学習するにはある程度の時間がかかるため、コンテナ化を学習した後にのみ Kubernetes を学習するのが理にかなっています。 Kubernetes が組織に適していると確信し、上記の点を考慮した場合、Kubernetes を本番環境で使用できる能力と自信のある数人のチャンピオンが必要になる可能性があります。組織に Kubernetes を初めて使用する人しかいない場合は、Kubernetes を本番環境で使用するリスクを軽減しながら経験を積むためのパスを提供します。やり方については後で説明します。

6. Kubernetesの落とし穴

Kubernetes を万能薬と呼ぶ人がいるとしたら、それはおそらくまだ初期段階にあるのでしょう。注意すべき点がいくつかあります。

6.1 マネージドKubernetesは万能薬ではない

Kubernetes は、連携して動作する多数のソフトウェアで構成されたシステムです。直接管理する場合でも、Kubernetes をホストすることを選択した場合でも、問題が発生する可能性があります。ホストされた Kubernetes の場合でも、さまざまなコンポーネントで問題が発生する可能性があります。 Kubernetes コントロール プレーンがクラウド プロバイダーによって管理されているからといって、問題が起こらないとは考えないでください。 Github には、クラウド プロバイダー固有の Kubernetes の問題がいくつか掲載されています。問題が発生した場合、サポートに連絡して対処する必要がある場合があります。ダウンタイムが発生する可能性があります。コントロール プレーンの Kubernetes コンポーネントはコンテナの作成と監視のみを行うため、障害が発生しても、すでに実行中のコンテナには通常影響しません。ただし、コントロール プレーンの問題により、新しいコンテナを作成したり、コンテナの数を自動的に調整したりする機能に影響する可能性があります。

6.2 Kubernetes上のステートフルアプリケーションは進化し​​続けている

Kubernetes は、（短命の）コンテナを作成および破棄するアプリケーションに適しています。トラフィックの急増に対処するために、一時的に多数のコンテナが作成され、状況が正常に戻ったら終了されます。バックグラウンドジョブランナーと同じです。これは、サーバーが個別ではなく全体として扱われる、非常に動的な環境になることを意味します。つまり、データベースのようなステートフル アプリケーションは考慮されていないようです。実際、データベース分野の開発は非常に活発であり、この機能は現在比較的安定しています。ただし、Kubernetes ステートフル アプリケーションの機能は依然として急速に変化しています。

Kubernetes 自体は、ステートフル アプリケーションでの永続ボリュームの使用をサポートしています。もちろん、クラウド プロバイダーと同じ方法で、ステートフル アプリケーションに永続ボリュームを割り当てることもできます。

基盤となるクラウド プロバイダーによって管理されるステートフル サービス (RDS、DynamoDB など) を使用する場合は、Kubernetes サービス カタログを使用して、Kubernetes がクラウド プロバイダーによってホストされているサービスを利用できるようにする必要があります。

6.3 Kubernetes のアップグレード

Kubernetes クラスターをアップグレードするとどのような結果になるか不安な場合は、既存のクラスター設定を維持することを好むかもしれません。最善のアプローチとしては、本番クラスターと同じバージョンの Kubernetes と構成で新しいクラスターを作成し、すべての重要なアプリケーションをインストールしてそのクラスターをアップグレードし、すべてが機能するかどうかを確認し、機能する場合は本番環境でクラスターをアップグレードすることが考えられます。 Kubernetes とそのメリットを真剣に考えている場合、クラスターのアップグレードは避けられません。したがって、計画と実行が最善の解決策です。

6.4 柔軟なコンポーネントが多数

仮想化技術に関しては、それはすでに私たちが慣れ親しんでいる抽象化技術です。実際、誰かが「コンピュータ」や「サーバー」について言及する場合、ほとんどの場合、仮想マシンについて言及しています。 Kubernetes は、アプリケーションの新しい標準基盤プラットフォームになる可能性があります。新しいレベルの抽象化が新たな標準になります。仮想マシンに関しては、ほとんどの大規模システムが Linux の KVM テクノロジを標準化しているため、これはオペレーティング システム層の不可欠な部分であり、他のコンポーネントも関係していますが、それらは非常に低レベルです。これは、コンピューティング、ストレージ、ネットワーク、自動スケーリングの点でかなり複雑な操作を実行する、さまざまなマシン間で相互に通信する 12 個のサービスが存在する Kubernetes とは大きく異なります。

問題が発生した場合、傍観者でいなければならない場合があります。 Kubernetes で使用されるこれらのコンポーネントのさまざまなバージョンはすべて、ある程度は相互に調整されていると想定することしかできません。少なくとも、クラウド サービス プロバイダーは私たちにそう信じさせようとしています。

6.5 Kubernetes の人材の確保

Kubernetes を導入したいが、それをサポートする人が 1 人しかいない場合は、自己責任で導入する必要があります。 Kubernetes はプロジェクトでその価値を証明していますが、これから説明するように、DevOps チーム全体に Kubernetes のトレーニングを行うか、自分で学習することが重要です。結局のところ、ホットなテクノロジーをトレーニングする機会を望む人は誰でしょうか?一方、将来的に Kubernetes 実行の継続性を維持するには、1 人や 2 人ではなく、Kubernetes に精通した DevOps チームが必要です。信じてください。Kubernetes が LinkedIn のページにスキルとして記載されているため、転職は容易であり、このタスクの実行を 1 人か 2 人だけに頼ることはできません。

7. 組織にKubernetesを導入する

この時点で、組織に Kubernetes を導入することでメリットが得られると確信している場合は、以下の手順に従って、Kubernetes についてチームに段階的に教育し、運用ワークロードの管理に導入することができます。

7.1 Kubernetesの人材を育成または雇用する

計画を実行するには、Kubernetes の知識と実践的なスキルを備えた人材が DevOps チームに必要です。高品質のトレーニング教材が利用できるので、独学することも、より正式なトレーニング プログラムを受講することもできます。クラウド プロバイダーに問い合わせて、組織専用のトレーニングを提供できるかどうか、またはチームで受講できるトレーニングがあるかどうかを確認する必要があります。お住まいの地域では他の有料オプションが利用できる場合があります。

Kubernetes の才能のある人材を雇うことも別の選択肢です。 Kubernetes を使用して本番環境のワークロードを実行した経験のある人を探します。採用する際には、これまでどのように本番環境に導入してきたか、Kubernetes で本番環境のワークロードを実行する際に直面する課題について話し合うとよいでしょう。ステートフルワークロードを実行しているかどうかを尋ねます。これらの話し合いを通じて、彼らがあなたのプロジェクトに適しているかどうかを判断できるはずです。

7.2 ワークロードを Docker に移行する

まず、ワークロードを Docker に移行し、次に Dodcker から Kubernetes に移行する必要があります。アプリケーションが Docker 上で実行されておらず、Kubernetes に直接移行する場合、問題が発生した場合、その原因がビルド時、実行時、または構成の問題のいずれであるかを正確に指摘することはできません。一方、チームがワークロードをコンテナ化し、Docker を使用して本番環境で実行することに時間を費やす場合は、心配する問題は少なくなります。

7.3 Kubernetes 上で非本番環境ワークロードを実行する

ワークロードがコンテナ化されたので、開発ワークロードや一時ワークロードなどの一部の非本番環境ワークロードを Kubernetes に移行できます。こうすることで、大規模なチームがまず新しい環境に慣れ、Kubernetes を継続的なデプロイメント パイプラインに統合するなどの作業が可能になります。

7.4 ステートレスワークロードの移行を優先する

運用ワークロードを Kubernetes に移行する場合は、ステートレス ワークロード (リクエストのみを処理し、データを直接保存しないコンテナー) から始めます。 Kubernetes 上でステートフル ワークロードを実行するには、Kubernetes に関するより深い専門知識が必要です。ステートフル ワークロードの場合、ノードに障害が発生した場合の管理方法について、より慎重に計画する必要があります。これは、たとえば Elasticsearch のような分散型ステートフル アプリケーションの場合、特に複雑になります。

7.5 重要でないワークロードの移行

まず、重要でないワークロードのみを Kubernetes に移行し、チームに Kubernetes 上で本番ワークロードを実行する経験を積ませます。たとえば、本番環境でワークロードを実行するには、監視、アラート、アプリケーションのアップグレードが必要です。

7.6 大きな飛躍

上記の手順では、専門知識を構築し、リスクを軽減しながら組織に Kubernetes を導入する方法を説明しました。また、コンテナ化して本番ワークロードを Kubernetes に徐々に導入するために、エンジニアリングの観点からどのように準備するかについても説明しました。いつがベストなタイミングかを判断するだけです。組織ごとに採用率やリスク率は異なるため、最善の判断を下す必要があります。私の推奨は、Terraform などのツールを使用して、Kubernetes クラスター自体のデプロイメントを自動化することです。

8. 結論

最善の計画は常に最悪のシナリオを考慮したもので、これがこの記事の主な目的です。Kubernetes を導入する際の潜在的な問題とリスクを軽減する方法を説明します。 Kubernetes は素晴らしいテクノロジーです。それは間違いなく多くの点であなたを助けるでしょう。ただし、本番環境のワークロードに使用する予定のテクノロジの場合と同様に、リスクを比較検討して、メリットがリスクを上回るかどうかを確認する必要があります。 Kubernetes の失敗事例を調べることは、最も一般的な問題とその解決方法を見つけるのに役立ちます。

個人的には、Kubernetes と、その上で本番環境のワークロードを実行することに非常に興奮しています。 Kubernetes が提供するオーケストレーション、自動スケーリング、サーバー使用率の向上、自己修復機能はすべて実際のメリットをもたらし、実装に時間を費やす必要はありません。

翻訳者紹介:プログラマーのグレースは、ニューヨーク州立大学ストーニーブルック校を卒業し、現在はLinktime Cloud Companyに勤務しており、コンテナ化技術とデータ可視化技術に興味を持っています。