Zenn
🛠️

2021年に注目すべきCNCFの5つのテクノロジーを「Kubernetes Meetup Tokyo」のセッション記事から解説する

2021/01/11に公開
Kubernetes
Chaos Engineering
tech

はじめに

Kubernetes Meetup Tokyoの懇親会用に話のネタとしてメモを残す。

2021年に注目すべきCNCFの5つのテクノロジーとは？

https://twitter.com/lizrice/status/1329867030284144640

KubeConNA(2020)最終日のkeynote session、Keynote: Predictions from the Technical Oversight Committee (TOC) - Liz Rice, CNCF TOC Chairで、CNCFのTOC(技術統括委員会)の委員長を務めるLiz Riceさんが、CNCFの2021年の技術的展望として紹介した5つの技術要素である。(順不同)

  1. カオスエンジニアリング
  2. エッジコンピューティングとしてのKubernetes
  3. サービスメッシュ
  4. Web assembly and eBPF
  5. Developer + operator experience

これらの技術について、「Kubernetes Meetup Tokyo」のセッション(KubeFest Tokyoを含む)より関連するセッションとともに紹介したい。

Kubernetes Meetup Tokyo

"Kubernetes Meetup Tokyo は強力なコンテナオーケストレーションツールである Kubernetes について詳しく聞く会です！" とのこと。初回は2016/05に開催。現在まで37回を数える国内で長く続いているKubernetes勉強会の一つ。

CNCFの5つのテクノロジーをセッションから俯瞰する

  1. Kubernetes Robotics Distributed System Deep Dive

  2. Kubernetes based connected vehicle platform

  3. kubeadmのphaseから解るKubernetesクラスタの正体

  4. Resilience Engineering on Kubernetes~ワンターレンの夜明け~

エッジコンピューティングとしてのKubernetes

エッジコンピューティングとは、"エッジ処理とも呼ばれ、「端末の近くにサーバを分散配置する」ネットワーク技法"を指す。[1]端末からサーバーまでの通信距離を短くすることで、通信遅延を防ぎ、また負荷分散を行うことが目的だ。この分散配置したサーバーをKubernetesで管理しようというのがエッジコンピューティングとしてのKubernetesの狙いである。

Kubernetes Meetup Tokyoのセッションからは、藤田さんによるロボットをKubernetesのエッジノードとして活用しようとする研究事例を紹介したい。

Kubernetes Robotics Distributed System Deep Dive

元々は5分のLTだったが、好評だったため、再度ロングセッションをすることになった。その理由の一端となったのが次のスライドだ。この事例ではKubernetesのノードとしてドローンを利用している。

通信圏内に入ったドローンを自動的にKubernetesのクラスタにjoinし、通信圏内から離れたら自動的にdrainする。クラウド、ロボットが相互接続し、分散システムを作るSonyの構想は勉強会で大きな話題を呼んだ。

サービスメッシュ

サービスメッシュとは、"マイクロサービスごとにプロキシを配置し、プロキシを経由して他のサービスと通信させることでサービスの依存関係やトラフィックを制御する仕組み"である。[^servicemesh]

Kubernetes Meetup Tokyoのセッションからは、Densoさんによる開発されているプロジェクトMisakiを紹介したい。

Misaki: Kubernetes based connected vehicle platform

Misakiプロジェクトとは何か？

Publikeyさんの記事、Kubernetesを自動車に載せる、デンソーが「Misaki」を発表。年内にもオープンソースとして公開より引用する。

自動車は現在スマート化やネットワーク化が急速に進んでいます。自動運転を目指した自動車の進化を見るまでもなく、今後多くのコンピュータリソースが自動車に搭載されるようになり、そこで実行されるアプリケーションの重要性が高まっていくことは間違いありません。

デンソーが発表した「Misaki」は、このようなアプリケーション実行環境としての自動車をクラウドを中心としたネットワーク化された分散アプリケーション環境のエッジと位置づけ、その基盤をKuberenetesで実現するためのソフトウェアです。

Misakiによって、自動車向けアプリケーションがコンテナで開発、実行できるようになり、またMisakiが提供するサービスメッシュ機能により、アプリケーションは自動車の不安定なネットワーク環境を意識せずに開発でき、アプリケーションの自動車へのデプロイやアップデート、削除なども集中管理可能となります。

このプロジェクトの技術要素が、「エッジコンピューティング」と「サービスメッシュ」だ。

「サービスメッシュ」は、マイクロサービスアーキテクチャにおいて、サービスの可用性を担保するために開発された仕組みだが、サービス間のネットワーク経路が不安定になりがちなエッジコンピューティング環境においてもうまく動作することを示した応用事例だと言える。

Developer + operator experience

ワークフローが簡単になり、YamlやGitOpsみたいな細かい実装から開発者は解放されるべきだとLiz Riceさんは話す。

  • プラガブルダッシュボードやapi指向の拡張的なUIの実装
    • 著者注: Starboardを思い出した。セキュリティ周りとダッシュボードの統合の流れは今後も進化を続けそうな感じはしてる
  • ベストプラクティスやツールの使用方法を企業間で共有するための開発者ポータルサイト
    等々が2021年にトレンドとして来るらしい。

Kubernetes Meetup Tokyoのセッションからは、世良さんによるkubeadmの解説セッションを紹介したい。

kubeadmのphaseから解るKubernetesクラスタの正体

Kubernetes The Hard Wayをご存知の方は多いと思う。GoogleのKelsey Hightowerさんによって発案された、Kubernetesクラスタを手動で作ってみようという手引書だ。

Kubernetesのクラスタがどうやって構成されているのか理解するため、あるいはCKAと呼ばれる認定試験準備のため、このKubernetes The Hard Wayに基づいて動くKubernetesクラスタを構成することは、Kubernetesインフラエンジニアにとって登竜門とも言える。[2]

実際のオンプレミス商用環境で、Kubernetes The Hard Wayに従ってKubernetesクラスタを構築するエンジニアはほぼいない。代わりに使用するのが kubeadmだ。

Kubernetesコミュニティ、正確にはCluster Lifecycle Special Interest Group(GoogleやVMWareの人が委員を務めている)が主宰となって開発しているKubernetesクラスタの自動構成ツールである。

マスタノードを作るためには下記のコマンドを叩けばよい。

kubeadm init

これだけだ。これだけでマスタノードができてしまう。

その裏では一体何をしているのか？
Kubernetes The Hardwayで延々と証明書を作らされた第四章はどこへ消えてしまったのか？

それらの疑問に答えて、kubeadm init について深く解説したのが本セッションになる。

たった一つのコマンドの裏には実は13ものフェーズがあるという。それらが組み合わさることでKubernetesのマスタノードはできるのだ。

詳細はセッションを見てほしい。また、kubeadm init 以外のコマンドに関しては書籍化した下記を参考にしてほしい。

解体kubeadm　フェーズから読み解くKubernetesクラスタ構築ツールの全貌

kubeadm upgrade 等はお世話になるエンジニアは多いと思うので、内容は知ってて損はしないと思う。

カオスエンジニアリング

カオスエンジニアリングとは"本番環境の分散システムが過酷な状況でも耐えれるとの確信を得るために、実験するという取り組み"を指す。

Kubernetes Meetup Tokyoのセッションからは、真壁さんのResilience Engineering on Kubernetes~ワンターレンの夜明け~を紹介したい。

Resilience Engineering on Kubernetes~ワンターレンの夜明け~

カオスエンジニアリングにおいて、障害を起こすためには実験計画は欠かせない。障害が起きてからそれがどのような問題が起きるのか予測することが重要だ。では、その実験計画の要であるハザードシナリオ(障害を引き起こすためのシナリオ)は、どうやって作ればよいか？

一つがKubernetes Failure Storiesのような先達に倣う例だ。しかし、環境に依存した特殊な例もあるし、自分たちの環境にどこまで応用ができるか判断は難しい。

そこでCAST(Causal Analysis using System Theory)で事故発生後に原因を分析しつつ、STPA（System-Theoretic Process Analysis）と呼ばれる安全性解析手法でハザードを識別しながら、ハザードシナリオの妥当性を確認して一般化する方法を紹介している。

カオスエンジニアリングの今後について

Kubernetes Tokyo Meetupでカオスエンジニアリングネタがあんまり引っかからなかったのでここに書いておくと、一年を振り返れば「カオスエンジニアリングとKubernetesとゲーム」を組み合わせたプロジェクトはトレンドだったと思う。Twitterなどで過去に次のソフトウェアが話題になった。

  • 端緒となったのはKubeInvadersだ。SpaceInvaderのようにエイリアンと化したPodを次々と撃ち落としていくこのサービスはCNCFのブログ記事でも紹介されるほど話題となった。

https://twitter.com/gashirar/status/1266996439869083649

  • @gashirar さんが作成した カオスエンジニアリング X Kubernetes X Minecraftな KubeChaosCraftMod

https://twitter.com/learnk8s/status/1256961851965034499

  • DoomのモンスターをKubernetesのPodに見立てて除去していくkubedoom などである。

こういったゲーム感覚でKubernetes上のサービスに対してカオスエンジニアリングを行う仕組みにより窓口が広がるとともに、CNCF所管のプロジェクトであるLitmusChaosのような、本番環境のリリース前にプロダクトの品質チェックをするためのプロダクトも増えた。

拙ブログで過去に カオスエンジニアリングの過去と今(前編) という記事を書いたので参考にしてほしい。

2021年トレンドとして、AWSがManaged ServiceとしてFIT(Fault Injection Testing)を出したことによるカオスエンジニアリングの事例の増加、カオスエンジニアリングをCI/CDの一部として組み込むような動きがあると思われる。

Web assembly and eBPF

所感

他にも紹介損ねたセッションは山ほどあります。実際に振り返って見て、Kubernetes Meetup Tokyoが動画付きで全部セッションが残っている事、Kubernetesのプラットフォームの上でいかようにも話が未来へ発展することに気づかされました。

最後にお願いです。ぼっち嫌なので、明日誰か話しかけてください。

参考文献

^servicemesh

脚注

  1. https://www.keyence.co.jp/ss/general/iot-glossary/edge-computing.jsp#:~:text=エッジコンピューティングとは,遅延を解消します。 ↩︎

  2. 半分くらいのエンジニアはここで満足せずに、Raspberry Piでクラスタを組んだり、Hyper-Vに乗せたり、おうちサーバーに組み替えたりする。何が彼らを駆り立てるのだろうか... ↩︎

Discussion