Slide 1
Slide 1 text
Zero Scale Abstraction
in Knative Serving
2019-10-22
ServerlessDays Tokyo 2019
Tsubasa Nagasawa
1
Slide 2
Slide 2 text
2
● 長澤 翼 (Tsubasa Nagasawa)
● インフラエンジニア
● 富士通株式会社 (2016.04-2018.10)
● CyberAgent (2018.11-)
○ メディア事業部, Service Reliability Group
○ ポイントシステムや認証基盤のインフラ担当
● その他
○ Kubernetes/Knative を触り始めて半年
○ Knative へのコントリビュート始めました
About me
toVersus
Slide 3
Slide 3 text
● Knative プロジェクトとは (3分)
● Knative Serving
○ 紹介と簡単なデモ (7分)
○ ゼロスケールの仕組み (7分)
○ 優れた点 (5分)
○ 制約と課題 (5分)
● Knative Serving の本番導入に向けて
○ アーキテクチャの紹介 (5分)
○ 直面した問題と解決策 (5分)
3
Slide 4
Slide 4 text
Knative
Kubernetes native platform
for serverless workload
[kay-native]
● Build: Source to Container
● Serving: Request-driven, scale-to-zero,
container-based compute.
● Eventing: Attach work to event sources.
4
Slide 5
Slide 5 text
K8S
GKE
EKS
Rancher Knative
'Kubernetes is becoming the Linux of the cloud'
- Jim Zemlin, Linux Foundation
CaaS PaaS FaaS
Eirini
+ Runtime
Cloud Run
OpenShift
Knative Serving API に準拠
※ This is just my personal insight.
5
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
Knative — Kubernetes-native PaaS
with Serverless
https://itnext.io/knative-kubernetes-native-paas-with-serverless-a1e0a0612943
> The PaaS handles source-to-deployment workflow,
building the user’s container image, rolling out a new
deployment, and configuring a new route and DNS
subdomain to allow traffic to reach the deployed containers.
7
Slide 8
Slide 8 text
Knative serverless Kubernetes
bypasses FaaS to revive PaaS
https://searchitoperations.techtarget.com/news/252469607/Knative-serverless-Kuber
netes-bypasses-FaaS-to-revive-PaaS
> Unlike the earlier generation of VM-based, fully managed
PaaS offerings, Knative and Kubernetes allow enterprise
DevOps and SRE teams to retain control over the
Kubernetes infrastructure behind the scenes.
8
Slide 9
Slide 9 text
What Exactly Is Knative?
https://medium.com/datadriveninvestor/what-exactly-is-knative-252ec94e4de7
> PaaS providers such as CloudFoundry and OpenShift are
also actively making contributions to the Knative
community.
9
Slide 10
Slide 10 text
Knative
Raises the level of abstraction
to running and connecting stateless
applications on Kubernetes
in practical ways
10
Slide 11
Slide 11 text
Knative Launch Partners
11
Slide 12
Slide 12 text
Knative Community Enabled
Build Serving
Kubernetes
Platform
Products
Primitives Events ...
Google Cloud Run SAP Kyma
Pivotal Function
Service
IBM Cloud Functions Red Hat
Openshift Cloud Functions
Pivotal riff
TriggerMesh T-mobile Jazz Rancher Rio
12
Slide 13
Slide 13 text
Knative Serving
Stateless, HTTP request-driven,
container autoscaling platform
on top of Kubernetes
13
Slide 14
Slide 14 text
● コンテナオーケストレーションプラットフォーム
○ サービスディスカバリと負荷分散
○ ストレージ管理
○ アプリのローリングアップデート/切り戻しの単純化
○ リソースに基づいたアプリ配置の最適化
○ 自動回復
○ 秘匿情報と設定の管理
● Kubernetes Components
○ kube-proxy
■ サービスディスカバリのデータプレーン
■ ワーカーノード毎
■ iptables で Netfilter のルールを操作
■ VIP とバックエンドの紐付け
Brief Review - Kubernetes
14
master
worker
Slide 15
Slide 15 text
Pod
● アプリをホストする 最小
単位のリソース
● 単一もしくは複数の コン
テナで構成
● ひとつの IP アドレスと
ポート空間を共有
● 短寿命
Deployment
● 複数の Pod のセット
● Pod の作成・更新などラ
イフサイクル管理
● セルフヒーリング
● 開発者が触るリソース
● 永続的
Service
● アプリにアクセスする方
法を抽象化
● Service Discovery
● 内部 VIP の提供
● L4 負荷分散
● 開発者が触るリソース
● 永続的
15
Brief Review - Kubernetes Primitives
Slide 16
Slide 16 text
apiVersion: apps/v1
kind: Deployment
metadata:
name: grpc-k8s
spec:
selector:
matchLabels:
app: grpc-k8s
template:
metadata:
labels:
app: grpc-k8s
spec:
containers:
- name: user-container
image: toversus/grpc-ping-go
ports:
- name: h2c
containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
periodSeconds: 1
apiVersion: v1
kind: Service
metadata:
name: grpc-k8s
spec:
ports:
- name: http2
port: 80
targetPort: h2c
selector:
app: grpc-k8s
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: grpc-istio
spec:
gateways:
- knative-ingress-gateway.knative-serving.svc.cluster.local
hosts:
- k8s.mattmoor.io
http:
- match:
- authority:
regex: ^k8s\.default\.io(?::\d{1,5})?$
route:
- destination:
host: grpc-k8s.default.svc.cluster.local
port:
number: 80
weight: 100
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: grpc-k8s
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: grpc-k8s
minReplicas: 1
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Kubernetes Deployment and others...
16
Slide 17
Slide 17 text
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: grpc-knative
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "10"
spec:
containers:
- image: toversus/grpc-ping-go
ports:
- name: h2c
containerPort: 8080
Knative Service
17
Slide 18
Slide 18 text
Demo #1
Hello, Knative!
18
Slide 19
Slide 19 text
19
Demo #1: Hello, Knative!
Slide 20
Slide 20 text
20
Demo #1: Hello, Knative!
Slide 21
Slide 21 text
21
Demo #1: Hello, Knative!
Slide 22
Slide 22 text
22
Demo #1: Hello, Knative!
Slide 23
Slide 23 text
23
Demo #1: Hello, Knative!
Slide 24
Slide 24 text
Knative Service
アプリの生成から削除までのライフサイクルを管理
Configuration
アプリの状態管理 (現状と望ましい状態)
Twelve-Factor App の思想
コードと設定を分離
Revision
コードと設定の不変のスナップショット
Route
トラフィックを Revision に紐付け
Knative Serving Primitives
24
Slide 25
Slide 25 text
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: grpc-knative
spec:
template:
metadata:
name: grpc-knative-v1
spec:
containers:
- image: toversus/grpc-ping-go
ports:
- name: h2c
containerPort: 8080
Revision
(grpc-knative-v1)
Configuration
(grpc-knative)
records
history of
Route
(grpc-knative)
Service
(grpc-knative)
traffic: 100%
Knative Service
25
Slide 26
Slide 26 text
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: grpc-knative
spec:
template:
metadata:
name: grpc-knative-v1
spec:
containers:
- image: toversus/grpc-ping-go
ports:
- name: h2c
containerPort: 8080
traffic:
- latestRevision: true
percent: 100
Knative Service
26
Configuration
(grpc-knative)
Route
(grpc-knative)
Service
(grpc-knative)
traffic: 100%
records
history of
Revision
(grpc-knative-v1)
Slide 27
Slide 27 text
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: grpc-knative
spec:
template:
metadata:
name: grpc-knative-v2
spec:
containers:
- image: toversus/grpc-ping-go
args: ["-value=KNATIVE"]
ports:
- name: h2c
containerPort: 8080
traffic:
- revisionName: grpc-knative-v1
percent: 100
tag: blue
- revisionName: grpc-knative-v2
percent: 0
tag: green
Knative Service (rolling update)
Configuration
(grpc-knative)
Route
(grpc-knative)
Service
(grpc-knative)
Revision
(grpc-knative-v1)
records
history of
Revision
(grpc-knative-v2)
traffic: 100%
27
Slide 28
Slide 28 text
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: grpc-knative
spec:
template:
metadata:
name: grpc-knative-v2
spec:
containers:
- image: toversus/grpc-ping-go
args: ["-value=KNATIVE"]
ports:
- name: h2c
containerPort: 8080
traffic:
- revisionName: grpc-knative-v1
percent: 0
tag: blue
- revisionName: grpc-knative-v2
percent: 100
tag: green
Knative Service (rolling update)
Configuration
(grpc-knative)
Route
(grpc-knative)
Service
(grpc-knative)
traffic: 100%
Revision
(grpc-knative-v1)
records
history of
Revision
(grpc-knative-v2)
28
Slide 29
Slide 29 text
Demo #2
Rolling Update
29
Slide 30
Slide 30 text
Demo #2: Rolling Update
30
Slide 31
Slide 31 text
Demo #2: Rolling Update
31
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: account
spec:
template:
metadata:
name: account-grpc-v0-1-0
labels:
serving.knative.dev/visibility: cluster-local
annotations:
autoscaling.knative.dev/target: "10"
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "3"
...
spec:
containers:
- image: toversus/rosetta-account:v0.1.0
ports:
- name: h2c
containerPort: 8070
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 128Mi
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: gateway
spec:
template:
metadata:
name: gateway-graphql-v0-1-0
annotations:
autoscaling.knative.dev/target: "10"
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "3"
...
spec:
containers:
- image: toversus/rosetta-gateway:v0.1.0
ports:
- name: h2c
containerPort: 8080
env:
- name: ACCOUNT_SERVICE_URL
value: account.default.svc.cluster.local:80
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 128Mi
Slide 32
Slide 32 text
Demo #2: Rolling Update
32
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: account
spec:
template:
metadata:
name: account-grpc-v0-2-0
labels:
serving.knative.dev/visibility: cluster-local
annotations:
autoscaling.knative.dev/target: "10"
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "3"
...
spec:
containers:
- image: toversus/rosetta-account:v0.2.0
ports:
- name: h2c
containerPort: 8070
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 128Mi
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: gateway
spec:
template:
metadata:
name: gateway-graphql-v0-2-0
annotations:
autoscaling.knative.dev/target: "10"
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "3"
...
spec:
containers:
- image: toversus/rosetta-gateway:v0.2.0
ports:
- name: h2c
containerPort: 8080
env:
- name: ACCOUNT_SERVICE_URL
value: account.default.svc.cluster.local:80
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 128Mi
Slide 33
Slide 33 text
Demo #2: Rolling Update
33
Slide 34
Slide 34 text
Inside Knative Serving
- Dominik Tornow, SAP & Andrew Chen, Google
https://www.youtube.com/watch?v=-tvQgLbcNtg
34
Slide 35
Slide 35 text
Inside Zero Scale Abstraction
35
Slide 36
Slide 36 text
To archive scaling to zero…
How can we retain synchronous user requests
until desired number of Pods are scaled out?
36
Slide 37
Slide 37 text
● Queuing/Buffering requests
● Fast scaling out
● Switching request path
● Observing request concurrency
● Making autoscale decision
The key elements are...
37
Slide 38
Slide 38 text
● Activator (a.k.a. KQueue)
○ Centralized request queue
○ Routing/Balancing requests
○ Expose metrics like request concurrency routed to Activator
● Autoscaler
○ Scraping metrics
○ Calculating and making autoscale decision
● queue-proxy
○ Distributed request queue
○ Reverse proxy
○ Expose metrics like request concurrency routed to queue-proxy
○ Deploy as sidecar container
The key components are...
38
Slide 39
Slide 39 text
A journey through initial scaling to zero
39
Slide 40
Slide 40 text
Initial state
● Activator と Autoscaler は
WebSocket で常時接続
● メトリクスを定期的に送信
40
Slide 41
Slide 41 text
Deploy Knative Service
● Revision Controller が KPA 作成
● KPA は、Revision のスケール方式、
スケール数、スケールを決定するメト
リクスのソースを管理
41
Slide 42
Slide 42 text
Serverless-style K8S Service
● リクエストパスの切り替えを 行う重
要なリソース
42
Slide 43
Slide 43 text
K8S Services
● Public K8S Service がリクエストパ
スのスイッチ役 (non-Endpoints)
● Revision K8S Service は、リクエス
トの転送先を監視するため
(ClusterIP or Endpoints)
43
Slide 44
Slide 44 text
Queuing requests
● Endpoints を手動コピーしてリクエ
ストパスを Activator に向ける
● Activator で一旦リクエストを
キューに溜められるように
44
Slide 45
Slide 45 text
Proving Endpoints
● Activator は、Pod がリクエストの処
理ができる状態か Revision Service
の Endpoints を監視
45
Slide 46
Slide 46 text
Healthy Endpoints
● Pod がリクエストを処理できる 状態
であることが判明
46
Slide 47
Slide 47 text
Switching Endpoints
● Revision Service の Endpoints オ
ブジェクトで、Public Service の
Endpoints を上書き
47
Slide 48
Slide 48 text
Monitoring metrics
● Autoscaler は、queue-proxy のメト
リクスを収集
● Activator のメトリクスと突き合わせ
てスケールが必要か判断
48
Slide 49
Slide 49 text
Scaling down to zero
● スケールダウンする前に Public
Service の Endpoints を
Autoscaler に向ける
● Deployment の replicas が 0 に
書き換えられる
49
Slide 50
Slide 50 text
Zero scaled
● Pod が削除され、ゼロスケール
● Revision K8S Service の
Endpoints も削除
50
Slide 51
Slide 51 text
A journey through scaling from zero
51
Slide 52
Slide 52 text
52
Incoming requests
● クラウドロードバランサが
リクエストを受ける
Slide 53
Slide 53 text
53
Forwarding requests
● クラウドロードバランサが
K8S のワーカーノードに
リクエスト振り分け
Slide 54
Slide 54 text
54
Pass-through requests
● K8S Service が nodePort で
受けたリクエストを
Front Envoy (L7 LB) に流す
Slide 55
Slide 55 text
55
Istio magic
● リクエストのホストヘッダーから転
送先の Public Service を識別
● Public Service にリクエスト転送
Slide 56
Slide 56 text
56
Activator queuing
● Public Service は、Activator にリ
クエストを転送
● Activator は、リクエストをキュー
に溜める
Slide 57
Slide 57 text
57
Making autoscale decision
● Autoscaler がメトリクスからスケー
ルが必要と検知
● KPA にスケールを指示
Slide 58
Slide 58 text
58
Scaling from zero
● KPA が Deployment の
レプリカ数を書き換え
● Pod 作成中
Slide 59
Slide 59 text
59
Proving endpoints
● Activator は、Pod がリクエストの処
理ができる状態か Revision Service
の Endpoints を監視
Slide 60
Slide 60 text
60
Transfering requests
● Activator は、ClusterIP もしくは
PodIP にリクエストを転送
Slide 61
Slide 61 text
61
Switching Endpoints
● Revision Service の Endpoints オ
ブジェクトで、Public Service の
Endpoints を上書き
Slide 62
Slide 62 text
62
Stable request path
● Activator を経由することなく
リクエストがバックエンドに
流れる
Slide 63
Slide 63 text
● スケール時
○ 最初の proxy が Activator -> queue-proxy
○ 2 回目の proxy が queue-proxy -> user-container
● 通常時
○ queue-proxy -> user-container への proxy のみ
63
Tracing results
スケール時
通常時
Slide 64
Slide 64 text
● Knative のオートスケールの仕組みを Kubernetes に取り込む
○ K8S Service/Ingress でゼロスケールをサポート
○ Ingress v2 へのフィードバックを積極的に行なっている
■ SIG-NETWORK: [PUBLIC] A sketch of the API
● Kubernetes HPA の現状
○ API レベルで `minReplicas: 0` をサポート (v1.16)
■ Support scaling HPA to/from zero pods for object/external metrics
○ リクエストバッファの仕組みは K8S の世界にない
○ 自作もしくは外部メトリクスをベースにゼロスケール
■ 外部キューの長さがゼロ、LB の rps がゼロ、...
64
Autoscaling ultimate goal
Slide 65
Slide 65 text
● kube-proxy を使ったゼロスケールの仕組み (Proposal)
○ ClusterIP へのリクエストは kube-proxy を経由する
○ ゼロスケール時は Pod 起動まで kube-proxy でキューに溜める
○ kube-proxy が Endpoints を監視して、バックエンドの正常性を判断
● Osiris (by Microsoft)
○ HTTP リクエストベースでゼロスケールする仕組みを提供
○ K8S Service の Endpoints を手動付け替え
■ Knative が参考にした仕組み
○ 2つの Service を使ってリクエストパスの切り替えを行う
■ Knative の Public Service の役目はなし
■ 直接 Revision Service を selector 有り無しで切り替える
65
Autoscaling ultimate goal
Slide 66
Slide 66 text
● 課金の開始いつから？
○ 初期デプロイ時の起動から停止の 90 秒間を課金に含めない
○ 初期デプロイ時に Pod をすぐに停止させる
○ 初期デプロイ時に Pod を起動させない
Off-topic: Don't scale to 1 upon deploy
90 sec
Initial
deploy
66
Slide 67
Slide 67 text
● 課金の開始いつから？
○ 初期デプロイ時の起動から停止の 90 秒間を課金に含めない
○ 初期デプロイ時に Pod をすぐに停止させる
○ 初期デプロイ時に Pod を起動させない
Off-topic: Don't scale to 1 upon deploy
90 sec
Initial
deploy
readinessProbe を明示的に指定していない場合は、
Pod を起動させない方向で調整中
67
Slide 68
Slide 68 text
Knative Serving Pros.
68
Slide 69
Slide 69 text
● HTTP リクエストベースでスケール可能
○ アプリが同時処理中のリクエスト数
○ アプリが 1 秒間に処理したリクエスト数
○ CPU の使用率 (HPA)
○ メモリの使用率 (HPA)
● スケールのポリシーをある程度カスタマイズ可能
○ アプリの並列処理数
○ 最大/最小スケール数
○ ゼロスケールまでの期間
○ Burst Capacity
Auto scaling with request metrics
69
Slide 70
Slide 70 text
● Kubernetes の世界
○ コンテナイメージのタグは mutable
○ Docker Registry v1 時代に GAE 上に GCR の前身を構築
■ google/docker-registry は (Python) ベース
■ google/docker-registry で文法エラーがあり、修正をロールアウト
■ DDoS 攻撃並みのアクセス発生、DockerHub で数時間の障害が
■ Kubernetes に imagePullPolicy が存在するキッカケなそうな
70
Free from `imagePullPolicy: Always`
Slide 71
Slide 71 text
● Kubernetes の世界
○ latest タグ以外はデフォで `imagePullPolicy: IfNotPresent`
○ Immutable なタグを Deployment に指定することを推奨
○ ...イメージ更新したが Deployment に変更が反映されない！
■ `imagePullPolicy: Always` に逆戻り...
This is not what I wanted...
71
Free from `imagePullPolicy: Always`
Slide 72
Slide 72 text
● Kubernetes の世界
○ 同じタグを更新していて、ノードがスケールアウトすると...
v1.0.0
v1.0.0’
72
Free from `imagePullPolicy: Always`
Slide 73
Slide 73 text
● Knative の世界
○ Revision コントローラがイメージタグを Digest に変換
○ Deployement の `image` にタグ解決で得られた Digest を指定
○ Revision は immutable
■ ノードがスケールしても事故は起きない
○ より実用的な方法でフェイルセーフを実現
○ Tag to digest の機能をオフにもできる
Free from `imagePullPolicy: Always`
73
Slide 74
Slide 74 text
Why we resolve tags in Knative
https://docs.google.com/presentation/d/1gjcVniYD95H1DmGM_n7dYJ69vD9d6Kg
JiA-D9dydWGU
10 Ways to Shoot Yourself in the Foot with Kubernetes,
#9 Will Surprise You
https://youtu.be/QKI-JRs2RIE?t=483
> Jobs are not starting, image pull fails
https://github.com/knative/serving/issues/4098#issuecomment-506194163
> Another syntax error, but this one actually managed to take down DockerHub
for a few hours. This outage was effectively the reason imagePullPolicy: exists
in Kubernetes, and has such a terrible default value (that makes me sad).
74
Google Slide を見るには knative-users@ に参加する必要があります。
Slide 75
Slide 75 text
● サービス停止を伴わないアプリのローリングアップデートの難しさ
Safe rolling update
K8S Service (L4) や Ingress (L7) の更新のレイテンシ
理想
1. 削除する Pod を決定
2. Service/Ingress の PodIP リスト更新
3. アプリに SIGTERM が飛ぶ
4. Graceful Shutdown が発動
現実
1. 削除する Pod を決定
2. Service/Ingress の PodIP リスト更新
(更新に時間がかかる)
3. アプリに SIGTERM が飛ぶ
4. Graceful Shutdown が発動
5. Pod にリクエストが流れてしまう
6. アプリ停止により 5xx を返す
75
Slide 76
Slide 76 text
Safe rolling update
● Knative Service のローリングアップデート
○ 新バージョンの Pod の起動
■ Activator のリクエストキュー
○ 旧バージョンの Pod はリクエストの処理が完了してから、
■ Replicaset Controller が削除する Pod をランダムに決定
■ Istio Proxy の設定の更新 (時間がかかる)
■ Pod に SIGTERM が飛ぶ
■ queue-proxy は、SIGTERM を受けると 20 秒間スリープ
■ リクエストパスが変わっているので、新しいリクエストなし
76
Slide 77
Slide 77 text
Reliability, reliability, reliability...
● Knative Serving のテストと信頼性
○ fake client を使ったユニットテスト
○ test-infra を使った E2E テスト
■ PR のコミット単位で都度 GKE に Knative をインストール
■ 作成したリソース状態や各コンポーネントのログを検索可能
○ Flaky (不安定) なテストの自動検出
○ Serving API に準拠しているかを確認するコンフォーマンステスト
○ パフォーマンステストと SLA の設定
■ google/mako で監視
○ pprof で各コンポーネントのプロファイリングを取得
■ ボトルネックを見つけて最適化予定
77
Slide 78
Slide 78 text
Reliability, reliability, reliability...
● パフォーマンステスト
○ 30分置きに vegeta で 0 -> 1k -> 2k -> 3k と負荷をかける
○ レイテンシやエラー率、理想/現実の Pod 数を計測
○ レイテンシの最大値 => ゼロスケールのレイテンシ
■ https://mako.dev/benchmark?benchmark_key=5352009922248704
&~l=max&tseconds=345600&tag=tbc%3D200
78
Slide 79
Slide 79 text
● マルチテナント対応
○ 1 つの Istio IngressGateway に複数のドメインを設定可能
○ Knative Serving で使用する Istio IngressGateway を指定可能
● Istio 依存からの脱却
○ Gloo, Ambassador に対応済み (SMI、Ingress v2 も視野に)
○ Cold Start (non Istio side-car) ~ 3 s
● Revision GC
○ リクエストパスに指定されていない Revision をお掃除
● 独自のオートスケーラーを実装可能
● メトリクス・ログ監視
○ クラスター内に Fluentd DS/Prometheus/Grafana/ES Stack を構築
○ GKE なら Stack Driver に流すことが可能
Others...
79
Slide 80
Slide 80 text
Knative Serving Cons.
80
Slide 81
Slide 81 text
● Pod に対してユーザーが定義できるコンテナは 1 つだけ
● Init/Sidecar コンテナ未サポート
○ CloudSQL Proxy、Dapr、ロギング・監視エージェント...
○ Validating Admission Webhook で作成時に弾かれる
● istio-proxy や queue-proxy はなぜ存在する？
○ Mutating Admission Webhook を使っている
● コンテナを複数梱包したいなら、Webhook 自作
81
Single container per Pod
Slide 82
Slide 82 text
● [Proposal] Support Multiple Containers
○ アプリのポートを上手くマッピングする必要あり
■ queue-proxy のリクエスト転送先のポートを知る必要あり
■ 現状、ポートを複数公開することもできない
■ 最終的に [KEP] Sidecar Containers に寄せていく
82
Single container per Pod
Slide 83
Slide 83 text
● Pod にアタッチできる Volume に制限あり
● 以下の Volume タイプのみサポート
○ ConfigMap
○ Secret
○ Projected Volume
● 読み取り専用の Persistent Volume もマウント不可
● 要望が多数あるため慎重に導入を検討中
○ Feature Request: Relax volume constraint to support more volume
types
83
Limits on Pod mounted Volume
Slide 84
Slide 84 text
● Pod を特定のノードに配備させるポリシーを設定できない
○ nodeSelector: 特定のラベルの付いたノードに配備
○ Node Affinity: 特定のラベルの付いたノードに配備
○ Tolerations: 特定のラベルの付いたノードに配備されないように
● ユースケース
○ Preemptive (Spot) Instance の利用
○ GPU マシンの使い分け
○ Windows Server の使い分け
○ Virtual Kubelete との併用
● アプリ開発者にノードの存在を意識させてしまう...
○ Serverless の理念にそぐわない
84
Limits on Node scheduling policy
Slide 85
Slide 85 text
● Knative Serving API v1 は MVP の実装
○ 多くの Pod Spec 配下のフィールドが指定できない状態
■ DownwardAPI
■ InitContainers
■ PriorityClassName
■ Priority
■ ReadinessGates
■ RuntimeClassName
■ Capabilities
■ Privileged
■ ...
85
And other masked fields...
Slide 86
Slide 86 text
● スケールダウン時に Deployment のレプリカ数を書き換えている
○ ReplicaSet コントローラがどの Pod を削除するか決定
○ Pod のステータスで優先順位はあるがランダム削除
○ Knative の問題というより Kubernetes の課題...
● Knative の Graceful Termination
○ 30 秒以上処理時間が掛かる場合に問題に...
■ バッチ処理、機械学習モデルの実行など
● [draft proposal] Graceful Scaledown
○ メトリクスを元に削除する Pod を決定
○ queue-proxy の readinessProbe を失敗させる
○ Deployment のレプリカ数を更新する
86
Pod phantom killer
Slide 87
Slide 87 text
● K8S Service のコスト
○ 1つの Revision に対して 3 つの K8S Service
○ K8S Service が増えると ClusterIP 経由での接続のレイテンシが悪化
● Non-Inteligent Autoscaling Algorithm
○ 一定の割合で増えるリクエスト数を検知して事前に Pod をスケールできず
● 非同期処理未対応
○ Knative Eventing と組み合わせるなど別の方法を検討する必要あり
● Stateful アプリケーション未対応
● Pod で公開できるポートが1つのみ
○ メトリクス公開用のポートはカスタムメトリクス用のポートを使う
● IAM Roles for Service Account が使えない
○ Revision 作成時に tag-to-digest の変換が入る
○ credential_helper.go で参照している AWS SDK のバージョン...
Others...
87
Slide 88
Slide 88 text
Road to Knative Serving v1
v0.9.0 (v1rc2)
2019/09/17 2019/10/29 2019/12/10
v0.10.0 (v1)
● Burst Capacity の導入
● Autoscale の安定性向上
● Zero Scale 時間の改善
● Validating Webhook
● Performance 計測/SLA 導入
●
v0.11.0 (v1)
88
Slide 89
Slide 89 text
Knative Feature Tracks
89
Slide 90
Slide 90 text
● Node local scheduling
○ 高負荷やゼロからスケールする時だけ自前スケジューリング
■ Pod のスケールは K8S のコントロールプレーンに完全に依存
■ Activator をノード毎に配置
■ Activator が kube-apiserver を経由して kubelet にスケールを指示
○ これでも大幅な改善が見られない場合は kubelet を最適化
● Request load balancing and routing
○ Activator をよりロードバランサーに仕立てる
Autoscaling
90
Slide 91
Slide 91 text
● Pipeline cold start
○ Knative Service 間のネストが深い場合のレスポンス時間の改善
■ KService A -> KService B -> KService C -> ...
○ トレース情報を使って事前に Pod を起動できないか
● Merge KPA to HPA
○ 必要であれば HPA に機能を移植
○ HPA でオートスケールの仕組みを組み立てる
○ 独自実装の KPA のメンテナンスコストを下げる
Autoscaling
91
Slide 92
Slide 92 text
● Revision へのルーティング方式の拡張
○ HTTP リクエストヘッダーによる Feature Flag ルーティングなど
● Zero to 1M QPS
○ ゼロから 1M QPS のリクエストを処理できるように
○ 必要な Istio/Knative のリソースを示す
● Acrtivator の置き換え
○ Activator を Envory に置き換える
■ リクエストバッファ、負荷分散以外にもメトリクスを送信
○ Mixer Adapter の実装
● queue-proxy の置き換え
○ queue-proxy を Envoy に置き換える
Networking
92
Slide 93
Slide 93 text
https://groups.google.com/forum/#!topic/knative-dev/YmL2vgMC4rc
> Since the start of the Knative project, there have been questions about
whether Knative would be donated to a foundation, such as CNCF.
Google leadership has considered this, and has decided not to donate
Knative to any foundation for the foreseeable future.
Off-topic: CNCF Donation
93
Slide 94
Slide 94 text
https://twitter.com/brendandburns/status/1179176440647913472
Off-topic: CNCF Donation
94
Slide 95
Slide 95 text
● CNCF 寄贈しない宣言契機に Steering Committee (SC) に対する不信感が...
○ SC の議論や決定のプロセスが外から見えない
○ SC の席の 4/6 が Google
○ SC のメンバーは組織の貢献度をもとにどう決定している？
● Steering Committee で議論中で近日中に発表があるとのこと
Off-topic: CNCF Donation
95
Slide 96
Slide 96 text
Knative Adoption
96
● Why Knative?
● High-level architecture walkthrough
● gRPC load balancing
● Strategy for upgrading EKS cluster
● Event driven system
● Resource requests and limits
Slide 97
Slide 97 text
● Kubernetes の抽象化
○ Kubernetes の難しさ/学習コストの高さ
○ ネットワークレイヤーも含めた K8S のほどよいオレオレ抽象化
○ 誰が苦労すべきか
● YAML 地獄からの脱却
○ Helm, kustomize とは違ったアプローチ
● ゼロスケール出来ることの意義
○ パフォーマンス ＜ 可用性
● Dual Stack
○ Knative と Kubernetes リソースの併用が可能
● Portability の向上
○ Kubernetes さえあればどこでもデプロイ可能で構築が容易
97
Why Knative?
Slide 98
Slide 98 text
98
Slide 99
Slide 99 text
● クラスターのアップグレードは
Blue/Green 方式
○ Global Accelerator でクラスターレベル
のリクエスト振り分け
○ 切り戻し優先のため、DNS レコード切
り替えは不採用
99
Slide 100
Slide 100 text
100
● Global Accelerator 利用のため、クラ
ウドロードバランサーとして Network
Load Balancer (NLB)
● NLB で TLS 終端
● mTLS は使わない
Slide 101
Slide 101 text
● Istio の Gateway リソースで HTTP ->
HTTPS へリダイレクトを設定
101
Slide 102
Slide 102 text
● gRPC LoadBalancing を Envoy Proxy
で行うため、Mesh の機能を止む無く
有効化 (後述)
● HTTP/1.1 かつランダム振り分けなら
Service Mesh 必須ではない
102
Slide 103
Slide 103 text
● 定期的に SQS をポーリングして、アプ
リの HTTP エンドポイントを叩く
● Knative Eventing を使いたかった部分
(後述)
103
Slide 104
Slide 104 text
104
● イベント駆動で処理を実行する部分だ
けゼロスケール利用
● 制約上、常に同時処理数を1つに固定
したい (後述)
Slide 105
Slide 105 text
105
● それ以外はゼロスケール利用しない
○ あくまで可用性向上の仕組み
○ ゼロスケールのレイテンシが 1
秒未満になれば使うかも...？
Slide 106
Slide 106 text
● メトリクス/ログ収集は DaemonSet を
利用
○ Sidecar パターンが使えない
○ リソース共有の問題もあるし、最
近余り見ないかも...？
106
Slide 107
Slide 107 text
● gRPC (HTTP/2) はコネクションを使い回す
○ K8S Service (HTTP/1.1) だとバックエンドへの接続が偏る
● gRPC のロードバランスの手法
○ クライアントサイド
■ Headless サービスを自前管理する必要あり
○ サイドカーパターン
■ Istio の場合、Automatic Sidecar Injection の機能が必要
● Istio はそこまで Plugable ではない印象
● Service Mesh を飼うコスト
■ Istio 以外の軽量な Service Mesh を使う (Gloo, Ambassador)
● 成熟度に課題
● Knative の E2E/パフォーマンステストが充実していない
107
gRPC load balancing
Slide 108
Slide 108 text
● gRPC (HTTP/2) はコネクションを使い回す
○ K8S Service (HTTP/1.1) だとバックエンドへの接続が偏る
● gRPC のロードバランスの手法
○ クライアントサイド
■ Headless サービスを自前管理する必要あり
○ サイドカーパターン
■ Istio の場合、Automatic Sidecar Injection の機能が必要
● Istio はそこまで Plugable ではない
● Service Mesh を飼うコスト
■ Istio 以外の軽量な Service Mesh を使う (Gloo, Ambassador)
● 成熟度に課題
● Knative の E2E/パフォーマンステストが充実していない
108
Istio with Service Mesh の採用を
強いられている...！
gRPC load balancing
Slide 109
Slide 109 text
● Activator で gRPC ロードバランシングすれば Mesh 不要では!?
○ L7 Load Balancer の役目も果たす (Throttler)
○ HTTP/2 without TLS もサポート
○ Activator を常にリクエストパスに置くことが可能 (target-burst-capacity: “-1”)
○ PodIP と ClusterIP で先に有効になった方にリクエストを投げる
○ v0.9.0 では PodIP と ClusterIP だと ClusterIP が優先
● Better Load Balancing in Activator
○ Prefer Pod IPs to ClusterIPs when possible #5820
■ 有効な PodIP に優先でリクエストを送る
109
gRPC load balancing
Slide 110
Slide 110 text
● Istio の問題点
○ アップグレードが鬼門
■ https://istio.io/docs/setup/upgrade/steps/
> The upgrade process may install new binaries and may change
configuration and API schemas. The upgrade process may result
in service downtime. To minimize downtime, please ensure your
Istio control plane components and your applications are highly
available with multiple replicas.
○ LTS の周期が速い
■ https://istio.io/about/release-cadence/
Support is provided until 3 months after the next LTS
110
Strategy for upgrading EKS cluster
Slide 111
Slide 111 text
● Knative の問題点
○ アップグレードへの気遣い
■ https://docs.google.com/document/d/1GXDe6163lO8ohtLUMPCplbjm3
OTpYo_4U8f9K1fgZPo
■ どのバージョンからどのバージョンに上げられるか明記
■ Knative アップグレードの E2E テストも追加される予定
○ ダウングレードは前バージョンまで
○ 複数の API バージョンに対応
■ https://docs.google.com/presentation/d/1mOhnhy8kA4-K9Necct-NeIwy
sxze_FUule-8u5ZHmwA
111
Strategy for upgrading EKS cluster
Slide 112
Slide 112 text
● クラスターを Blue/Green でアップグレード
○ 本番稼働中のクラスターで Istio/Knative をアップグレードしたくない
○ Global Accelerator で EKS クラスターレベルの一時的なルーティング
■ クラスターの内外を繋げる NLB に振り分ける
● 既存クラスターの Knative Service の移行
○ Revision は immutable で、直接作成できない
■ Configuration リソース経由
○ Revision の履歴は Configuration で管理していない
○ リクエストが向いていない Revision も含めて移行したい
112
$ kn service migrate --source-context xxx:xxxxxxx
Strategy for upgrading EKS cluster
Slide 113
Slide 113 text
● SQS キューのメッセージ駆動で特定の処理 (Function) を走らせたい
○ Lambda
○ ECS on EC2/Fargate
○ Knative Eventing
○ K8S Deployment + custom scheduler
● 懸念事項
○ API サーバーなど他アプリとデプロイ方法を分けたくない
■ デプロイフローの整備/メンテナンスコスト
■ サービス利用の学習曲線
○ Function の依存関係によるベースイメージのカスタマイズ性
○ Knative Eventing の成熟度
■ 本番利用可能とはまだまだ言えない...
113
Event driven system
Slide 114
Slide 114 text
● SQS キューのメッセージ駆動で特定の処理 (Function) を走らせたい
○ Lambda
○ ECS on EC2/Fargate
○ Knative Eventing
○ K8S Deployment + custom scheduler
● 懸念事項
○ API サーバーなど他アプリとデプロイ方法を分けたくない
■ デプロイフローの整備/メンテナンスコスト
■ サービス利用の学習曲線
○ Function の依存関係によるベースイメージのカスタマイズ性
○ Knative Eventing の成熟度
■ 本番利用可能とはまだまだ言えない...
114
Event driven system
K8S Deployment + 自前スケジューラ
最終的には Knative Eventing を使いたい...
Slide 115
Slide 115 text
● SQS イベントのサブスクライバー(処理部分) の制約
○ サブスクライバーは並列処理を許さない
■ `containerConcurrency: 1` と `maxScale: 1` を指定
● それ以上のリクエストが届いた場合にどうなる？
○ 超過分のリクエストは、queue-proxy のキューに溜まって処理待ち
○ 処理が終わると SQS のキューからメッセージを削除
○ 前の処理が終わると、queue-proxy がサブスクライバーにリクエスト転送
○ サブスクライバーの処理が詰まった時は、スケジューラがタイムアウト
○ キューの処理順は問題でない
○ スケジューラが SQS からキューを拾って再送を繰り返す
115
Event driven system
Slide 116
Slide 116 text
● [WIP]: Istio/Knative の resources.requests の合計
○ Istio IngressGateway で ~ 1k rps を想定
■ min: 7.65 vCPU
■ min: 10.2 Gi
● [WIP]: ワーカーノードのサイズと台数
○ c5.2xlarge (8vCPU, 16GB RAM) x 3 台 (> 1178.83 $)
○ Cluster Autoscaler で最大 10 台までスケール
■ Knative コンポーネントがいるノードはスケールダウンしない
116
Resource requests and limits
Slide 117
Slide 117 text
117
Container min. max.
requests limits
cpu memory cpu memory
Activator 1 20 300m 60Mi 1000m 600Mi
Autoscaler 1 1 30m 40Mi 300m 400Mi
Knative Webhook 1 1 20m 20Mi 200m 200Mi
Knative Controller 1 1 100m 100Mi 1000m 1000Mi
Networking Istio 1 1 100m 100Mi 1000m 1000Mi
ClusterLocalGW 2 4 3000m 2048Mi 3000m 2048Mi
IngressGateway 2 4 3000m 2048Mi 3000m 2048Mi
Pilot 2 5 100m 128Mi 2000m 1024Mi
Telemetry 1 5 1000m 1024Mi 4800m 4096Mi
Policy 1 5 100m 128Mi 2000m 1024Mi
queue-proxy ? ? 25m - - -
istio-proxy ? ? 100m 128Mi 2000m 1024Mi
user-container ? ? ? ? ? ?
Default setting
Slide 118
Slide 118 text
118
Container min. max.
requests limits
cpu memory cpu memory
Activator 1 5 300m 600Mi - 600Mi
Autoscaler 1 1 30m 40Mi - 400Mi
Knative Webhook 1 1 20m 20Mi - 200Mi
Knative Controller 1 1 100m 100Mi - 1000Mi
Networking Istio 1 1 100m 100Mi - 1000Mi
ClusterLocalGW 2 4 1000m 1024Mi - 1024Mi
IngressGateway 2 4 1000m 1024Mi - 1024Mi
Pilot 2 5 1000m 2048Mi - 2048Mi
Telemetry 1 5 1000m 1024Mi - 1024Mi
Policy 1 5 100m 128Mi - 1024Mi
queue-proxy ? ? ? ? - ?
istio-proxy ? ? 100m 128Mi - 512m
user-container ? ? ? ? ? ?
Our planning setting for future load test
Slide 119
Slide 119 text
https://twitter.com/mattklein123/status/1179455833265987584
119
Off-topic: Envoy as first-class citizens
Slide 120
Slide 120 text
● Serving Operator
○ Knative Serving のインストールからアップデートまでを管理
● Client (kn)
○ Knative/Tekton リソースを操作するための CLI ツールかつライブラリ
● Observaility
○ Telegraf/Fluent Bit ベースでメトリクスやログを外部のサービスに転送
● ko
○ import パス指定で Go アプリをビルド (like Jib in Java) & デプロイ
● kf
○ Knative 上で実現する CF (Cloud Foundry)
Off-topic: Knative Sub Projects
120
Slide 121
Slide 121 text
● Knative Pod Autoscaler (KPA) のシミュレータ
● スケーラのコード変更後にシミュレータで振る舞いを確認できる
● HPA でも使えるかも!? CNCF への寄贈含め議論中
Off-topic: Skenario
121
Slide 122
Slide 122 text
● Knative Serving API Specification
● Knative Runtime Contract
● [Tech Talk] Knative Serving API 101
● [TechTalk] Knative Autoscaling
● [Blog] Knative v0.3 Autoscaling — A Love Story
● [Video] Knative: Scaling From 0 to Infinity
● 2019 Autoscaling Roadmap
● Knativeで実現するKubernetes上のサーバーレスアーキテクチャ
● Knative serverless Kubernetes bypasses FaaS to revive PaaS
● Serverless On Your Own Terms Using Knative
Knative References
122
Slide 123
Slide 123 text
Simple
1-click build and deploy,
configurable when you need to
Source to container or URL safely
within your cluster
Extendable
Easy to configure event sources
Plugable event bus and persistence
Automatic
Automatically deploys containers and
provision ingress
Scale based on requests
Scale down to zero
● Set of primitives (build, events, serving...)
● Solves for modern development patterns
● Implements learnings from Google, partners
github.com/knative
Join Knative community
knative/docs/community
Have questions?
Knative.slack.com
Knative News?
@KnativeProject
Ingredients for Serverless