計画のベスト プラクティス

このトピックでは、Migrate to Containers を使用して行われた実際のアプリケーションの移行に基づいて、Google Kubernetes Engine（GKE）または GKE Enterprise にアプリケーションを移行する際に役立つ情報を提供します。

移行センターのディスカバリー クライアント CLI または mcdc CLI は、コンテナに移行する VM ワークロードの適合性を判断するツールです。

Migrate to Containers は、以下に挙げる特定のタイプの Linux および Windows ワークロードの場合に推奨されます。

適した用途

Linux

Migrate for Containers を使用した移行には、次のアプリケーション アーキテクチャを持つ Linux アプリケーションが適しています。

  • ウェブ / アプリケーション サーバー
  • ビジネス ロジック ミドルウェア（Tomcat など）
  • 複数の VM、多層スタック（LAMP など）
  • 中小規模のデータベース（MySQL、PostgreSQL など）

さらに、Migrate to Containers を使用した移行に最適なアプリケーションには、次のような運用における特徴があります。

  • アイドル状態が長い、集中的に負荷がかかるワークロード
  • 開発、ラボ環境でのテストとトレーニング
  • 常に稼働状態、負荷が低いサービス

一般に、ほとんどの Linux ワークロードは移行に互換性があります。ただし、以下の明らかに適さない用途のワークロードは除きます。

Windows

Migrate to Containers を使用した移行に適している Windows アプリケーションとしては、次のすべての特性を満たすワークロードが挙げられます。

  • IIS 7 以降、.NET Framework 3.5 以降を使用する ASP.NET
  • ウェブとロジックの階層
  • Windows Server 2008 R2 以上

オペレーティング システムのサポート

Migrate to Containers は、以下の VM オペレーティング システムと互換性があります。

適さない用途

Linux

Linux の場合、Migrate to Containers による移行に適さないアプリケーションやサーバーには、次のようなものがあります。

  • 高パフォーマンスおよび大規模なインメモリ データベース
  • 特別なカーネル ドライバを持つ VM（カーネルモードの NFS など）
  • 特定のハードウェアに依存するもの
  • 特定のハードウェア ID 登録に関連付けられたライセンスを持つソフトウェア

Windows

Windows の場合、IIS 7 以降がインストールされていないワークロードは移行に適していません。移行に適さないその他の種類のアプリケーションには、次のものがあります。

  • GPU または TPU への依存関係があるアプリケーション
  • 低レベルのネットワーキング アプリケーション
  • デスクトップ アプリケーション、RDP アプリケーション、VDI アプリケーション
  • BYOL を使用するアプリケーション

DNS およびネットワーク アクセスルール

GKE に移行する前に、移行されたワークロードで使用されるネットワーク リソースとサービスを理解し、Virtual Private Cloud からアクセス可能かつアドレスで参照できることを確認します。

Kubernetes Service の名前を計画する

ワークロードが DNS を利用してサービスにアクセスする場合は、Kubernetes の Namespace スキーム、ネットワーク ポリシー、Service の名前を計画する必要があります。

移行プロセスによって生成されるデプロイ仕様には、「ClusterIP」タイプの推奨ヘッドレス Service オブジェクトが含まれています。「ClusterIP」は負荷分散なしの、クラスタ内からのみ到達可能な単一クラスタの内部 IP です。Kubernetes エンドポイント コントローラは DNS 構成を変更して、Pod を指すレコード（アドレス）を返します。これは、deployment_spec.yaml で "app": "app-name" としてラベル付けされます。

Pod やコンテナへの接続サービスを作成して適用する

ワークロードを移行すると、ホスト名が適用されなくなります。ワークロードへのコネクションを許可するには、Service を作成して適用します。

移行した名前と IP を識別して構成する

GKE では、/etc/hosts ファイルが管理されています。Migrate to Containers では、移行元 VM から GKE への hosts ファイルの適用は、まだ自動化されていません。移行された VM 上の hosts ファイル内の名前と IP は、hostAliases として識別、構成する必要があります。

同じ Namespace に依存サービスを配置する

相互に依存するサービスは同じ Kubernetes Namespace に配置し、短い DNS 名（例えばapp や db など）を使用して通信を行います。この構成により、本番環境、ステージング、テストなどの複数のアプリケーション環境を複製することもできます。

GKE ネットワーキングを使用してアクセス サーフェスを制御する

GKE は高度なネットワーク制御を備えています。Pod には、パブリック インターネット、VPC ネットワーク、内部クラスタ ネットワークなど、さまざまなネットワークからアクセスできます。これにより、VLAN、フィルタ、ルーティング ルールの管理を複雑にすることなく、ワークロードに対するアクセス面をさらに制御して制限できるようになります。

たとえば、一般的な 3 層構成のアプリケーションには、フロントエンド層、アプリケーション層、データベース層があります。Google Cloud に移行すると、フロントエンド サービスは VPC ネットワーク上の LoadBalancer を使用して構成されます。他の階層には、GKE クラスタ外から直接アクセスできません。ネットワーク アクセス ポリシーにより、内部クラスタ ネットワーク内からは、フロントエンド Pod だけがアプリケーション サービスにアクセスできるようになります。別のポリシーにより、データベース Pod へはアプリケーション Pod のみがアクセスできるようになります。

NFS

NFS マウントを永続ボリュームとして定義する

移行計画を作成すると、移行元 VM 上にマウントされた NFS クライアントが自動的に検出され、生成されたプランに追加されます。

マウントがプランに追加される間、デフォルトでは無効になります。つまり、PersistentVolume と PersistentVolumeClaim の各定義は、移行アーティファクトの生成時には deployment_spec.yaml ファイルに含まれていません。Migrate to Containers で PersistentVolume と PersistentVolumeClaim の定義を生成するには、まず移行計画を編集して NFS クライアントのマウントを有効にする必要があります。

詳細については、NFS マウントのカスタマイズをご覧ください。

カーネルモードの NFS サーバー

NFS サーバーがカーネルモードで実行されている VM は、Migrate to Containers を使用して GKE に移行することはできません。これらの VM は、Compute Engine 上の VM に移行する必要があります。別の方法では、Filestore をクラウドネイティブな NFS ソリューションに使用することもできます。

移行元 NFS 共有からデータを移行する

移行元 VM が NFS 共有マウントを使用している場合、このデータは自動的には移行されません。NFS 永続ボリュームを使用して、移行されたワークロード コンテナに共有をマウントするか、移行元 NFS 共有がリモートの場合は、データを別のファイル共有にコピーして、クラスタへのアクセス レイテンシを減らします。

データのコピー方法のオプションについては、以下を参照してください。

  1. Storage Transfer Service または Transfer Appliance。

  2. gcloud storage rsync を使用してデータをコピーする（移行元のファイル共有からバケットへ、その後バケットからクラウド内のファイル共有へ移行）。

  3. NetApp SnapMirror から NetApp Cloud Volumes へなど、サードパーティのソリューション。

  4. Rsync などの OSS ユーティリティ。

データベースにアクセスできるようにする

アプリケーションが、VM または外部マシンで実行されているデータベースに依存している場合は、新しく移行した Pod からデータベースに引き続きアクセスできることを確認する必要があります。ネットワーク ファイアウォール ポリシーで、クラスタからデータベースへのアクセスが許可されていることを確認する必要があります。

データベースを Google Cloud に移行するには、Database Migration Service の使用をおすすめします。

また、クラスタ内でデータベースを実行することもできます。詳細については、GKE でのデータベース デプロイを計画するをご覧ください。

挿入されたメタデータが使用できることを確認する

アプリケーションが、挿入されたメタデータに依存する場合（環境変数など）は、そのメタデータが GKE で利用できることを確認する必要があります。同じメタデータ挿入方法が利用できない場合、GKE では ConfigMaps と Secret が提供されます。

ランレベル 3 で開始するために必要なサービスを構成する

Migrate to Containers ワークロードはランレベル 3 にのみ到達します。Migrate to Containers を使用して GKE に移行された VM は、Linux のランレベル 3 のコンテナで起動されます。特定のサービス（たとえば VNC を使用したリモート GUI アクセス用の X11 や XDM など）は、デフォルトでランレベル 5 でのみ起動するように構成されています。必要なサービスがランレベル 3 で開始されるように構成する必要があります。

不要なサービスを無効にする

Migrate to Containers は、ハードウェア固有のサービスや環境固有のサービスに加え、VM 上で実行される事前定義された一連の追加サービスを自動的に無効にします。ワークロードをコンテナに移行した後は、これらのサービスは必要ありません。

たとえば、Migrate to Containers は、iptables、ip6tables、firewalld を自動的に無効にします。Migrate for Containers により無効にされるサービスの完全なリストについては、blocklist.yaml ファイルをダウンロードしてください。

無効になっているサービスのカスタマイズ

デフォルトでは、Migrate to Containers は、上記の不要なサービスを無効にします。移行計画をカスタマイズしてブロックリストを定義することで、移行先のコンテナで無効にするサービスについて独自のカスタムリストを定義することもできます。ブロックリストには、移行されたコンテナで無効にするサービスを 1 つ以上指定します。

移行した VM の維持と更新

移行中に生成したアーティファクトを使用して、アプリケーションやユーザーモードの OS ソフトウェアの更新、セキュリティ パッチの適用、埋め込み構成の編集、ファイルの追加や置き換え、Migrate to Containers ランタイム ソフトウェアの更新などを行えます。

詳細については、移行後のイメージの更新をご覧ください。

次のステップ