こんにちは。ようこそ、クラウドネイティブの深淵へ。
普段、Kubernetes（k8s）を運用していて、「リクエストが来ていない間もPodが動き続けて、リソースを食いつぶしているのがもったいない」と感じたことはありませんか？
標準のk8sでは、HPA（Horizontal Pod Autoscaler）を使って負荷に応じたスケーリングは可能ですが、「0から1へ」のスケーリング、つまりScale-to-Zero（リクエストがない時にPodを完全に消す）をスマートに実現するのは、実は容易ではありません。
そこで登場するのがKnative（ケイネイティブ）です。
今日は、k8sという強力なエンジンに「サーバレス」という翼を授けるKnative Servingの世界を、現場で即戦力となる知見と共に紐解いていきましょう。
—
1. Knative Servingとは何か？ 標準k8sとの決定的な違い
まず、私たちが普段触っているk8sの「Deployment」や「Service」は、あくまで「常駐型」のワークロードを管理するためのものです。
対してKnative Servingは、「リクエスト駆動（Request-driven）」の思想で設計されています。
| 機能 | Kubernetes標準 (Deployment + HPA) | Knative Serving |
| :— | :— | :— |
| 最小Pod数 | 通常は1以上（0にするには手動操作が必要） | 0まで削減可能（Scale-to-Zero） |
| スケーリング指標 | CPUやメモリ使用率（メトリクスベース） | 同時リクエスト数（コンカレンシーベース） |
| ルーティング | Service/Ingressによる静的配分 | トラフィック分割（カナリアリリース）が容易 |
| 抽象化 | 低レイヤー（Pod, SVC, Ingressの個別管理） | 高レイヤー（Service一つで全てを内包） |
Knativeを導入すると、開発者は「コンテナポートは何番で、CPUはどれくらいで…」といった細かいインフラの繋ぎ込みから解放され、「リクエストが来たら、このコードを動かしてくれ」という本質的な要求に集中できるようになります。
—
2. 【実践】Knative環境の構築とScale-to-Zeroの体験
では、実際に手を動かしてみましょう。
ここでは、すでにKubernetesクラスタがあり、`kubectl`が使える状態を想定します。（※KnativeのインストールにはIstioやContourなどのネットワーク層が必要ですが、今回はエッセンスを伝えるために簡略化して進めます）
Knative Serviceの定義（これが基本のキです）
標準のk8s YAMLとは異なり、`serving.knative.dev/v1` というAPIを使います。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: hello-serverless
namespace: default
spec:
template:
metadata:
annotations:
# ここが肝！最小Pod数を0に設定（デフォルトで0になりますが明示が美しい）
autoscaling.knative.dev/minScale: “0”
# 1つのPodが同時に処理するリクエストの上限。これをトリガーにスケールします
autoscaling.knative.dev/target: “10”
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
value: “Knative Enthusiast”
このYAMLを `kubectl apply -f service.yaml` で投入するだけで、Knativeは裏側で k8sのDeployment、Service、Ingress（Route）、Configuration を自動生成します。
動作確認：静寂と覚醒
1. 静寂のフェーズ:
デプロイ直後、しばらくアクセスがないと `kubectl get pod` を打っても何も表示されません。Podは「0」の状態です。
2. 覚醒のフェーズ:
Knativeが発行したURLに対して `curl` を投げた瞬間、Knativeのコンポーネントである「Activator」がリクエストを一時的にバッファし、猛スピードでPodを起動させます。
3. 再び静寂へ:
リクエストが止まり、一定時間（デフォルト60秒）が経過すると、Podは自動的にターミネートされます。
これが、クラウド破産を防ぎ、リソース効率を極限まで高める「Scale-to-Zero」の魔力です。
—
3. 現場で震えるほど役立つ、コールドスタート対策とチューニング
「Scale-to-Zeroは素晴らしい。でも、最初の1リクエスト目が遅くなる（コールドスタート）のは困るんだ」
実務では必ずこの壁にぶつかります。ここからが、プロのSREとしての腕の見せ所です。
戦略①：`minScale` の使い分け
全てのサービスを0にする必要はありません。
- 管理画面やバッチAPI: `minScale: 0` でコスト優先。
- ユーザーが直接触るフロントエンドAPI: `minScale: 1` に設定し、常に1つはホットスタンバイさせておく。
戦略②：Activatorの理解
Knativeには Activator というコンポーネントがあります。Podが0の時にリクエストを受け取り、Podが立ち上がるまでリクエストを「待機」させてくれる守護神です。
このActivatorがPodへのパスを繋ぐ際のオーバーヘッドを減らすため、ネットワークプラグイン（KourierやIstio）の設定を最適化することが、レイテンシ改善の鍵となります。
戦略③：コンカレンシー（同時実行数）の最適化
k8s標準のHPAはCPU負荷でスケールしますが、Knativeは「1つのPodが今、何リクエスト捌いているか」でスケールを判断します。
autoscaling.knative.dev/target: “1”
あえて `target: 1` に設定すると、1リクエストごとに新しいPodが爆速で立ち上がる「超並列モード」になります。逆に、GoやNode.jsのように非同期処理が得意な言語なら、`100` 程度に設定して1つのPodを使い倒すのが正解です。
—
4. 最後に：なぜ今、Knativeなのか
インフラエンジニアの仕事は、サーバーを立てることではありません。「開発者が書いたコードを、最も効率よく、安全に価値へと変換する仕組み」を作ることです。
Knativeを導入することは、単なるコスト削減以上の意味を持ちます。
- 冪等性の担保: Podはいつでも消えていい（Stateless）という前提が強制されるため、自然とクリーンな設計になります。
- デプロイの心理的障壁の低下: トラフィックの0%から100%への切り替えが容易なため、カナリアリリースが当たり前の文化になります。
最初は少し難しく感じるかもしれませんが、まずは「リクエストが来たらPodが湧いてくる」あの感動を、ご自身のクラスタで味わってみてください。その瞬間、あなたのKubernetesに対する理解は、もう一段上のステージへ引き上げられているはずです。
もし構築で詰まったら、いつでも聞いてくださいね。私たちは、複雑なものをシンプルにするためにここにいるのですから。
それでは、ハッピー・スケーリング！