Kubernetes Meetup Tokyo #20 参加レポート

はじめに

今年に入ってますます Kubernetes (k8s) が盛り上がりを見せています。つい先日も Apple がCNCF (Cloud Native Computing Foundation) への参加を発表する 等、エコシステムの進化が急速に進みそうなニュースも発表されました。今後、ますます k8s を使うユーザが増えていくと考えられます。

今回、2019年6月18日に開催された Kubernetes Meetup Tokyo #20 に blog 枠として参加させていただけましたので、イベントの内容についてレポートいたします。

• Kubernetes Meetup Tokyo #20 へのリンク
  • https://k8sjp.connpass.com/event/134064/
• 発表資料
  • https://k8sjp.connpass.com/event/134064/presentation/

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 をしたい
• 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 が付いていません。なかなかアグレッシブな構成です。
ということは、もはや古い端末からはインターネットに出られないのかな..

bash

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      !
...