KubeCon + CloudNativeCon North America 2017

12月6日から8日にわたり米国テキサス州オースティンで開催された KubeCon + CloudNativeCon に参加したのでその様子を報告する。

■ Keynote: A Community of Builders: CloudNativeCon Opening Keynote

最初のセッションでは Kubernetes と Cloud Native Computing Foundation (CNCF) の今年の動向について、流行っている (拡大している) ことを Google Trend や KubeCon の参加者の推移のグラフを使って説明していた。今回の参加者は 4,100 人強で、前回 (2017年ベルリン) の約 3倍である。 CNCF の Hosted Project が増えたという話もしていて、OpenStack Summit でもかつてそんな話を聞いたなあと懐かしくなった。

最初のユーザ事例として紹介されたのは Alibaba Cloud で、ピーク時に毎秒 32万トランザクション処理したとか、10万個のコンテナで動いているといった説明があった。巨大デプロイ事例はすっかり中国のものという印象である。

次の話題はダイバーシティで、基金をあつめて 100人くらいに奨学金を出しているようである。情報産業 (やもっと狭くオープンソースコミュニティ) が北米の男性に偏っていることが最近問題視されるようになったので、この話題は避けて通れないといった感じである。ダイバーシティプログラムの奨学生のビザがおりなかったのでコペンハーゲン (次回のサミット) に呼ぶということであった。

■ Keynote: CNCF Project Updates

CNCF は Kubernetes の他に現在 17 のプロジェクトをホスティングしており、それらを順番に紹介するというセッションであった。それらの中でも Prometheus (監視ツール)、 fluentd (ログ取得ツール)、 linkered (サービスメッシュ) の 3つはそれぞれ開発者が登壇して長めに紹介を行っていた。

■ その他のキーノート

その他の (短い) キーノートセッションは、事例紹介と (新) 製品の紹介が半々という感じであった。
事例紹介では、Kubernetes のデプロイツールとしての側面を強調したものが多かった。 GitHub の事例は次のようなものであった。
github.com のウェブサイトは Kubernetes で動いていて、コードの変更はまず内部の review-lab にデプロイする。そこで問題がなければ、実運用にデプロイするのだが、いきなり全て置きかえるのではく、一部のみ更新する (これを Canary Deployment と呼んでいた)。それで問題がないことがわかったらサイト全体に適用するという運用だそうである。そしてこれらの作業は自動化されているとデモで示していた。

新製品紹介としては、 AWS が EKS を紹介していた。 AWS の上に Kubernetes クラスタを構成するツールは既にフリーのものがあるのだが、AWS のサービスとして提供するにあたって (ネイティブと表現していた)、AWS VPC 対応の CNI プラグインや、IAM 認証対応を (それぞれ Tigera と Heptio に協力してもらって) 作ったと発表していて、これらの面での使い勝手の向上がはかられているようである。

Tigera は Google や IBM と一緒に開発した Istio を紹介していた。Istio はサービスメッシュを管理するためのもので、マイクロサービス間の通信にロードバランサをかけたり制御や監視を行う。 いままでのモノリシックなアプリケーションをマイクロサービスに分割すると動作がわかりにくくなるので、 Istio のようなツールを使ってマイクロサービス間の通信を可視化したり監視してねといった感じで宣伝していた。 Tigera は大きなスポンサーブースを出していたが、そこもほぼ Istio の宣伝であった。

■ Keynote: What is Kubernetes ?

最後のキーノートは Google の Brian Grant 氏によるこのタイトルであった。
最初の頃から Kubernetes をやってた人で、 Kubernetes は Social Experiment だとか言っていた。 Kubernetes とは何かについて、以下のものを含む 10通りの見方を順番に説明していた。

• Container Platform (オーケストレータ)
• 宣言型 (declarative) APIのコントロールプレーン
• 管理自動化のプラットホーム

Kubernetes はこんな風に使えますよ、こういう風に使いこなしてくださいねと言っているような感じでもあった。10番目の見方はエコシステムで、20 以上の関連するプロジェクト (OpenStack も含まれていた) のロゴを映しだして、これから皆で協力して盛りあげていきましょうとまとめていた。

5つのダイアモンドスポンサーのブースは立派だったが、それ以外はこじんまりしたものが多く、 OpenStack Summit のピーク時に比べるとまだまだという印象であった。 OpenStack では対応ハードを売る企業のブースが目立ったが、Kubernetes では AWS や GCE や Azure などのホステッド環境での運用がメインになると思われるので、展示物はソフトウェアが中心となっていたという違いもある。

■ Establishing Container Trust at Scale [I] – Tim Mackey, Black Duck Software

聴衆は150人位いて関心の高さを感じた。Docker Build がどのように動くかの話から始まった。Docker Image はレイヤーを重ねるようにして作られており、レイヤー一つひとつを見ていくと数がたくさんあり、しかも結構古いものも含まれている。古いもののうちメンテナンスされていないものがリスクとなるといった説明がされた。
Black Duck は脆弱性のあるソフトウェアのリストを持っているようで、それと照合することを Security Scan と呼んでいるようである。OpenShift では build 時に Security Scan できるという話があった。

また、ビルド後に脆弱性が明らかになることに対処するために、コンテナの脆弱性は継続的に評価する必要があるとも言っていた。後半では、CVE 番号を列挙しつつ最近のセキュリティ事件を紹介していた。脆弱性を放置しておくと酷い目にあいますよという啓蒙だと思われる (Equifaxの事件 (CVE-2017-5638) や Open IoT Proxy (CVE-2004-1653) など)。

■ Extending Kubernetes: Our Journey & Roadmap [I] – Daniel Smith & Eric Tune, Google intro

Google の人による Kubernetes の拡張のやり方の話である。 Kubernetes のコードを変更するのは大変なので Extension Mechanism を活用してほしいと言っていた。
Extension にはインフラ側と API 側の 2通りがあって、前者は Storage Interface, Cloud Controller Manager, Device Plugin, Network Plugin などがあり、API 側は CRD (Custom Resource Definition), Admission Extension などがあると順番に説明していた。
CRD は yaml でリソース定義をすることで Kubernetes の REST API を追加できる機能である。 CRD を使っている例として Calico Canal が紹介されていた (ネットワーク情報を CRD で保存している)。来年は CRD に自動で GUI がつくようにするそうである。

Admission Controller は Kubernetes の API リクエストが認証された後に動くもので、リクエストオブジェクトを変更 (Mutation) したり、弾いたり (Validation) するものである。いままでは静的なコードしかなかったが、Webhook で拡張できるようになったと説明していた。

■BOF: baremetal

無理矢理つめこんだスケジュールという感じであるが、 BOF は初日の Welcome Party の後にやっていた。 Baremetal で Kubernetes を運用している人達が話すセッションである。
GPU を使うとかディスクが大量にあるとかで、(面倒だけど) やむをえず Baremetal 上で Kubernetes を使っているそうである。 PXE で boot して Ansible でデプロイしているといった事例が話されていたが、会場からは Ansible はときどき失敗してトラブルシューティングもうまく行かなくて困ってるといった声もあった。いろいろな苦労があるようである。

■SIG

Kubernetes は OpenStack のようにプロジェクト毎にリポジトリは分かれていないが、分野ごとに SIG を作って活動している。 SIG は Special Interest Groups の略で、https://github.com/kubernetes/community/blob/master/sig-list.md に一覧がある。
KubeCon のプログラムでは、 SIG 毎に Update と Deep Dive の 2部構成になっているものが多かった。

・ SIG Network

まず Update のセッションで現状の報告があった。
Pod のネットワーク実装には Kubenet と CNI があるのだが、CNI に足りない機能を足して Kubenet を CNI に移行させて Kubenet は消す方針だそうである。 IPv6 対応については、 Kubernetes にもちょうどコードが入り始めた段階であるが、とりあえずの目標は IPv6 オンリーで IPv4 parity (IPv4 と同等の機能を実現する) だそうだ。Dual Stack 対応はまだだいぶ先になりそうである。CoreDNS の IPv6 対応も作業中だそうである。

各ノードに kube-proxy が動いているが、これの IPVS 実装が 1.9 で Beta になったという話もあった。以前からある IPtables の実装は遅いという問題があるとのことであった。

Kubernetes の Service を外部からアクセスできるようにするために Ingress というリソース (https://kubernetes.io/docs/concepts/services-networking/ingress/) があるが、API が Beta のままで、 Ingress Controller の実装依存の Annotation に互換性がないという問題があると説明されていた。

CoreDNS の話もあった。Plugin を組みあわせて作られているのが特徴だそうである (参考: https://coredns.io/plugins/)。Kubernetes 1.11 のリリース時にあわせて GA にする予定だそうである。

続く Deep Dive のセッションでは、多くの参加者が興味を持つ話をしたいということで、司会が参加者に手を挙げさせてトピックを決めていた (「この話を45分続けたら出ていく人は?」という聞き方をしていておもしろかった) 。
最初の話題は Ingress である。参加者も結構使っていて、そのうちのほとんどの人が Annotation も使っているという状況である。いまさら共通化なんて難しいから Portable な Ingress なんて要らないんじゃないのという意見もあった。

次の話題は Multiple Networks で、 Pod を複数のネットワークに繋ぐ話であるが、 Kubernetes がそういうことを想定した作りになっていないので、いままで動いていたものが動かなくなってしまうのがまず問題であり、 Node の拡張はやりづらいということであった。しかし、コミュニティの関心は高いので何かやれるのではないか、まず代表的な Top Use-Cases をみつけてそれから作業を進めていこうという話になった。そのような Use-Case の例として、 High Performance Network (40Gビットイーサネットとか) などが挙げられていた。
実は Multus (https://github.com/Intel-Corp/multus-cni) というものがあって、 CNI レベルで複数ネットワークを実装しているのだが、 Multus のようなものは短期的なソリューションになるかもといった意見もあった。

・ WG multitenancy Deep Dive

狭い部屋ではあったが、人が溢れて立ち見がでていた。
Microsoft や Google の人達が考えているマルチテナントをそれぞれプレゼンして、これからどう合意をとっていこうかという段階であった。Soft Multi-Tenancy, Hard Multi-Tenancy というキーワードがあって、前者は 1つの組織の部署間のテナント分離で厳密なセキュリティは要らないもの、後者は全く別の顧客で完全なセキュリティが求められるものという意味である。後者を実現する手段として、 Katacontainer のような VM 技術を使ったものや、Node-Level Solation (ノード単位で複数テナントが同居しないように制御する) といったものが出ていた。 Network, DNS などの分離をどうするかといった話もあり、先は長そうな感じであった。

・ SIG Schedule + Resource Management Working Group

普段は 10人から 15人くらいでミーティングをやっているグループだと自己紹介していた。VM と比較して性能が出ていない点を改善したそうで、具体的には CPU pinning, hugepages, NUMA やハードウェアアクセラレータである。ハードウェアアクセラレータについて、 Device Plugin を作ったとか、モニタリング機能を足したという話があった。(どちらも現状使えるのは NVIDIA の GPU のみ)

2018年のテーマとして、 Device Plugin はいま Alpha だが、まず Beta にしてから GA まで持っていきたいということや、HugePages も同様にといったことを話していた。また、 Resource API に関して、いまあるものでは GPU や FPGA 等をうまく表現できず、Resource Class をどう定義するかや PoC (実証コード) を作るかどうかの議論がされていた。
(参考: https://github.com/kubernetes/community/pull/782)