変更要約: Professional Cloud Developer 第4章を新規作成（ドメイン3「デプロイ向け構成」: Cloud Run へのデプロイ＝ソースデプロイ/リビジョン/トラフィック分割/Eventarc・Pub/Sub トリガー/Apigee、GKE へのデプロイ＝Deployment/Service・liveness/readiness プローブ・Horizontal Pod Autoscaler・Cloud Run との使い分け）。
4.2GKE へのデプロイ
GKE へのコンテナ化アプリのデプロイ（Deployment・Service）、可用性を高める Kubernetes のヘルスチェック（liveness/readiness プローブ）、Horizontal Pod Autoscaler によるスケーリング、そして Cloud Run と GKE の使い分けを理解します。
より細かな制御や複雑なオーケストレーションが要るなら GKE（Kubernetes）へデプロイします。可用性とスケーラビリティを Kubernetes の仕組みで担保します。
4.2.1デプロイとヘルスチェック
コンテナ化アプリは Deployment（望ましい Pod 数を宣言）で配置し、Service でネットワーク公開します。可用性を高めるには ヘルスチェック（liveness プローブ＝異常時に再起動、readiness プローブ＝準備できるまでトラフィックを送らない）を設定します。これにより、起動途中や不調の Pod に誤ってリクエストが届くのを防ぎます。「異常時に再起動＝liveness」「準備完了まで送らない＝readiness」と結びます。
4.2.2スケーリングと使い分け
負荷に応じて Pod 数を増減するには Horizontal Pod Autoscaler（HPA） を使い、CPU 使用率やカスタムメトリクスでスケールします。Cloud Run と GKE の使い分けは、「最小運用でサーバーレスに動かす＝Cloud Run」「細かな制御・複雑なオーケストレーション・既存 Kubernetes 資産＝GKE」が目安です。「負荷でPodを増減＝HPA」「最小運用なら Cloud Run、細かな制御なら GKE」を押さえます。
「要件 → 手段」が頻出。例：「不調の Pod を自動再起動」＝liveness プローブ、「準備完了までトラフィックを送らない」＝readiness プローブ、「負荷に応じて Pod を増減」＝Horizontal Pod Autoscaler、「最小運用でサーバーレス」＝Cloud Run、「細かな制御/複雑なオーケストレーション」＝GKE。
混同に注意：
①liveness（再起動）と readiness（トラフィック可否）を取り違えない。
②HPA は Pod 数のスケールで、ノード数のスケール（Cluster Autoscaler）とは別。
③Cloud Run と GKE は運用負担と制御で選ぶ。
4.2.3この節のまとめ
- GKE は Deployment で配置・Service で公開、ヘルスチェック（liveness/readiness）で可用性
- Horizontal Pod Autoscaler で負荷に応じ Pod 数をスケール
- 最小運用＝Cloud Run、細かな制御/複雑なオーケストレーション＝GKE
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 不調になった Pod を自動的に再起動したい。設定するのはどれですか？
Q2. 起動途中の Pod にトラフィックを送らず、準備できてから送りたい。設定するのはどれですか？
Q3. 負荷に応じて Pod の数を自動で増減したい。使うのはどれですか？
Q4. 最小限の運用でコンテナをサーバーレスに動かしたい。最適なのはどれですか？
Q5. 細かな制御や複雑なオーケストレーション、既存 Kubernetes 資産がある場合に適すのはどれですか？
Q6. liveness プローブと readiness プローブの違いとして正しいものはどれですか？