6/14(水）に開かれた上記カンファレンスの夜のイベントとして、Google Cloud Community fesが開催されたので参加してきた。
www.meetup.com
Google Cloud Community fesはGoogle系の技術を扱うコミュニティが集まって様々なセッションが行われていた。 GCPUGでのパネルディスカッションやbq SushiでBigQueryの開発者の方を読んで話を聞くなど様々あったが ひたすらkubernetes部屋にいた。 セッション内容は以下の通り
An Introduction to Kubernetes
An introduction to Kubernetes // Speaker Deck
Kubernetesの基本的なところからおさらいすることができてよかった。 PodやLabelsの概念はわかるんだけど etcdやapiserver周りはそこまで見れてなかったから参考になった。 以下メモを箇条書き
概念的な
- kubernetesはよくk8sと略されるけど uberneteが8文字だから
- 米国ではよくk-eightsと呼ばれているらしい
- PrometeusというKubernetesのメトリクスを収集するのがある。
- KubernetesはPortablityで自分で立てることができるし、RuntimeもDockerだけじゃない
- HybridなCloud Kubernetesも組める。GLBとかで受けて様々なクラウドに流すのもあり
- Kubernetes Cluster Federationで複数k8s Clusterを仮想的に1つに見せられる。
kubernetes は成長している
- Kubernetes, Apache Mesos Docker Swarm
アーキテクチャ
- MasterとNodeの2つの役割がある
- Masterのetcd : kubernetesの全ての状態を保存する。 分散型kvs.zookeperの類似品みたいな
- watchしといて更新されたら対象コンポーネントに通知が飛ぶ
- apiserver
- REST/認証/認可
- 唯一etcdに書き込む。
- validation(specがあってるか)
- Scheduler : Podのスケジューリング。スケジューリングされていなPODを特定のNodeにスケジュールする。
- Controller Manager : ビジネスロジックを司る。 ある特定のリソースを作ったときに他のリソースを作るかの判断を行う。
- kuberlet(キューブレット) : apiserverを常にwatchしている。 自分のNodeに割り当てられたコンテナがあるかを調べて割り当てられたらImageのPullとかする。
コアコンセプト
-
- デプロイの最小単位
- 複数のコンテナと複数のボリューム
- IP-per-pod
Labels
- Key valueのデータ 唯一グルーピングする。ラベルセレクタ
Replica sets
- N個のPodが実行されている状態を保つ
- Services
- 仮想IPとポート - L4LBにあたるもの - ラベルセレクタによるPodのグルーピング - サービスが負荷分散してくれる。 ClusterIP -> 内部の仮想IP , External-LB - PersistentVolumes
- PersistentVolumes ストレージを払い出して
- PersistentVOlumeClaims それを要求する
- GKEであればPesistentDisk
- その他のリソースがある
作りたい
- apiserverに作りたいです って命令 2.認証認可する 3.パスしたら etcdに対して作成するpodの情報をKVSを書く 4.ユーザには200返す
- SchedulerがUnScheduleのPodを監視する。Nodeの状態見ていい感じに配置する。配置したNodeの情報をapiserverで受けてetcdに書き込む
kubeletが自分の中で動いているか確認して、イメージ立ち上げたりコンテナ立ち上げたりする。 7.ステータスは apiserverを経由してetcdに書き込む
sternという便利ツールある
- kubernetes : up and Runnning とう言う洋書がいい。なおkubernetesは進化し続けるから和書はでないと思われる（翻訳しているタイミングでバージョン上がってしまう)
kubectlずっとクベコントロールで読んでたわ #k8sjp
— y.takky (@y_takky2014) 2017年6月14日
実際は"キューブコントロール"って読むみたい。
Understanding SRE
GoogleでSREやっている Paul Newson (@newsons_nybbles) | Twitter が発表してくれた。 スライドはGoogle翻訳したものらしい。 あと同時翻訳なんてあるわけないので、頑張って英語を聞いていた。
google内のjobローテーションでSREチームに所属してた。
開発やデプロイ、サポートまでは分割していて開発者だったりQAだったりインフラだったりサポートチームだったりするけどそうじゃない。エンジニアリングってのはすべてをやることだよ。
SREは buildingやScaleじゃなくてテストとかそのへんまで関わってくよ
大体のチームではOperation TeamはコードをBuildしないし、その逆だけどGoogleはその辺ちゃんとやる。
サービスがスケールするたびに自動化やコーダが必要になってくる。
SREは多くの方法とは異なる。
GoogleにおいてもSREはレアで面白い仕事でキャリアの成長やメンターになる
On-call
- Two Location
- 8時間の時差
- 最低6人で最大12時間シフト
- 1シフトで2コールまで
拠点が2つあることによってOncallが大体ビジネスタイムになるから、他のSREチームはゆっくり寝れる #k8sjp
— y.takky (@y_takky2014) 2017年6月14日
まあこれは大事だけどほぼ日本でだけやってる会社はちょっとつらいよね。 それこそSRE的な人を日勤夜勤でローテーションさせるしかない
— y.takky (@y_takky2014) 2017年6月14日
LT
LTあたりからバッテリーがもうダメでそんなにメモは取っていない。
10分でわかる「kube-aws]
#k8sjp Google Cloud Nextのあとのコミュニティイベントで AWS使ってる人ーって聞くのわりとシュール
— y.takky (@y_takky2014) 2017年6月14日
アプリのVersionごとにURLを自動生成 on GKE
- アプリをデプロイしたらデプロイしたversionのURLがつくといいなー。
- gitにtagをつけてpushするだけ
- ingressのrulesでこっちのURLに来たらこっちのsvc使うとかできる。
- container builder でdeployもできる。
Container Builderに関してはかなり参考になった。
Prometheus による Kubernetes モニタリングの基礎
Prometheus による Kubernetes モニタリングの基礎 / Kubernetes monitoring with Prometheus // Speaker Deck - CNCFのコンポーネントの1つ - Service Discovery - PrometeusはPodとしてデプロイするのがいい - Prometeusが定期的に監視してくれる - Prometeusの集約・監視もできる(Federation) - Grafanaで可視化できる - kubestatemetricsとかでkubernetes自体の監視もできる
アプリケーションの監視
- prometeus形式のエンドポイントを実装
- Serviceにアノテーション追加するだけ
Kubernetes1.6
- SLOがある。
- 5000Node , 150000podまで対応した
- etcdのパフォーマンスを上げた
- httpでなく protocolbufferで内部のやり取りはするようにした
- RBAC Support
- Roleベースのアクセスコントロール
- PrivateのDNS ZOneが使えるようになった
- DNS ServerをCLusterの中で使えるようになった
流石に150,000pod立てるようなアプリケーション運用はしないから恩恵は得られないだろうけど、 etcdのパフォーマンスが上がったっていうのはじみに良い気がする。
まとめ
昼のGoogle Cloud Nextはどちらかというと万人向けで基本的なところから始まったけどコミュニティイベントはかなりディープな感じでよかった。 かなり勉強になりました。
運営の皆様ありがとうございました。
あとみんなコミュニティ入ろう。
