はじめに
こんにちは。
クラウドネイティブ／Kubernetes を中心に、Knative・Eventing・運用自動化などを触っているエンジニアです。
執筆した記事
- Kubernetes × GPU Operator × Knativeで実現するGPUaaS 〜AIエージェント時代にGPUを「占有しない」インフラ設計〜
- 【AWS未経験】1年でCFP → SAA → SAPに合格した勉強法
- 【G検定】未経験から1か月で合格した勉強法 〜AI基盤開発業務の背景と「広く浅く」の戦略〜
- 【入社3年目・初登壇】CloudNative Daysで「Edge-as-a-Service」を発表して見えた、エッジ×クラウドネイティブのリアル
- 🚀 Kubernetes上でVMを動かしてみた
この記事で分かること
- Kubernetes上で FaaS（関数）っぽい体験を作る方法
- Knative Functions で “常駐Podを立てない通知処理” を実装する手順
- なぜこのアプローチが Kubernetesの敷居を下げ、今後注目されそうか（理由つき）
結論（先にまとめ）
- Knative Functions は Kubernetes上で関数を書くためのシンプルなモデルを提供する（深いK8s知識を要求しない） :contentReference[oaicite:0]{index=0}
- HTTP / イベントで起動し、需要がない時は scale-to-zero で0台まで落ちる（=常駐不要） :contentReference[oaicite:1]{index=1}
-
func deployは OCIイメージを作ってレジストリへPushし、Knative Serviceとしてデプロイしてくれる :contentReference[oaicite:2]{index=2} - つまり「Kubernetesを、Python/Goから “Lambdaのように” 使う」入口として強い
なぜ今 Knative Functions なのか（メリットを重点的に）
ここが本題です。
1) ソフトウェアエンジニアの“Kubernetes学習コスト”を下げられる
Knative Functions は Knative / Kubernetes / コンテナ / Dockerfile の深い知識がなくても使える「シンプルなプログラミングモデル」を提供します :contentReference[oaicite:3]{index=3}
これが何を意味するかというと、
- Platform/SRE：基盤（Knative Servingなど）を整備する
- アプリ開発者：関数（=ビジネスロジック）に集中する
という分業がしやすくなります。
結果として「Kubernetes上で動くのに、開発体験がFaaS寄り」になり、Kubernetesの敷居が下がるのが大きいです。
2) “常駐Pod”を減らして、運用を軽くできる
通知・Webhook・小さな自動化のために、常駐Podを立て続けると、
監視・アップデート・リソース確保が積み上がります。
Knative Servingは、トラフィックが無い時に0台まで落とす scale-to-zero を提供します :contentReference[oaicite:4]{index=4}
→ 「使われない時は止まる」ので、運用負債を減らしやすいです。
3) ベンダーフリーで “Lambda的パターン” を持ち込める
Lambdaは便利ですが、設計や運用がAWS流になりやすいのも事実。
KnativeはKubernetes上なので、オンプレ / 複数クラウドでも成立しやすいのが強みです。
4) 今後注目されそうな理由（根拠つき）
- Knativeは 2025年10月8日にCNCF Graduated（成熟度の強いシグナル） :contentReference[oaicite:5]{index=5}
- CNCFの年次調査でも、クラウドネイティブ採用が成長し、回答者の一部では「開発/デプロイのほぼ全てがクラウドネイティブ」という状況が報告されています :contentReference[oaicite:6]{index=6}
「Kubernetesが共通基盤になっていくほど、その上での“開発者体験（FaaS）”の需要も上がる」
→ ここにKnativeが刺さる、という見立てです。
AWS Lambda と Knative Functions の違い（超ざっくり）
| 観点 | AWS Lambda | Knative Functions |
|---|---|---|
| 実行基盤 | AWS | Kubernetes |
| ベンダー | AWS依存 | ベンダーフリー |
| 実体 | マネージド実行環境 | コンテナ（Knative Service） :contentReference[oaicite:7]{index=7} |
| オンプレ | 不可 | 可能 |
| 体験 | 関数中心 | 関数中心（K8s隠蔽しやすい） :contentReference[oaicite:8]{index=8} |
今回作るもの（最小構成）
手順等は公式サイトを参照して作成しましたが、改訂等により一部修正が必要になっているところもあるかもしれないです
HTTPアクセス（curl / Webhook）
→ Knative Function（Go）
→ Gmail(SMTP) でメール通知
- アクセスが来たら起動
- 処理が終わればスケールダウン（設定により0台へ）
- 認証情報はKubernetes Secretで管理
使用環境
- OS: Ubuntu 22.04
- 環境: AWS VM / オンプレミス
- Kubernetes（Knative Serving 導入済）
- Docker Hub アカウント
- Gmail アカウント（アプリパスワード使用）
ステップ1: Gmail アプリパスワードの発行
- Google アカウントで 2段階認証を有効化
- アプリパスワード発行ページにアクセス
- 「メール」+ 任意のデバイス名で発行
- 16桁のパスワードを控える
ステップ2: 関数(handle.go)を実装
package function
import (
"fmt"
"io"
"net/http"
"net/smtp"
"os"
)
func Handle(w http.ResponseWriter, r *http.Request) {
body, _ := io.ReadAll(r.Body)
fmt.Println("📨 イベント受信:", string(body))
from := os.Getenv("MAIL_FROM")
pass := os.Getenv("MAIL_PASS")
to := os.Getenv("MAIL_TO")
msg := "From: " + from + "\n" +
"To: " + to + "\n" +
"Subject: 📨 Knative Functionから通知\n\n" +
"イベントが届きました: " + string(body)
err := smtp.SendMail(
"smtp.gmail.com:587",
smtp.PlainAuth("", from, pass, "smtp.gmail.com"),
from,
[]string{to},
[]byte(msg),
)
if err != nil {
fmt.Println("メール送信失敗:", err)
} else {
fmt.Println("✅ メール送信成功")
}
fmt.Fprintln(w, "📧 メール送信処理完了")
}
ステップ3: Gmail 認証情報を Secret 化
mail-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mail-secret
namespace: skupper
type: Opaque
stringData:
MAIL_FROM: "your@gmail.com"
MAIL_PASS: "your_app_password"
MAIL_TO: "recipient@example.com"
ステップ4: func.yaml に環境変数を設定
envVars:
- name: MAIL_FROM
valueFrom:
secretKeyRef:
name: mail-secret
key: MAIL_FROM
- name: MAIL_PASS
valueFrom:
secretKeyRef:
name: mail-secret
key: MAIL_PASS
- name: MAIL_TO
valueFrom:
secretKeyRef:
name: mail-secret
key: MAIL_TO
ステップ5: ビルド & デプロイ
func deploy --registry docker.io/あなたのユーザ名
デプロイ後、以下の URL が発行されます。
http://myfunc.<namespace>.<your-domain>.sslip.io
ステップ6: 動作確認
curl -X POST "http://myfunc.skupper.1.2.3.4.sslip.io" \
-H "Content-Type: application/json" \
-d '{"message":"手動メール送信"}'
### ログ確認：
kubectl logs -n skupper \
-l serving.knative.dev/service=myfunc \
-c user-container -f
まとめ（メリット）
Knative Functions を使うと、
- 関数として書く（=ビジネスロジックに集中）
- HTTP / イベントで起動
- 常駐Podを減らせる（scale-to-zero）
- しかも Kubernetes上（ベンダーフリー）
という 「Lambdaっぽい体験」 を作れます。
特に、通知・Webhook・運用自動化など “常駐させたくない小さな処理” に刺さります。
今後さらに注目されそうな理由（個人の見立て）
そして個人的には、Knativeは
- CNCF Graduated（2025/10/8）
- クラウドネイティブ採用が伸び続けている
という流れもあり、**「Kubernetesの敷居を下げるFaaSの入口」**として、今後さらに注目されるのでは？と考えています。