KubeCon NA 2019 個人的に面白かったセッションまとめ

KubeConで(自分が)面白かったと思ったセッションまとめ
※網羅しているわけではなくて抜粋

## Multi Cluster / 巨大クラスタ / スケーリング系 / オートメーション

### [Handling Risky Business: Cluster Upgrades](https://static.sched.com/hosted_files/kccncna19/a0/Handling%20Cluster%20Upgrades%20-%20K8srotator.pdf)

LyftのK8sクラスタのバージョン自動更新の仕組みの話
TriggerベースのOperatorをGoで書いていて、Rotateモード(バージョンアップを実行)・Freezeモード(バージョンアップを停止)の2種類をベースにしている
基本は自動実行、問題があればFreezeモードで手動対応といった形で対応する
Rotateの方法は、新しいNodeを立てて古いNodeを削除する(Nodeの)RollingUpdate

### [Scaling Kubernetes to Thousands of Nodes Across Multiple Clusters](https://static.sched.com/hosted_files/kccncna19/46/KubeCon%202019%20Scaling%20Kubernetes%20to%20Thousands%20of%20Nodes.pdf)

Airbnbで、ビジネスが成長するにつれてNodeが450台 → 900台 → 1800台 → 2400台とK8sクラスタが肥大化していってMulti Clusterに分割した
Multi Clusterを作るにあたって、Cluster Typeを定義して、そのインスタンスとしてClusterを払い出している
裏側はChefやTerraform, Helmなど様々な技術を組み合わせている
現在は22Cluster Type, 36Cluster, 7000+Nodeの規模

### [Rethinking the K8s DNS for the Modern Enterprise](https://static.sched.com/hosted_files/kccncna19/97/Rethinking%20the%20K8s%20DNS%20for%20the%20Modern%20Enterprise.pdf)

Multi Cloud, Multi Clusterを考える上で重要になるのがDNS
DNSを露出して、Cluster間でService Discoveryできる仕組みを作る必要がある
ただ、Kuberntes DNSではCluster Resourceで隔離できない・動的設定変更できない・Secure Queryに対応できていない、といった課題もある
この発表ではEnvoyをDNS Layerの前にProxyとして置くことでその課題を解決することを提案している

### [eBay Search On K8s](https://static.sched.com/hosted_files/kccncna19/2a/ebay-search-on-k8s.pdf)

現在の規模は60+Cluster, 2,000+Node, 160,000+Podと凄まじい規模
PVCも活用していて、StatefulなWorkloadも多く動いていて、その点を工夫している
例えば、検索サービス用に、Matrix deploymentというStatefulSetを払い出すCRDを用意している模様

### [Tinder’s Kubernetes Move](https://static.sched.com/hosted_files/kccncna19/1e/Tinder_KubeCon_2019.pdf)

現在の規模は、~2000Node, 6Control Plane Master, 25,000~30,000Podとこれも凄まじい規模
レガシー時のEC2 AutoScaling GroupからMicro Service + Kubernetesに移行していった
大規模特有の問題として、ARP・DNS・LoadBalancingで出た問題を共有している

### [To Infinite Scale and Beyond: Operating Kubernetes Past the Steady State](https://static.sched.com/hosted_files/kccncna19/ce/%5BKubeCon%20San%20Diego%202019%5D%20To%20Infinite%20Scale%20and%20Beyond_%20Operating%20Kubernetes%20Past%20the%20Steady%20State.pdf)

タイトルにもあるように、無限のスケーリングのためには何が必要か、を考えるセッション
・クラスタの自動更新
・Multi Clusterのデプロイ管理
を主軸に深掘りしている

障害を想定しろ！
障害は起きる
一つのクラスタは(もはや)Single Point of Failure!
といった内容もあって、そうしたMulti Clusterが当たり前になる時代になっていくのかもしれない、と少し思った

### [A Toolkit for Simulating Kubernetes Scheduling at Scale](https://static.sched.com/hosted_files/kccncna19/97/KubeCon_JoySim.pdf)

JD.comが、デプロイ時の影響確認用にシミュレーター(JoySim)を開発した話
巨大K8sクラスタのスケーリングやパフォーマンスの推定に利用している

## Service Mesh系

### [Life Outside the Cluster: Adding Virtual Machines to an Envoy Service Mesh](https://static.sched.com/hosted_files/kccncna19/2d/Life%20Outside%20the%20Cluster%20%20-%20Kubecon%20NA%20%2719.pdf)

VMにIstioを入れるユースケースを説明
KubernetesクラスタとVM環境との繋ぎこみをケースに説明している
レガシー環境に、ServiceMeshを入れて、ServiceDiscoveryの恩恵を得たい、といったケースにあっているかもしれない

### [How Spotify Migrated HTTP Ingress System to Envoy](https://static.sched.com/hosted_files/kccncna19/83/EnvoySpotifyPerimeter.pdf)

SpotifyでNginx + HAProxyなどの古いアーキテクチャからEnvoyへ移行した話
古いアーキテクチャでService Discoveryや運用コストの悩みから移行した
ServiceMeshで、Envoyを古い環境に入れたいときに参考になるかもしれない(可能ならMigrationに直面する場面を減らせとも言ってるが)

### [Stitching a Service Mesh Across Hundreds of Discrete Networks](https://static.sched.com/hosted_files/kccncna19/4e/admiral-v3-KUBECON2019.pdf)

160Cluster, 6,600Node, 62,000Podの規模で、ServiceMeshを組み込んだ話
ServiceMeshの構築で、Shard Control Plane → Multiple Control Plane → Multiple + Admiral(自作OSS)といった統合を進めていった
Cluster LayerでServiceMeshを実現できた、という非常に勇気をもらえる内容だった

## Stateful Application

### [Running Large-Scale Stateful Workloads On Kubernetes at Lyft](https://static.sched.com/hosted_files/kccncna19/24/Stateful-workloads-lyft-kubecon.pdf)

LyftでのStateful workloadのためのプラットフォームを構築した話
FlyteというML&Data用のオーケーストレータを簡単にする
Operatorも統合している

## CNCFプロジェクト系

### [Evolving the Kubernetes Ingress APIs to GA and Beyond](https://static.sched.com/hosted_files/kccncna19/a5/Kubecon%20San%20Diego%202019%20-%20Evolving%20the%20Kubernetes%20Ingress%20APIs%20to%20GA%20and%20Beyond%20%5BPUBLIC%5D.pdf)

IngressのGA(v1)とその次のAPI構想(v2)についての発表
v1: IngressClass, backend → defaultBackend, PathTypeなど
v2: GatewayClass, Gateway, Route, ServiceにAPI Resourceを分割(未定)

### [Helm 3 Deep Dive](https://static.sched.com/hosted_files/kccncna19/ec/helm3-deep-dive.pdf)

Helm3のアーキテクチャの変更、移行などについて全て説明
Helm３はHelm2からアーキテクチャ・インフラ部分の変更のみなので、Helm2と共存可能
Helm2 → Helm3に移行するPluginも提供されている

### [CoreDNS Deep Dive](https://static.sched.com/hosted_files/kccncna19/b1/CoreDNS%20Deep%20Dive%20KubeCon%20NA%202019.pdf)

Pluginの設定がメイン
個人的には「onlyone」Pluginが気になる

### [CoreDNS: Beyond the Basics](https://static.sched.com/hosted_files/kccncna19/45/CoreDNS%20Beyond%20the%20Basics%20KubeCon%20NA%202019.pdf)

応用編として、DNSSECやDNS Over TLSなどについて説明。他にもトリッキーなテクニックを紹介
全く知らなかったが、MultiCluster Service DiscoveryでCoreDNS公式でリポジトリもあるらしい
https://github.com/coredns/multicluster-dns

## その他

### [The Gotchas of Zero-Downtime Traffic /w Kubernetes](https://static.sched.com/hosted_files/kccncna19/f7/The%20Gotchas%20of%20Zero-Downtime%20Traffic.pdf)

zero-downtimeで(Web)サービスを更新するために必要な物をまとめている

1. entrypointはシグナルをハンドルすべき
2. STOPSIGNALが必要になるかもしれない
3. Liveness / Readiness Probeは異なる間隔を設定する
4. 接続を受け付けないように、preStopではSleepを入れる
5. apps/v1 Deploymentを使う
6. RollingUpdateの間にウォームアップを行う
7. SideCarのシャットダウンを同期させる

### [Understanding and Troubleshooting the eBPF Datapath in Cilium](https://static.sched.com/hosted_files/kccncna19/20/eBPF%20and%20the%20Cilium%20Datapath.pdf)

eBPFとCilium(CNI)の説明