はじめに
今年に入ってますます Kubernetes (k8s) が盛り上がりを見せています。つい先日も Apple がCNCF (Cloud Native Computing Foundation) への参加を発表する 等、エコシステムの進化が急速に進みそうなニュースも発表されました。今後、ますます k8s を使うユーザが増えていくと考えられます。
今回、2019年6月18日に開催された Kubernetes Meetup Tokyo #20 に blog 枠として参加させていただけましたので、イベントの内容についてレポートいたします。
- Kubernetes Meetup Tokyo #20 へのリンク
- 発表資料
KubeCon + CloudNativeCon Europe 2019
発表内容については全て KubeCon + CloudNativeCon Europe 2019 に関するものになります。1件のみ、もともと予定されていた "Production GPU Clusters With K8s for AI and DL workloads"については急遽キャンセルとなりました。
発表者 | タイトル |
---|---|
@hatotaka | KubeCon + CloudNativeCon Europe 2019 Overview |
@yoshikai_ | 5G Orchestration in Serverless & Managing Edge Computing with Serverles |
@jyoshise | Modern CI/CD with Tekton and Prow Automated via Jenkins X |
@inductor | Kubectl Apply 2019: Defense Against the Dark Arts |
@shmurata | Resize Your Pods w/o Disruptions... & Restart-Free Vertical Scaling... |
@IanMLewis | Container Runtime |
KubeCon + CloudNativeCon Europe 2019 Overview
今回のイベントで Keynote でも大きく取り扱われていた分野としては、OpenTelemetry と Service Mesh Interface (SMI) とのことでした。
- 開催場所: Fira Gran Via, Barcelona, Spain
- 参加人数 7,700 人
- Keynote
- OpenTelemetry, Service Mesh Interface (SMI)
- Project Updates
- Linkerd, Helm, Harbor, ROOK, cri-o等
- OpenTelemetry
- 次の major update から、OpenTelemetry に変わる予定
- SMI
- Interfaceの共通化が進む
- Ingress に近いAPI仕様になる模様
- index-free Logs
- Obervability
- 開発者でも、もっと簡単に log grep をしたい
- Obervability
- Grafana loki
- Prometheus に似たログアグリゲーションシステム
- 次回はアムステルダム
- All Attendee Party
- パエリアが振舞われたり、フラメンコが観られたり
5G Orchestration in Serverless & Managing Edge Computing with Serverles
主に、Edge 系のセッションについて紹介をいただけました。ただし、yoshikai_ さんが注目
されている分野は いわゆる Customer Edge なので、Telecom Carrier が想定している
基地局や集約拠点とはサイズ感が異なっていた、とのことでした。
個人的には、k3s を Raspberry Pi に入れてアプリをガンガンと動かしている点がとても
面白かったです。丁度 ROCK64 (Raspberry Pi に似た メモリ容量の大きいボード) に
ROOK を入れて色々遊んでみようと準備していたところなので、k3s だけを深掘りするような
発表が今後あると嬉しいです。
- 5G Orchestration in Serverless (AT&T)
- Container より Serverless をなるべく使いましょう
- Cloud に集約することで発生する課題を解決したい
- Akraino Edge Stack
- Edge のえー感じなやつ!?
- VM よりは軽いが、課題もある
- MQTT を用いたメッセージングにより、リソース消費を抑えている
- Serverless で処理される
- 全てのコンポーネントは k8s 上で稼働する
- ONAP
- とても広範囲にわたる仕様
- Managing Edge Computing with Serverless
- 活用事例の紹介だった
- Inteligent Edge の必要性
- 元々、提唱したのは Microsoft
- 賢いEdge, Serverless
- 必要なデータのみを Cloud にアップロードする
- Nuclio
- non-blocking parallel で高い処理性能が出せる
- AWS Lambda よりも 100倍 速い、とのベンダ見解
- Success Stories
- マッチング系のクーポンシステム
- 弊社事例
- 工場に設置したデバイス(Raspberry Pi 3; k3s)から CloudFunctionにデータをアップロード
- Pub/Sub インタフェース, MQTT にて通信
Modern CI/CD with Tekton and Prow Automated via Jenkins X
アプリ及びインフラ、それぞれの各レイヤーで GitOps を考えないといけない、という考えを披露されていました。オンプレで Kubernetes を運用する人にとっては、とても重要なテーマに今後なっていきそうです。
https://twitter.com/jyoshise/status/1136917140605288448
インフラの GitOps を実現することについては、かなりの開発力が必要になると予想されます。
例えば Airship のようなものが、いずれはその役を担える日が来ると良いですね。
- Jenkins X のお話は、割愛しておりますので悪しからず
- Kubernetes Native な CI/CD 構築のサポートをしてます
- Continous Delivery Foundation が発足した
- CI/CD の標準化を狙っている
- Kubernetes Native とは
- あらゆるプロセスは、コンテナ上で稼働
- オブジェクトは、Decrarative に記述できること
- 状態の変更は拡張可能な Kubernetes API を通じて行われる
- GitOps
- PullReq -> Merge の流れ
- レイヤごとに考えられる
- アプリ
- インフラ
- Tekton
- Knative が出自
- Custom Reource として Pipeline を定義できる
- 足りないもの
- Event trigger
- Log Persistence
- SCM Support (chat ops)
- Pipeline Resource / Task の拡張性
- 2019年中に実装される予定
- Jenkins X + Prow + Tekton
- Jenkins X の中に Tekton が組み込まれている
Kubectl Apply 2019: Defense Against the Dark Arts
GitOps を実践するのは辛いので、CIOps + Kustomize + diff を考案した点、とても勉強になりました。確かに GitOps にいきなり進めるのは大変ですね。。
- 闇の魔術に対する防衛術
- kubectl apply: 宣言的っぽいリソース管理
- 3-way diff
- zlabさん(kusumiさん)の qiita ドキュメントに網羅されている
- 新しいバージョンの k8s
- server 側に差分計算をするための endpoint が追加された
- kubectl diff
- v1.13 以降で使用できるようになった
- Kustomize
- v1.14 以降で統合された
- Apply 怖い
- 動作がわかりにくい
- namespace 間違いで事故りそう
- yamlファイルがどんどん増えて管理が大変
-> gitops, or ciops に進みたいが、gitops はシステム自体の管理が大変- Kustomize + kubectl diff でシンプルに解決できないか
- CIOPS + Kustomize + kubectl diff で乗り切れそう
Resize Your Pods w/o Disruptions ... & Restart-Free Vertical Scaling...
- 発表タイトル
- Resize Your Pods w/o Disruptions aka How to Have a Cake and Eat a Cake
- Restart-Free Vertical Scaling for Kubernetes Pods
- VirticalPodScalerの現状
- 参加者の挙手では、VPA を実際に使っている人は皆無
- resource request 変更に伴い、pod の再起動が必要となる
- statefulset だと、あまり嬉しくないこともありえるので、今後の改善課題となっている
- Restart Free ...
- Option1(patch) だと race condition が発生する可能性がある
- Option2(annotation 使用)
- another one
- KEP にて proposal が出ている
- 弊社での取り組み
- YJ では200+のクラスタが稼働している
- アドオンの resource request の設定が難しい
- VPA を利用できないか検証中
- ユーザの利用動向の変更にうまく追従できそうなことが分かった
- in-place updater が欲しい
- 現状、YJ k8s では persistent volume が使えないため
Container Runtime Recap
- Container Runtime
- カバーしている領域は広範に及ぶ
- どこまでが runtime なのか
- 'run container' だけではない
- run container でやっていることが雑多
- high level と low level に runtime を分離したい
- 分離することで、差し替えができたり、例えば kata container / firecracker に移譲することもできる
- Lessons learned Migrating k8s from docker to containerd runtime
- Let's Try Every CRI Runtimes Available for k8s, No Reality!
- cri 実装をいくつか試す
- cata や gvisor は、そのままでは同じ動作をしないので、Shim を挟むことで差分吸収をしている
おまけ
Google さんの Guest Wifi ネットワーク、IPv4 には default route が付いていません。なかなかアグレッシブな構成です。
ということは、もはや古い端末からはインターネットに出られないのかな..
netstat -nrfinet6
Routing tables
Internet6:
Destination Gateway Flags Netif Expire
default fe80::200:5eff:fe00:265%en0 UGc en0
default fe80::%utun0 UGcI utun0
...
netstat -nrfinet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 12 1744911 lo0
169.254 link#8 UCS 1 0 en0 !
169.254.154.95/32 link#8 UCS 1 0 en0 !
...