Above & Beyond

日々のアウトプット記録

Kubernetes Meetup Tokyo #16

参加報告

02/19(火) は「Kubernetes Meetup Tokyo #16」に参加してきました。

k8sjp.connpass.com

f:id:kabukawa:20190217163535p:plain

会場は ヤフー株式会社 さん。

f:id:kabukawa:20190219182600j:plain

Yahoo Lodgeかと思ったら、奥の方にある別のセミナー用の会場でした。メチャクチャ広い！

目次

Kubernetes Meetup Tokyo とは

イベントの概要から引用します。

コンテナをデプロイできる強力なシステム Kubernetes のことを詳しく聞く会です！

Kubernetes はここ数年で一気にコンテナオーケストレーションのデファクトに上り詰め、クラウドネイティブのコンポーネントにおいても中心的な役割を果たす重要なコンポーネントになりました。その Kubernetes についての知見を共有してもらえる、とてもありがたいMeetupだと思います。毎回参加したい人が多くて、申し込んでも抽選になるのですが、倍率が3倍以上の狭き門になっています。(過去に登壇したことがある場合は優先参加できるようです)

何故参加したか

Kubernetes は一昨年くらいから注目をしていました。(理解できていたわけではなく、分からないので勉強したいなぁという割とふわっとした理由です) なので、このMeetupを見つけて一昨年の後半から参加しました。

調べてみたら去年の1月ですね。。。

ところがみるみる人気勉強会となり、2回位参加できた後はずっと抽選で外れて参加できませんでした。 なので、今回は1年ぶりくらいの参加になります。 1年間で周りの状況も大きく変わりましたし、そのあたりの話が聞けるのをとても楽しみにして参加しました。

タイムテーブル

時間 内容 スピーカー
18:15～19:00 受付開始 (19:30まで)、ソーシャル
19:00～19:05 Opening (5min)
19:05～19:35 Z氏は、Kubernetesクラスタを手中に収めることができたのか 大塚 元央 (@yuanying)
ゼットラボ株式会社
19:35～20:05 CNI 入門 Hirofumi Ichihara (@rafiror)
LINE Corporation
20:05～20:35 大規模Kubernetesクラスタ向けにCNIプラグインを自作した話 池添 明宏 (@zoetro)
サイボウズ株式会社
20:35～21:05 懇親タイム sponsored by Yahoo! JAPAN
21:05～21:10 猫でもわかる Scheduling Framework（仮） @y_taka_23
21:10～21:15 intelのdevice pluginを試してFPGAリソースとして使えるようにした話 @khrd
21:15～21:20 EKS後の世界とeksctlについて @mumoshu
21:20～21:25 Kubernetesを使った機械学習基盤に必要なもの @FKuro_
21:25～21:30 AKS,EKS,GKEコマンド比較してみた話 @yuta

内容

動画が公開されていますので、全容を知りたい方はこちらを見ると会場の雰囲気も含めてよく分かると思います。 配信、ありがとうございます！

www.youtube.com

というか動画配信されていたんですね。参加できなかった時も動画配信見ればよかったのか。。。orz

動画があるので、セッションについては自分のツイートを貼る感じで。

Z氏は、Kubernetesクラスタを手中に収めることができたのか

ゼットラボ株式会社 大塚 元央 (@yuanying) さん

speakerdeck.com

ネタ振りとして、直近に出た脆弱性の話題。この話をするか、今回の話をするか迷ったとのこと。

今回のセッションは去年のJapan Container Days 12.08 の直前に出た脆弱性の話。 「この脆弱性について知っている人物であれば誰でもKubernetesクラスタを手中に収めることができる。」が本当なのかが今回のセッションのポイント。

この脆弱性についての説明の最初でいきなり分子生物学におけるCentral Dogmaについて。Central Dogmaが何かは以下をどうぞ。

en.wikipedia.org

情報の流れは必ず片方向である、という考え方。

セントラルドグマ これは、一度「情報」がタンパク質に伝わると再び出ることはできないと述べています。
より詳細には、核酸から核酸へ、または核酸からタンパク質への情報の伝達は可能であり得るが、タンパク質からタンパク質へ、またはタンパク質から核酸への伝達は不可能である。
ここで情報とは、核酸中の塩基またはタンパク質中のアミノ酸残基のいずれかの正確な配列決定を意味する。

では、Kubernetesにおけるセントラルドグマに相当する部分はどこか？それがAPI サーバー。

APIサーバーはKubernetesクラスターへのゲートウェイです。 これは、Kubernetesクラスター内のすべてのユーザー、自動化、およびコンポーネントによってアクセスされる中心的な接点です。

www.oreilly.com

ただし、例外はある。

  • Pod に対するexec/attach/port_forward 時の認証

Kubernetes APIを拡張する方法

  1. Custom Resource Definition (CRD)
    • オススメ䛾方法
  2. Aggregated API Server
    • CRD で䛿実現不可能な API を実装する場合

Kubernetes に Kubernetes の API に加えて別の API を追加する場合に、APIサーバーはAggregator(k8s api endpoint)として動作する。

Aggregated API を呼び出す際、Aggregatorは認証プロキシとして動作するので、Aggregated APIはAggregatorからの呼び出しを全面的に信頼する。

  • apiserver からのリクエストをどうにかして書き換えられれば、Aggregated API Server の API を自在に操ることができそう

今回の脆弱性

  1. Reverse Proxy は WebSocket 接続モードへと切り替わったのち、Client からのパケットを Backendへ中継のみを行う。
  2. Upgrade に失敗した場合、接続を終了し以降䛾クライアントからのリクエストを破棄する必要がある。
  3. エラーハンドリングに問題があり、Upgradeが失敗したにも関わらず、Reverse Proxyが WebSocket 接続モードに移行してしまう。

HTTP Upgrade に失敗し、 WebSocket を受信する準備が整っていないサーバに対して無制限にデータを送れてしまう

つまり

バックエンド䛾APIをリクエストできる人は誰でも、apiserver の権限でバックエンドのAPIをリクエストできてしまう。

権限昇格の脆弱性

デモのところは手順を追って

  • どこが問題で
  • どうなってしまうのか

がとてもわかり易く解説されているので、ぜひ動画で見てください。

は正しくなくて、実際には

  • この脆弱性について知っている人物であれば誰でも Aggregated API Server の API を呼び出すことができる。

ということがわかった。但し、

CNI 入門

LINE Corporation Hirofumi Ichihara (@rafiror) さん

speakerdeck.com

コンテナのネットワーク周りの仕組みとしてはCNI(Container Network Interface)とCNM(Container Network Model)がある。今回はCNIの話。

f:id:kabukawa:20190222235617p:plain:w500

CNIとは

f:id:kabukawa:20190222235632p:plain:w500

CNIリポジトリ

CNIオペレーション仕様

コマンド 機能
ADD コンテナ八ネットワークを追加する
DEL コンテナからネットワークを削除する
CHECK コンテナのネットワークを確認する
VERSION CNIのバージョンをレポートする

CNI基本動作原理

f:id:kabukawa:20190222235646p:plain:w500

環境変数で渡されるパラメータ

  • CNI_COMMAND
    • CNIのオペレーション ADD、DEL、CHECK、VERSION のいずれか。(version 0.4.0)
  • CNI_CONTAINERID
    • コンテナID
  • CN|_NETNS
    • ネットワークnamespaceのファイルパス
  • CNI_IFNAME
    • コンテナ内につけるインターフェースの名前
  • CNI_ARGS
    • プラグイン実行時に設定できる任意の情報、Key-value pair をセミコロンで区切って与 える(例：FOO=BAR;ABC=123)
  • CNI_PATH

ネットワーク設定(JSONで記述 標準入カで与える)

  • cniVersion(string)：CNIのバージョン
  • name(string)：ネットワークの名前
  • type(string)：実行するCNIプラグインのファイル名
  • args (dictionary, optional)：ランタイムから与えられるオプション情報
  • ipMasq (boolean, optional)：IPマスカレードを設定
  • ipam(dictionary, optional)：IPAM設定のための情報
    • typn (string)：IPAMブラグインのファイル名
  • dns(dictionary, optional)：DNS設定のための情報
    • nameservers (list of strings, opnonal)：DNS nameserverのリスト。IPv4もしくは lPv6で表現されたstringのリスト
    • domain (strings, optional)：ローカルドメイン切指定
    • search (list of strings, optional)：サーチドメインのリスト
    • optmons (lot of strings, optional)：リゾルバに渡すオプションのリスト

CNIプラグイン仕様

f:id:kabukawa:20190222235703p:plain:w500

CNIチェイン動作原理

f:id:kabukawa:20190222235717p:plain:w500

プラグインのデモについては御本人がこちらに纏めていただいたようです。 ありがとうございます！

qiita.com

CNI Roadmap

  • v0.6.0
    • Plugin composition functioraality
    • IPv6 support
    • Strategy and tooling for backwards compatibility
    • Integrate build artefact generation with CI
  • v1.0.0
    • More precise specification language
    • CHECK action
    • Conformance test suite for CNI plugins (both reference and 3rd party)
    • Stable SPEC
    • Complete test coverage
    • Signed release binaries

大規模Kubernetesクラスタ向けにCNIプラグインを自作した話

サイボウズ株式会社 池添 明宏 (@zoetro) さん

speakerdeck.com

neco プロジェクト

necoのアーキテクチャ

f:id:kabukawa:20190220122214p:plain:w500

成果はOSSとして公開。ということで neco プロジェクトのリポジトリ。

github.com

neco を支えるソフトウェア

f:id:kabukawa:20190220122248p:plain:w500

なぜCNIプラグインを自作したのか？

necoのネットワーク構成

f:id:kabukawa:20190220122822p:plain:w500

blog.cybozu.io

CNIプラグインの選定

  • データセンターネットワークと合わせて、KubernetesのネットワークにもBGPを採用して効率的にルーティングをおこないたい。
  • 既存のプラグインだとうまくマッチしなかった

プラグインの組み合わせ

  • コンテナネットワークでは解決すべき課題が多数ある。
    • IPアドレス管理 (IPAM)
    • ネットワーク接続性
    • ネットワークポリシー
    • 帯域制限
  • すべての問題を1つのプラグインで解決する必要はない。

どこを自作する必要があるのか？

  • ネットワークポリシー
  • IPアドレス管理 (IPAM)
  • ネットワーク接続

プラグインを自作(coil)

github.com

特徴

  • Go言語で実装、バックエンドには etcd を採用
  • Linux only, Kubernetes only, IPv4 only
  • IPAMとノード内のルーティング機能のみを提供
  • ルーティングソフトウェアを内包しない
  • 大規模クラスタでの利用を考慮

coilの構成要素

f:id:kabukawa:20190220123429p:plain:w500

coil処理の流れ

f:id:kabukawa:20190220123449p:plain:w500

CNIプラグイン開発で得られた知見

  • 開発やデバッグが大変では？
    • ネットワーク構成をソフトウェアで仮想化した環境で簡単に動作確認をおこなうことができるので、それほど大変ではない。
  • Kubernetesの情報を得るには？
    • CNIプラグインはPodの情報を取得する仕様は定められておらず、実装を読み解く必要があった。
  • CNIプラグインが読み込まれない
  • Kubernetes 1.13でPod間通信ができない
    • Linuxのカーネルパラメータ(sysctl)の設定が変更されていた (リリースノートに記述なし)

LT

LTは力尽きたので資料を貼るだけで、、、でも、こちらも各セッション5分とは思えない内容の濃さでした。普通のセッションで聞きたい内容！

猫でもわかる Scheduling Framework（仮）

@y_taka_23 さん

speakerdeck.com

intelのdevice pluginを試してFPGAリソースとして使えるようにした話

@khrd さん

docs.google.com

EKS後の世界とeksctlについて

@mumoshu さん

speakerdeck.com

Kubernetesを使った機械学習基盤に必要なもの

@FKuro_ さん

speakerdeck.com]

AKS,EKS,GKEコマンド比較してみた話

@yuta さん

speakerdeck.com

懇親会

こういうことで食べ物と飲み物の写真はありません。

楽しかった、ということで雰囲気を察していただければ。。。

まとめ

今回は常連の参加者の皆さんが口々に「神回」と仰っていた通り、とても内容の充実した素晴らしいMeetupだったと思います。 1年前に参加したときより、少し雰囲気も柔らかくなった感じがしました。 それだけ、講演者、スタッフ、参加者の方々が「楽しんで」作り上げているコミュニティなんだなと改めて感じました。 これはみんな参加したくなるのも頷けますね。 動画配信が行われることも分かったので、仮にリアル参加できないとしても動画でリモート参加が可能ですし、次回からはそちらも活用できればなと思っています。

講演者、スタッフ、参加者の皆様、ありがとうございました！

おまけ

Kubernetes Meetup Tokyoでは、質問をするとステッカーをいただけるという事になっています。 そう言われると質問してステッカー貰いたくなるので、とても良い仕掛けだと思います。 セッションの最後だけでなく、懇親会の時に質問してもOKです。かく言う僕も、前回参加した時にいただいて、大事にPCに貼ってあります。 なので、参加できたときは是非登壇者に質問してステッカーを貰いましょう！

f:id:kabukawa:20190220125125j:plain:h300

また、Kubernetes Meetup Tokyo では無いのですが、今年行われる CloudNative Days 2019 のステッカーをいただきました。 ありがとうございます！

f:id:kabukawa:20190220125527j:plain:w300f:id:kabukawa:20190220125539j:plain:w300

CloudNative Days は 去年行われた Japan Container Days の後継イベントです。

cloudnativedays.jp