knative

Knative スキル

概要

Knative は、サーバーレスワークロードをデプロイおよび管理するための、Kubernetes ベースのオープンソースプラットフォームです。主なコンポーネントは次の 3 つです。

コンポーネント	目的	主な機能
Serving	HTTP トリガーによる自動スケーリングランタイム	ゼロへのスケール、トラフィック分割、リビジョン
Eventing	イベント駆動型アーキテクチャ	ブローカー、トリガー、ソース、CloudEvents
Functions	関数のデプロイを簡素化	func CLI、複数言語のサポート

現在のバージョン：v1.20.0（2024 年後半時点）

このスキルを使用する場面

ユーザーが次のことを行う場合に、このスキルを使用します。

• Kubernetes 上にサーバーレスワークロードをデプロイしたい
• ゼロへのスケールによる自動スケーリング機能が必要
• イベント駆動型アーキテクチャを実装している
• トラフィック管理（ブルーグリーン、カナリア、段階的ロールアウト）が必要
• CloudEvents またはイベントルーティングを扱っている
• Knative Serving、Eventing、または Functions に言及している
• ブローカー、トリガー、ソース、またはシンクについて質問している
• ネットワークレイヤー（Kourier、Istio、Contour）の設定が必要

クイックリファレンス

Knative Service（Serving）

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        # Autoscaling configuration
        autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
        autoscaling.knative.dev/min-scale: "0"
        autoscaling.knative.dev/max-scale: "10"
        autoscaling.knative.dev/target: "100"  # concurrent requests
    spec:
      containers:
        - image: gcr.io/my-project/my-app:latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              memory: 128Mi  # Memory limit = request (required)
          # NO CPU limits (causes throttling)

トラフィック分割

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    # ... container spec
  traffic:
    # Blue-green: 100% to new or old
    - revisionName: my-service-00001
      percent: 90
    - revisionName: my-service-00002
      percent: 10
    # Or use latestRevision
    - latestRevision: true
      percent: 100

タグ付きリビジョン（プレビュー URL）

traffic:
  - revisionName: my-service-00002
    percent: 0
    tag: staging  # Accessible at staging-my-service.example.com
  - latestRevision: true
    percent: 100
    tag: production

ブローカーとトリガー（Eventing）

# Create a Broker
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: default
  namespace: default
---
# Create a Trigger to route events
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: my-trigger
  namespace: default
spec:
  broker: default
  filter:
    attributes:
      type: dev.knative.example
      source: /my/source
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: my-service

イベントソースの例（PingSource）

apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: cron-job
spec:
  schedule: "*/1 * * * *"  # Every minute
  contentType: application/json
  data: '{"message": "Hello from cron"}'
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display

インストール

前提条件

• Kubernetes クラスター v1.28+
• kubectl の設定
• クラスター管理者権限

方法 1：YAML インストール（GitOps に推奨）

# Install Knative Serving CRDs and Core
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.20.0/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/knative-v1.20.0/serving-core.yaml

# Install Networking Layer (choose one)
# Option A: Kourier (lightweight, recommended for most cases)
kubectl apply -f https://github.com/knative/net-kourier/releases/download/knative-v1.20.0/kourier.yaml
kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'

# Option B: Istio (for service mesh requirements)
kubectl apply -f https://github.com/knative/net-istio/releases/download/knative-v1.20.0/net-istio.yaml

# Install Knative Eventing
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.20.0/eventing-crds.yaml
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.20.0/eventing-core.yaml

# Install In-Memory Channel (dev only) or Kafka Channel (production)
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.20.0/in-memory-channel.yaml

# Install MT-Channel-Based Broker
kubectl apply -f https://github.com/knative/eventing/releases/download/knative-v1.20.0/mt-channel-broker.yaml

方法 2：Knative Operator

# Install the Operator
kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.20.0/operator.yaml

# Deploy Knative Serving
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress-class: kourier.ingress.networking.knative.dev

---
# Deploy Knative Eventing
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing

DNS の設定

# Get the External IP of the ingress
kubectl get svc kourier -n kourier-system

# Option A: Real DNS (production)
# Create A record: *.knative.example.com -> EXTERNAL-IP

# Option B: Magic DNS with sslip.io (development)
kubectl patch configmap/config-domain \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"<EXTERNAL-IP>.sslip.io":""}}'

# Option C: Default domain (internal only)
kubectl patch configmap/config-domain \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"example.com":""}}'

自動スケーリング

オートスケーラーのクラス

クラス	キー	ゼロへのスケール	メトリクス
KPA（デフォルト）	kpa.autoscaling.knative.dev	はい	同時実行数、RPS
HPA	hpa.autoscaling.knative.dev	いいえ	CPU、メモリ

自動スケーリングのアノテーション

metadata:
  annotations:
    # Autoscaler class
    autoscaling.knative.dev/class: kpa.autoscaling.knative.dev

    # Scale bounds
    autoscaling.knative.dev/min-scale: "1"    # Prevent scale-to-zero
    autoscaling.knative.dev/max-scale: "100"
    autoscaling.knative.dev/initial-scale: "3"

    # Scaling metric (KPA)
    autoscaling.knative.dev/metric: concurrency  # or rps
    autoscaling.knative.dev/target: "100"        # target per pod

    # Scale-down behavior
    autoscaling.knative.dev/scale-down-delay: "5m"
    autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m"

    # Window for averaging metrics
    autoscaling.knative.dev/window: "60s"

同時実行数の制限

spec:
  template:
    spec:
      containerConcurrency: 100  # Hard limit per pod (0 = unlimited)

ネットワーキング

ネットワークレイヤーの比較

レイヤー	メリット	デメリット	ユースケース
Kourier	軽量、高速、シンプル	機能が限定的	ほとんどのデプロイ
Istio	フル機能のサービスメッシュ、mTLS	重く、複雑	エンタープライズ、セキュリティが重要な環境
Contour	Envoy ベース、高いパフォーマンス	中程度の複雑さ	高トラフィックのアプリ

TLS の設定

# Using cert-manager (recommended)
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
  annotations:
    # Auto-TLS with cert-manager
    networking.knative.dev/certificate-class: cert-manager
spec:
  # ... template spec

カスタムドメインのマッピング

apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
  name: api.example.com
  namespace: default
spec:
  ref:
    kind: Service
    name: my-service
    apiVersion: serving.knative.dev/v1

Eventing のパターン

イベントソースの種類

ソース	説明	ユースケース
PingSource	Cron ベースのイベント	スケジュールされたタスク
ApiServerSource	K8s API イベント	クラスターの監視
KafkaSource	Kafka メッセージ	ストリーム処理
GitHubSource	GitHub Webhook	CI/CD のトリガー
ContainerSource	カスタムコンテナー	あらゆる外部システム

チャネルの種類

チャネル	永続化	ユースケース
InMemoryChannel	いいえ	開発のみ
KafkaChannel	はい	本番環境
NATSChannel	設定可能	高スループット

シーケンス（連鎖処理）

apiVersion: flows.knative.dev/v1
kind: Sequence
metadata:
  name: my-sequence
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
  steps:
    - ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: step-1
    - ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: step-2
  reply:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: final-handler

並列処理（ファンアウト）

apiVersion: flows.knative.dev/v1
kind: Parallel
metadata:
  name: my-parallel
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
  branches:
    - subscriber:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: handler-a
    - subscriber:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: handler-b

Knative Functions

CLI のインストール

# macOS
brew install knative/client/func

# Linux
curl -sL https://github.com/knative/func/releases/latest/download/func_linux_amd64 -o func
chmod +x func && sudo mv func /usr/local/bin/

関数のライフサイクル

# Create a new function
func create -l python my-function
cd my-function

# Build the function
func build

# Deploy to cluster
func deploy

# Invoke locally
func invoke

# Invoke remote
func invoke --target=remote

サポートされている言語

言語	テンプレート	ランタイム
Go	go	ネイティブバイナリ
Node.js	node	Node.js 18+
Python	python	Python 3.9+
Quarkus	quarkus	GraalVM/JVM
Rust	rust	ネイティブバイナリ
TypeScript	typescript	Node.js

関数の設定（func.yaml）

specVersion: 0.36.0
name: my-function
runtime: python
registry: docker.io/myuser
image: docker.io/myuser/my-function:latest
build:
  builder: pack
  buildpacks:
    - paketo-buildpacks/python
deploy:
  namespace: default
  annotations:
    autoscaling.knative.dev/min-scale: "1"
  env:
    - name: MY_VAR
      value: my-value
  volumes:
    - secret: my-secret
      path: /secrets

ベストプラクティス

リソースの設定

リソース	要件	備考
CPU リクエスト	必須	実際の使用量に基づいて設定
CPU 制限	禁止	スロットリングの原因になります
メモリリクエスト	必須	アプリの必要量に合わせる
メモリ制限	必須	リクエストと同じ値にする

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    memory: 128Mi  # Same as request
    # NO cpu limit!

プローブの設定

spec:
  containers:
    - image: my-app
      readinessProbe:
        httpGet:
          path: /health
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      # Liveness probe optional for serverless
      # (Knative handles pod lifecycle)

コールドスタートの最適化

1. 最小レプリカ数を維持する：レイテンシが重要なサービスでは、min-scale: "1" を設定します
2. コンテナイメージを最適化する：distroless/alpine ベースイメージを使用します
3. 遅延初期化：負荷の高い初期化は最初のリクエストまで延期します
4. コネクションプーリング：データベース接続を事前にウォームアップします

本番環境のチェックリスト

• InMemoryChannel の代わりに KafkaChannel を使用する
• 適切なリソースリクエスト／制限を設定する
• cert-manager で TLS を設定する
• カスタムドメインを設定する
• 適切な最小／最大スケール値を設定する
• Triggers のデッドレターシンクを有効にする
• モニタリング（Prometheus メトリクス）を設定する
• 適切な RBAC を設定する

トラブルシューティング

よくある問題

症状	原因	解決策
サービスにアクセスできない	DNS が設定されていない	ドメインマッピングを設定するか、sslip.io を使用します
Pod がスケールアップしない	Activator の過負荷	Activator のレプリカ数を増やします
コールドスタートが遅い	イメージが大きい、または初期化が遅い	イメージを最適化し、min-scale: "1" を使用します
イベントが配信されない	Broker の設定ミス	Broker／Trigger のステータスを確認します
503 エラー	サービスのスケーリング	Activator のログを確認し、スケールを増やします
証明書エラー	cert-manager の問題	ClusterIssuer と Certificate のステータスを確認します

診断コマンド

# Check Knative Serving status
kubectl get ksvc -A
kubectl describe ksvc <service-name>

# Check revisions
kubectl get revisions -A
kubectl describe revision <revision-name>

# Check routes
kubectl get routes -A

# Check Knative Eventing status
kubectl get brokers -A
kubectl get triggers -A
kubectl get sources -A

# Check event delivery
kubectl get subscriptions -A

# View activator logs
kubectl logs -n knative-serving -l app=activator -c activator

# View controller logs
kubectl logs -n knative-serving -l app=controller

# Check networking layer (Kourier)
kubectl logs -n kourier-system -l app=3scale-kourier-gateway

イベントフローのデバッグ

# Deploy event-display service for debugging
kubectl apply -f - <<EOF
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: event-display
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
EOF

# Create a trigger to route all events
kubectl apply -f - <<EOF
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: debug-trigger
spec:
  broker: default
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display
EOF

# Watch events
kubectl logs -l serving.knative.dev/service=event-display -c user-container -f

ArgoCD との統合

Knative サービス用の ApplicationSet

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: knative-services
spec:
  generators:
    - git:
        repoURL: https://github.com/org/repo.git
        revision: HEAD
        directories:
          - path: knative-services/*
  template:
    metadata:
      name: '{{path.basename}}'
      annotations:
        # Disable SSA if using Jobs
        argocd.argoproj.io/compare-options: ServerSideDiff=false
    spec:
      project: default
      source:
        repoURL: https://github.com/org/repo.git
        targetRevision: HEAD
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Knative リソースのヘルスチェック

ArgoCD は Knative リソースを自動的に認識します。カスタムヘルスチェック：

# In argocd-cm ConfigMap
data:
  resource.customizations.health.serving.knative.dev_Service: |
    hs = {}
    if obj.status ~= nil then
      if obj.status.conditions ~= nil then
        for _, condition in ipairs(obj.status.conditions) do
          if condition.type == "Ready" and condition.status == "True" then
            hs.status = "Healthy"
            hs.message = "Service is ready"
            return hs
          end
        end
      end
    end
    hs.status = "Progressing"
    hs.message = "Waiting for service to be ready"
    return hs

参考資料

• 公式ドキュメント
• Knative Serving API
• Knative Eventing API
• Knative Functions
• GitHub リポジトリ
• 詳細なリファレンス

---

注意点

• min-scale: "0" はコストを抑えられますが、最初のリクエストでコールドスタートが発生します — JVM／Python アプリでは、3～10 秒かかることもあります。パブリック URL にヘルスプローブを送ると意図せず Pod がウォーム状態に保たれます。これを削除すると、ユーザーが常に経験していたコールドスタートが表面化します。
• containerConcurrency: 0（無制限）では KPA オートスケーリングが機能しません。オートスケーラーがスケーリングの基準にする同時実行数の目標を持てないためです。必ず明示的な値を設定してください。デフォルトの 0 では適切なスケーリングが暗黙のうちに無効になります。
• Knative Service の spec.template.metadata.name は、一度設定すると変更できません — 変更しても新しいリビジョンは作成されず、適用に失敗します。名前は省略し、Knative に -00001、-00002 などを自動生成させてください。
• Knative Services をデプロイする ArgoCD アプリには、ServerSideDiff=false アノテーションが必要です。これは ArgoCD のスキーマが Knative のステータスフィールドを認識しないためです。これがないと、マニフェストが有効でも同期が field not declared in schema で失敗します。
• InMemoryChannel は Broker Pod の再起動時にイベントを失います — 開発環境なら問題ありませんが、本番環境では致命的です。Trigger が Ready=True を報告しているのにイベントが時々消える場合は、この問題が起きています。本番環境では必ず KafkaChannel または NATSChannel を使用してください。
• CPU 制限は、ゼロからのスケール時にリクエストのレイテンシ急増を引き起こします。Activator がスロットリングするためです。クラスターのポリシーに合わせ、リクエストのみを設定し、CPU 制限は設定しないでください。
• percent: 0 のタグ付きリビジョンでも、メインルートに 0% と表示されていても、<tag>-<service> サブドメインではトラフィックを受信します。タグの 0% が「トラフィックなし」を意味すると考えないでください。