![[レポート] Kubernetes Meetup Tokyo #10 に参加してきました! #k8sjp](https://devio2023-media.developers.io/wp-content/uploads/2018/03/eye-catch-k8smeetup10.jpg)
[レポート] Kubernetes Meetup Tokyo #10 に参加してきました! #k8sjp
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
3/8 に開催された標題ミートアップに参加してきましたのでレポートします。Docker 本体が取り込み、AWS もマネージドサービスとして提供開始予定を発表している Kubernetes のイベントということで、参加人数も多く勢いが感じられるミートアップでした。
会場は六本木の Google 本社食堂。Google といえば Kubernetes 開発の発端ですし、本ミートアップスポンサーの Google Cloud Platform も Google Kubernetes Engine (GKE) としてサービス提供していますから、お膝元といってもよいところです。
なお念のためながら、以下で Kubernetes を k8s と略称することがありますのでご了承ください。
発表一覧
- Open Service Broker APIとKubernetes Service Catalog
 - Kubernetesセキュリティベストプラクティス
 - Debugging Applications in Kubernetes
 - LT: 『入門Kubernetes』の紹介
 - LT: Pod の優先度と割込みについて
 - LT: Amazon EKSデモ
 - LT: other ingress voyager
 - LT: DockerでHelmを使おう
 
※以下敬称略
同録動画
本ミートアップは非常に多くの(550名以上の!)方が参加を希望し、最終的な参加も 200名を超えるのですが、抽選に漏れた方も多かったとのことで Youtube で動画の配信もされました。埋め込みは無効になっていましたのでリンク先でご覧下さい。
Open Service Broker APIとKubernetes Service Catalog
スピーカー : Toshiaki Maki (@making) (Pivotal)
Open Service Broker APIはデータベースやメッセージブローカーなどのサービスのプロビジョニングやクレデンシャル作成を自動化するためのAPIで、元々はCloud Foundryで使用されてきました。 Service Catalogはk8sからOpen Service Broker APIを使うための仕組みです。これらがどうのような課題を解決してくれるかをデモ交えて紹介します。k8sで利用するデータベースの作成を手動で行なっている方は必見です。
資料
レポート
- 「アプリケーションで使用するデータベースはどのように作成していますか?」
- k8s か否か、マネージドサービス
 - DevかOpsかAPIか
 - VMかコンテナか
 
 - とある現場
- DevとDBAで何度もやり取り、数日のタイムラグ
 
 
- Service Brokerがある現場だとこんなにもスムーズ
- Service BroakerがDBAの代わりにDB作業をしてくれる
 - APIを叩く
 
 - Service Broaker は Cloud Foundryから来ている考え方
 - Cloud Controller と Service Broker の間の仕様 = Open Service Broker API
- k8s や OpenShift でも動かせるように仕様を策定
 - IBM、RedHat、Google
 
 - 仕様で定められているAPIは7つ
- Catalog ... GET
 - Service Instance ... PUT, DELETE
 - Service Binding ... PUT, DELETE
 
 - Kubernetes Service Catalog
- k8s API server と Service Broker の間(= Cloud Controller に相当)
 - Open Service Broker API と k8s の統合プロジェクト
 - Service Catalog SIG で管理(インキュベータープロジェクト)
 
 - New Resources
- k8s Adminが作成 - ClusterServiceBroker
 - ServiceCatalogが作成 - ClusterServiceClass, ClusterServicePlan
 - Developerが作成 - ServiceInstance, ServiceBinding
 
 - 使い方
- Helm でインストール
 
 - DEMO
 - エコシステム
 - まとめ
- Service Broker = DBなどのバックエンドサービス作成を自動化させるためのAPIサーバ
 - Open Service Broker APIでプラットフォーム非依存で利用可能
 - Service Catalogでk8sとOpen Service Broker APIを連携可能
 - エコシステムを充実させましょう
 - We are hiring! :)
 
 
Kubernetesセキュリティベストプラクティス
スピーカー : Ian Lewis (Google)
Kubernetesクラスターのセキュリティを高めるために、簡単に使える機能をいくつか紹介します。
資料
レポート
- frontendのpodに侵入できれば、そこからトークンを入手してRedis等の中身が見られる
- トークンを利用してAPIサーバを攻撃
 - シークレットなどを取得してさらにサービスを攻撃
 
 - Mitigate 1 & 2: RBAC (Role Based Access Controll)
- ユーザやサービスアカウントへロールを付与
 - GKEではIAMと連携
 
 - Mitigate 2: API Server Firewall
- APIサーバへのアクセスをIPアドレスで制限する
 
 - Mitigate 3: ネットワークポリシー
- DBへのアクセスを必要のあるPodに制限
 - ネットワークプラグインで実装されている(Calico, Weave ...)
 - GKE だと Calico がよく使われている
 
 - Mitigate 1: k8sの設定でいろいろoffにする
runAsUserreadOnlyRootFilesystem: trueallowPrivilegeEscalation: false
 - Mitigate 1: 出来ることにフィルタをかける
- seccomp
seccomp.security.alpha.kubernetes.io/pod: runtime/defaultが普通のアプリにはお勧め
 - AppArmor
 - SELinux
 
 - seccomp
 - Mitigate 2 & 3: kubeletの権限を制限
- GKEだとデフォルトでセキュリティオプションが有効になっている
 
 - istio
- 各コンテナ館の通信の暗号化、証明書自動更新
 - 中央サーバでコントロール
 - 導入はそこまで簡単ではないかも
 
 
Debugging Applications in Kubernetes
スピーカー : Takashi Kusumi (Z Lab)
Kubernetes には kubectl exec や port-forward といった便利なデバッグの仕組みが整っています。この発表では使い慣れたツールを使って Kubernetes 上でデバッグする場合のコツを紹介します。
資料
レポート
- Kubernetesでのデバッグの悩み
- PodやServiceにクラスタ外からアクセス出来ない
 - コンテナにデバッグツールが入っていない
- ツールは欲しいがコンテナサイズは最小にしたい
 
 
 - Kubectlでのデバッグの基本
- run
 - logs
 - exec
 - port-forward
 - cp
 - top
 
 --serviceaccountオプション- ServiceAccountの権限周りのデバッグに便利
 
--overrideオプション- 特定のノードだけスペックが違う時などに上書きする
 - run のオプションで指定できないフィールドも全て設定できる
 
- ホストのdockerソケットをマウントしてやることもできる
- Ian氏「やめてくれ」
 - SSHなくてもホストのroot権限が取れる
 - APIサーバはちゃんと護りましょう
 
 - kubectl logs
- wercker/stern: ⎈ Multi pod and container log tailing for Kubernetes
 - 複数のPodのログをまとめて表示
 
 - PodとLinuxの名前空間
- 別のコンテナの名前空間を使ってコンテナを起動することが出来る
 - The Almighty Pause Container - Ian Lewis
 - デバッグにはNetwork、PIDの共有が便利
 - PID名前空間を共有すればファイルシステムにもアクセス出来る
 
 - デバッグツールが含まれていない場合
- Podにパッケージをインストール -> 一番手軽
 - デバッグ用イメージを作成 -> 開発に便利
 - デバッグ用サイドカーを入れる -> パッケージマネージャがない場合にも便利
 - ducker run で名前空間を共有 -> scratchイメージも対応可能
 
 - contrib/scratch-debugger
- scratchイメージにbusyboxシェルを差し込むスクリプト
 - これするくらいだったら名前空間を(
 
 - 将来はいりそうな便利機能
 - まとめ
- デバッグの基本 - kubectl run|log|exec|port-forward|cp|top
 - デバッグツールが含まれていない場合
- パッケージインストール or 名前空間共有
 
 - kubectl debug に期待
 - We are hiring!
 
 
Docker / Kubernetes のかなりコアなところにまで手を伸ばす、非常に実践的なプレゼンテーションでした。発表の途中で、前登壇者の Ian 氏が「(そんなことをするのは)やめて!(笑)」と声を上げていたのがとても印象的でしたw
LT 大会
LT については簡単に内容の紹介をさせていただきます。
『入門Kubernetes』の紹介
スピーカー : 松浦 隼人
来る 3/22 に O'Reilly 社から発売となる予定の書籍「入門 kubernetes」、翻訳者自らのご紹介でした。単に k8s の紹介だけにとどまらず、コンテナの利便性や必要性から丁寧に解説してあるとのことで、入門には最適の書となっているとのことでした。
なお、原書は内容についての評判は良いものの誤りの多さが指摘されていたとのことで、レビュアーの方々の協力の下、対応する k8s のバージョンを 1.9 に引き上げると共に多数のエラッタもあててある…とのことですw
Pod の優先度と割込みについて(仮)
スピーカー : チェシャ猫(y_taka_23)
k8s には各 Pod を自動的にノードに振り分ける機能がありますが、ノードの稼働効率を上げるために各 Pod に「優先度」を設定することが可能になっています。その優先度を k8s はどう扱うのか、その仕組みと動作が分かりやすく説明されました。
Amazon Elastic Container Service for Kubernetes (EKS)
スピーカー : 岩永 亮介 (AWS)
昨年末に発表された Amazon Elastic Container Service for Kubernetes (EKS) は、現在そのプレビューの申し込みを受け付けている段階です。AWS はどのような位置づけで、どのようなところを目指して開発しているのか、その説明と、実際の動作デモが発表されました。
こちらについては別途レポート記事もご参照ください。
other ingress voyager
スピーカー : Shuji Tachibana (gavinzhm)
Kubernetes では Ingress を使って HTTPS 終端やロードバランシングを行いますが、複数の Ingress を使う上で複雑になる場合は voyager を使うとよい、というプレゼンテーションでした。
Docker for MacでHelmを使おう
スピーカー : Shouta Yoshikai
ローカルの開発環境である Mac でもパッケージマネージャ(Helm)を使う場合のメリットとデメリット、およびその具体的な使用方法についてのプレゼンテーションでした。
所感
コンテナのオーケストレーションツールとしては、市民権を得たどころかデファクトスタンダードになりつつある Kubernetes ですが、本日のミートアップに参加して、とても勢いがある界隈だと感じました。 AWS としても近い将来 EKS が提供開始されるでしょうし、 k8s については引き続き追っていこうと思います。
おまけ
ちなみに会場にはドロイド君もいましたw











