Kubernetes コンテナ クラウド プラットフォームへの移行について知っておくべき 9 つのこと

1. 既存のプラットフォームが直面する課題

コンテナへの移行に対する当初の意図は企業によって異なります。企業によっては、運用保守エンジニアや運用保守チームを持たず、特定のプラットフォームを利用して運用保守の自動化を実現したいと考えているところもあります。

企業によっては、コンピューティング リソースの利用率が低い場合があります。大手インターネット企業の中には数万台のサーバーを保有しているところもありますが、私の個人的な経験では、コンピューティング リソースの利用率は高くありません。これには多くの歴史的な理由がありますが、その 1 つは、より優れた隔離を実現することです。分離を実現する最善の方法は、物理マシンから仮想ベースのプライベート クラウドへのテクノロジを採用することです。

長い歴史を持つ企業では、アプリケーションの展開がローカルの運用環境に強く関連していることが多く、移行が非常に困難になります。このとき、分離するための適切なソリューションも必要です。また、業務量が多くなると管理の複雑さも増します。

[[238633]]

2. Kubernetesを選ぶ理由

上記の問題は、当社の生産現場でさまざまな程度で発生しています。解決策は数​​多くありますが、最終的にKubernetesを選択しました。

Kubernetes はまず第一に、コンピューティング リソースの使用率が低いという問題を解決し、サーバーの数を半分に削減しました。コンテナ化はコンピューティング リソースの利用の問題を解決します。

ビジネス コンテナ イメージは一度ビルドすると、複数の環境で実行できます。このアプローチにより、運用環境への依存度が低減され、運用および保守プラットフォームに十分な柔軟性がもたらされ、サービス プロバイダーのロックインの問題が解決されます。当時検討していたのは、あるIDCサービスプロバイダーがサービス要件を満たさなかった場合に、いかにして迅速な移行を実現するかということでした。一般的に、大量のサービスを移行するにはコストが非常に高く、時間がかかります。コンテナ化後、業務移行にかかる時間はわずか 30 分程度です。

Kubernetes のアーキテクチャ設計のアイデアを通じて、Web サイト システムのアーキテクチャ設計を標準化することもできます。 ***もう一つのポイントは、運用・保守の自動化を実現していることです。

3. コンテナクラウドプラットフォームへの移行前の準備

コンテナ クラウドに移行するには、企業は一定の運用および保守機能を必要とします。企業の規模が十分でない場合は、国内のコンテナ クラウド サービス プロバイダーを検討することもできます。私たちが行ってきた準備のいくつかについてお話ししましょう。

最初に行うことは、Kubernetes クラスターを構築することです。ハーバーを使用してプライベート Docker イメージ リポジトリを構築し、独立したクラスター監視を実行します。 CI/CD の基本設定には Jenkins と helm が使用され、分散ストレージ ソリューションには Glusterfs が使用されます。

IV.ビジネス移行で使用される仕様

Kubernetes には、2015 年末のバージョン 1.0 からその後のバージョン 1.2、1.3 に至るまで、依然として多くの問題が残っています。企業がこれを利用するには、ある程度の勇気が必要です。しかし、今では基本的に成熟しており、あまり変更を加えなくてもほとんどのアプリケーションで問題なく実行できます。

それでも、すべてのアプリケーションをコンテナ クラウドに移行できるわけではありません。アプリケーションがクラウドネイティブの設計原則に十分準拠できる場合は、確かに移行できますが、ほとんどのアプリケーションはそのような設計原則に従って設計されていません。現時点では、まずビジネスを移行し、その後徐々にマイクロサービス アーキテクチャに進化させるのが最善の方法です。

このプロセスでは、実際には最初は仕様がまったくなく、その後徐々に関連する仕様を策定しました。移行仕様を詳しく見てみましょう。

1. コンテナイメージパッケージングの基本原則

初期の頃は、多くのシステム アーキテクトが Docker を軽量の仮想マシンとして使用していましたが、これはベスト プラクティスではありません。 Docker を正しく使用するには、次の基本原則に従う必要があります。

• 可能な限りステートレスなサービスとして設計してください。利点は、水平方向に非常に簡単に拡張できることです。
• 不要なオペレーティング環境への依存性を可能な限り排除します。コンテナ内のビジネスに依存しすぎると、水平展開が非常に難しくなります。従来の展開形式では、仮想マシンの展開であれ物理マシンの展開であれ、さまざまな不要な依存関係が生成されることがよくあります。この問題は、一定の歴史を持つ企業にとっては非常に深刻となります。
• 永続化が必要なデータは分散ストレージボリュームに書き込まれます
• 分散アプリケーションを簡単に拡張できるように、ビジネスを可能な限り単一に保ちます。これはマイクロサービス アーキテクチャの設計原則でもあります。
• stdout と stderr に書き込まれるログの量を制御する
• コンテナイメージコンテンツからの構成の分離
• コンテナ内のIPアドレス設定の代わりにK8S内部DNSを使用する
• 集中ログ処理ソリューション (EFk)
• 独立したコンテナを使用してスケジュールされたタスクを処理する

2. 名前空間の使用

テスト環境やステージング環境などの運用環境のリソース使用率は高くないことを考慮して、開発環境、テスト環境、ステージング環境、本番環境をクラスター内で同時に実行したいと考えています。 NameSpace は異なるオペレーティング環境を分離するために使用され、異なるオペレーティング環境のアプリケーション ソフトウェア間で名前の競合は発生しません。

3. サービス命名標準

バージョン 1.5 より前では、サービス名は 24 文字を超えることはできません。バージョン 1.5 以降では、最大長は 63 文字です。さらに、正規表現 [az] ([-a-z0-9] * [a-z0-9])? の要件を満たす必要があります。つまり、最初の文字は az の文字である必要があり、最後の文字は - であってはならず、残りは文字、数字、および - 記号にすることができます。一般的には、命名方法は「ビジネス名-アプリケーションサーバータイプ-その他の識別子」という形式を使用します（例：book-tomcat-n1、book-mysql-m1 など）。

4. ヘルスチェック仕様を適用する

アプリケーション ヘルス チェック仕様は、自動化された運用と保守を実現するための重要な部分であり、システム障害を自動的に検出して自己回復するための重要な手段でもあります。現在、ヘルスチェックの方法には、プロセス レベルとビジネス レベルの 2 つがあります。

プロセスレベルのヘルスチェックは、Kubernetes 自体の機能です。これは、コンテナ プロセスが稼働中かどうかを確認するために使用され、デフォルトで有効になっています。

ビジネスレベルのヘルスチェックは自社で実施しています。要件は3つあります。まず、コア業務が正常かどうかを確認する必要があります。 2 番目に、ヘルスチェック プログラムの実行時間はヘルスチェック サイクルよりも短くなければなりません。 3 番目に、サービスジッターを回避するために、ヘルスチェック プログラムのリソース消費を適切に制御する必要があります。

ヘルス チェック手順は、環境によって実装が異なります。

• HTTP GET メソッドは、Web サービスのヘルス チェックに使用されます。 「/healthz」URL を実装する必要があります。この URL に対応するプログラムは、すべてのコア サービスが正常かどうかを確認する必要があります。ヘルスチェックプログラムは、異常な状況下では各チェック項目のステータスの詳細も出力する必要があります。
• その他のネットワーク サービスの場合、コンテナーの指定されたポートのステータスを使用して、コンテナーのヘルス ステータスを判断できます。
• 非ネットワーク サービスでは、コンテナ内で特定のコマンドを実行する必要があり、コンテナのヘルス ステータスは終了コードに基づいて決定されます。

5. YAMLでのイメージタグの設定仕様

コンテナ イメージをデプロイするときは、最新のタグ形式の使用を避ける必要があります。そうしないと、問題が発生した場合に、現在実行中のイメージ バージョンを追跡してロールバックを実行することが困難になります。したがって、各コンテナ イメージのタグはバージョン番号で識別することをお勧めします。

6. ConfigMapを使用してスムーズなアプリケーション移行を実現する

初期の 1.0 バージョンの設定情報はすべて設定ファイルに書き込まれていました。移行には多くの変更が必要でした。当時は、構成情報を渡す方法がいくつかしかありませんでした。その 1 つは、環境変数を介して渡すことであり、その後、変換のために内部的に対応するメカニズムが必要でした。これは実は非常に面倒なプロセスでした。しかし、ConfigMap ができたので、元の構成ファイルを ConfigMap にインポートするだけで済みます。

V. 移行中に遭遇したその他の問題

1. CI/CDについて

移行時には、Jenkins を使用して CI/CD を実装し、Helm を使用してソフトウェア パッケージを管理しました。 Helm は Kubernetes の公式サブプロジェクトです。社内の企業アプリケーション管理に非常に便利です。これにより、開発者は Kubernetes 自体ではなくアプリケーション開発に集中できるようになります。

2. タイムゾーンの設定の問題

公式サイトからダウンロードした画像には、デフォルトのタイムゾーンが設定されます。通常、使用時にはタイムゾーンを変更する必要があります。タイムゾーンを変更する方法はたくさんあります。ここに2つの簡単な方法があります。 1 つは、コンテナ イメージの /etc/loacltime を必要に応じて対応するタイム ゾーンに設定する方法であり、もう 1 つは、構成ファイル内のボリュームを使用して、ホストに対応する localtime ファイルをマウントする方法です。 2番目の方法をお勧めします。

3. 外部ネットワークアクセスサービス

Ingress がなかったときは、組み込みの Nginx コンテナを使用してクラスターの内部サービスを転送していました。現在、Ingress を使用してクラスターの内部サービスを転送しており、Ingress は NodePort を通じて外部ネットワークに公開されています。

***組み合わせ

上の図は、DevOps をベースにした Kubernetes の最適な組み合わせを示しています。上位層は k8s とコンテナで構成され、最上位層はマイクロサービス アプリケーション上に構築されます。この組み合わせにより、コンテナ クラウドが実現されるだけでなく、主にマイクロサービスのアーキテクチャ概念の影響を受ける R&D プロセスと組織構造も変化します。

以前は、アプリケーションのバージョンのリリースを完了するには複数の人の協力が必要になることがあり、緊急リリースが発生すると、これが実際には非常に面倒であることがわかりました。ただし、アプリケーションがマイクロサービス アーキテクチャに基づいている場合、通常は 1 人または 2 人がマイクロサービスを維持でき、マイクロサービスを独立してデプロイするかどうかを決定できます。

マイクロサービスと Kubernetes には、強調しなければならないもう 1 つの利点があります。 CI/CD を使用すると、開発者はデプロイメント環境の詳細について心配する必要がなくなります。