この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
スライドが投稿され次第､追加と内容の修正を行う予定です｡
セッション概要
- 登壇者: Tsubasa Nagasawa
- CyberAgent
- インフラエンジニア
内容
Knativeとは
一言でいうと､Kubernetes(以降､k8s)をそのまま使うのは難しいので､実用的な方法で抽象化を行ってくれものです｡
Knativeは､k8sの上でサーバーレスをワークロードを動かす為のプラットフォームで､役割としてはCloudFoundaryやHerokuと近いと考えています｡
これによって､アプリケーションコードを書くだけで､実行し外部からリクエストを受ける事ができます｡
もし､Knativeに向かないところはk8sワークロードとして実行する事が可能なので､柔軟に構える事ができます｡
Knative Serving
HTTPリクエスト駆動でスケーリングするプラットフォームです｡
k8sだと大量に必要なマニフェストが､Knativeなら比較して少ないマニフェストでサービスを立ち上げる事が可能になります｡Knativeが開発者の代わりにk8sのリソースを作成してくれる事によってこれは実現されています｡
バージョンに対してタグを付けることで､旧バージョンと新バージョンに対してリクエストを任意の割合で振り分けが可能になります｡ これによって､本番にリリースする前に､開発者だけが実際に動作を確認する事が可能です｡
Zero Scaleの仕組み
Zero Scaleするという事は､ユーザーからリクエストが来た際に､ワーカーが立ち上がるまでリクエストを保持する必要があります｡
また､アプリケーションがどれぐらいリクエストを処理できるかに応じて､スケーリングを行う必要があります｡
主要なコンポーネントとして以下があります｡
- Activator
- リクエストをキューに保存する
- Autoscaler
- ワーカーのメトリクスを取得する
- Podのスケールが必要か決定する
- queue-proxy
- アプリの隣にデプロイされる
- アプリにどれぐらいリクエストを送るか調整する
実際にZero Scaleする仕組みを説明します｡
後ほどスライドの図を追加します｡
Knativeの良い点
- AutoScaleの設定が細かくできる
- HTTPリクエストベースのスケールが可能
- スケールポリシーをある程度カスタマイズ可能
- imagePullPolicy: Alwaysが不要
- ローリングアップデートが安全
- k8sと比べて考慮点が少ない
- 上位のLBにワーカーが削除された事を伝えてるまでにラグがある
- Knativeならキューがリクエストを預かっているのでリクエストロストしない
Knativeの悪い所
- Podに同梱できるコンテナは1つだけ
- istio-proxyやqueue-proxyは特別な対応を行って対処している
- プロポーサルは既に上がっている
- ボリュームのマウントが制約がある
- 現時点ではプロポーサルは上がっていない
- 特定のノードでPodを立ち上げる事ができない
- アプリ開発者がノードを意識するのはサーバーレスの理念にそぐわない
- スケールダウン時にDeploymentのレプリカ数を書き換えている
- どのPodが削除されるかはランダム(処理中のPodが狙われる可能性がある)
- 削除までの猶予時間は設定できるのでそれで対応する
- メトリクスで判断するプロポーサルが出ている
Knativeを実際のプロダクトで採用する理由
下記の理由から､プロダクトで採用した｡
- アプリ開発者がいきなりk8sを触るのは敷居が高い
- 誰が苦労するかという話
- YAML地獄
- Knativeに代わりに書いてもらう事で負担軽減
- ゼロスケールできることの意義
- パフォーマンス < 可用性
- Dual Stack
- Knativeを使ってもk8sは併用できる
クラウドはAWSを利用し､EKSでクラスタを構築している｡ クラスタはBlueGrenn方式でクラスタアップデートを予定しており､以下を想定している｡
- Global Acclalatorで切り替え
- ELBが必須となる
- NLB採用予定
- knコマンドの利用
- クラスター間のサービスのマイグレーション
あとがき
k8sを簡単に扱えるKnativeってとても面白そうだなと感じました｡以前からちまちまとEKS ＆ ArgoCDでk8sを勉強しているので､合わせてKnativeも触ってみようと思いました｡
40
