こんにちは、Necoプロジェクトのmitzです。
楽しかったKubeConもいよいよ最終日となりました。これまでの現地レポートはこちらになります。
それでは今回も数多くのセッションの中で印象に残った発表などを簡単に紹介していきます。
Keynote: Metrics, Logs & Traces; What Does the Future Hold for Observability? - Tom Wilkie, VP Product, Grafana Labs & Frederic Branczyk, Software Engineer, Red Hat
Observabilityの将来について語ります。Observabilityとして3つの柱として掲げたのが、メトリクス(監視)、ログ(収集)、トレースです。そして3つの予測を立てました。
- 柱同士にもっと相関関係を。例えばPrometheus(メトリクス) + Grafana Loki(ログ収集)、Elasticsearch(ログ)+Zipkin(トレース)といった組み合わせです。例えば同じようなUXを持ち、あるタイムラインのメトリクスとログを参照できるようにするといったことが挙げられます。
- 新しいシグナルと分析。継続的にプロファイリングを行うことで、障害や警告などの予測を立てる。
- Indexingをしないログ収集。Indexingをした環境で収集されたログを検索する場合、ソフトウェア専用のQueryを組み立てて絞り込みを行います。一方でgrepコマンドでシンプルにパイプを使った絞り込みの方がLinuxユーザーにとっては慣れ親しみを感じます。簡単に絞り込みができ、Indexingを必要としない使い勝手が必要なのかもしれません。
Grafana Loki: Like Prometheus, but for Logs - Tom Wilkie, Grafana Labs
Keynoteに登壇したTom Wilkie氏によるLokiの紹介とデモです。PrometheusおよびCortexのMaintainerでもあります。
Lokiはスケーラビリティと高可用性を持つログ収集システムで、KubeCon North America 2018で発表されました。代表的なログ収集システムではCNCF Graduated projectのFluentdがあります。ログの収集後に検索できるようにするまでの手順としては、ElasticsearchでIndexingしておき、他のWeb UIでで検索するというのがよくある手順です。実現するにはIndexingが必須で、さらにFluentdにおいてはFilterを定義してログの種類を教えておく必要があります。すなわちそのような構成を構築するだけで面倒な点が多いのが課題です。それらの課題を解決するのがLokiです。LokiはPrometheusにインスパイアされており、以下の特徴があります。
- PrometheusのようなLabel, tagベースの検索。外部サービスによるIndexingが不要。
- PrometheusのようなService Discoveryによって自動的にPodを検出し、そのログを収集する(promtail)。
- Grafana Labsによる解決でWeb UIの親和性も高い。
- LogQLによる絞り込みを行う。grepのような形で条件をつなげることができる。
このセッション会場は一番大きく、ほぼ席が埋め尽くされるほどの人気でした。当日のKeynoteに感銘を受けた人や以前から気になっていた参加者が集まっていたのかもしれません。デモやTomの人柄もとてもユニークでした。
Kubernetes Scalability Definition Evolution - Wojciech Tyczynski & Andrzej Wasylkowski, Google
Kubernetesはスケーラビリティのあるコンテナオーケストレーションですが、ではスケーラビリティとは何なのかという問いに対して答えるというセッションでした。まずSLI(Service Level Indicator)やSLO(Service Level Objecive)を満たせばその条件においてスケーラビリティが可能と約束することができました。2015年と2017年においては以下のようなSLIやSLOを満たせばスケーラビリティがあるとしていました。
2015年
- API reqeustが1秒以内で99%返ってくること
- 予めコンテナイメージをPullしておいた環境でコンテナが5秒以内で99%起動すること
2017年
現在は多くのSIG(分科会)があり、いろいろな要因によって条件の達成の難易度が上がるかもしれないし、条件として過不足があるかもしれません。それを見直してより正確なSLI/SLOを定義することになりました。具体的には正確かつ矛盾が無く、観点がユーザ志向であり、かつ、テスト可能なものとしました。
さらに定義を公開した後にサービス利用者からのフィードバックを受け取り、それをもとにシステムを改善するといったサイクルを回すことがよりよいサービス提供の要となります。
今回の例ではKuberenetesの成長に合わせた定義の変更でしたが、モノリシックなインフラからマイクロサービスに切り替える際にも、SLI/SLOを再定義する必要があると感じました。
Secrets Store CSI Driver-Bring Your Own Enterprise Secrets Store to K8s - Rita Zhang, Microsoft & Anubhav Mishra, HashiCorp
CSIによるSecret Volume mountの紹介です。
CSI(Container Storage Interface)とはKubernetes、Mesos、Docker、Cloud Foundryといったコンテナオーケストレーションにおいてコンテナで使用するVolumeの形式を標準化した仕様です。KubernetesにおいてはサードパーティのStorageClassを使用する場合、まずすべてのNodeにAttach/Mount/Detach/Unmountをするためのプログラムをインストールしておく必要があります。例えばCeph RBD(Block Device)を使いたい場合はrbdコマンドを全Nodeに用意します。
Volume操作をするプログラムのインストールという操作をなくし、より効率よくVolumeを提供かつ標準化のために作られたのがCSIです。Kubernetes v1.13でGAとなり、誰でもKubernetes向けにCSI driverを作る環境がすでに整っています。
このセッションではCSI driverでsecretを読み込む方法について解説しています。CSIによるVolumeはPersistentVolumeおよびPersistentVolumeClaimのみしか使えなかったのですが、EphemeralなVolume、例えばSecretリソースのMountもCSI driverでできるようにしようという機能があります。これをCSI Inline Volumeと呼んでいます。
(KEPとはKubernetes Enhancement Proposalsの略で、改善したり新しい機能を追加したいときに提案するドキュメント)
この機能はKubernetes v1.15-alpha.2以上でFeatureGate(beta, alphaの機能をフラグで有効にする機能)で利用できます。なお本記事執筆時点におけるKubernetesの最新版はv1.15-alpha.3です。
デモでは3種類のSecretをCSI driverによるMountで読めるようにするというものでした。
- Kuberenes標準のSecret
- Microsoft Azure Key Vault
- HashiCorp Vault
現在はいずれもAlphaであり、またKubernetes APIからSecretを作成して各サービスのVaultに保存するといった事もできません。CSIが登場する以前はFlexVolumeという形式で、上述の通り全NodeにVolume操作のプログラムをインストールして利用しています。現在はFlexVolume形式が主流ですが、CSI driverはまだまだ少ないため、コミュニティとしてもFlexVolme相当の機能開発をしている段階であると感じました。一方でこのようなまさに開発中のお話を聴けるのが、参加の醍醐味でもあります。
会場の様子
Kubernetes生誕5周年ということで、感謝のメッセージを綴るWallや、歴史をまとめたブースがありました。
青いかけらのようなものは、自分がどの頃にKuberenetesに触れ始めたのか参加者が貼り付けたものです。ちなみに私の場合、etcd v2でRBACがデフォルトではなかったころでした。おそらく2016年ごろですね。
最後に
最後のKeynoteで今後の予定が公開されました。KubeCon Europe 2020はアムステルダム(オランダ)です。
バルセロナは食事が美味しいし安い。そしてこの時期は21時過ぎまで太陽が照り続けてる街です。 4回目の参加でしたが、今回が最高だったと思います。
KuberenetesおよびCNCF Projectの今後の成長も期待しつつ、次回も現地からのレポートをお送りしたいと思います。5日間連続に渡って読んでいただきありがとうございました！
