Day1
自分用参加・聴講メモ
※Keynoteは省略
Kubernetes at Cruise: Two Years of Multitenancy
資料公開なし
Cruiseは自動運転の会社
Cluster: 12-26
64or32vCPUで1,000node
(セッション情報では100,000Pod, 4000Nodeとあったけど、間違ってそう...)
Multitenancyは論理的に隔離されているが、物理的には統合されている
CruiseはK8sのNamespaceで論理的に隔離している
クラスタ数を少なくすることで、Costを減らす狙いがあった
秘密情報の管理にVaultを使っている
ClientであるDAYTONAをinitContainerで使っている
また、k-railという、Cruiseで作ったOSSでWorkloadのPolicyを管理している
Team単位でNamespaceを切っている
Google Groups for GKEでのRBACでもPermission Layerでの隔離を実現している
isopodも自作のOSSでYAMLなしで、DSLで設定が書ける
Junoというインフラ管理ツールでGCP Project, Vault Namespace, K8sNamespaceなどをUIで管理している
※Junoは非公開
Networkは、NATGateway, Ingress/Egress QPS, Bandwidthを工夫
Firewallは、Network PolicyやIstioの機能などを活用して、Virtual Firewallで隔離
Shard Ingressとして、VMでNginx Ingressを立てている
Shared DNSとして、Node Local DNSやNode PoolごとのDNSを立てている
Shared Observabilityとして、Log, Metrics, Tracing, Dashboardを工夫
感想
巨大クラスタの運用について、話が聞けるかと思って受講したが、内容はMultitenancyでの論理的な隔離性を様々な観点(Namespace, Secret, Permission, Policy, RBAC, Network, etc...)で担保している、という内容が主軸だった
そのため(自分が)望んでいた内容ではなかったが、Multitenancyで考慮しなければならない観点については充分学べたと思う
Rethinking the K8s DNS for the Modern Enterprise
※どうやら発表用の資料と公開用の資料が違う模様。詳しく知りたい場合はYoutubeの方が良さそう
Multiple ClusterやMultiple Cloudになると、DNSによるService Discoveryが重要になる
DNSにはObservabilityとSecurityが求められる
- TenantごとのTelemetry
- (DoT/DoHで)DNSのQureyのEncryotion
K8sのDNS(kube-dns)はTenantごとの隔離性がなく、動的設定変更ができず、Secureでもない
DNS ObservabilityとSecurity用にServiceMonitorというCRDを使う
またDNS Filtering用のCRDを使って、EnvoyをProxy(代理人パターン)として、Proxy LayerでFilteringを行う
DNS Filterを使うことで、DNSとProxy間はTLS通信ができ、ProxyのFilterChainでDNS QueryのFilteringもできる
感想
Multi Clusterに関わると、DNSの問題は避けられず、CoreDNSを起点にしてソリューションを考える必要がどうしても出てくる
EnvoyをProxyとして、Observability/Securityを満たす、という観点は非常に面白かった
おそらくMulti Clusterでのベストプラクティスになる気がしている
Managing Helm Deployments with Gitops at CERN
物理マシンの話から始まり、Cloud → Containerにメリットを感じて利用している
Docker, Kubernetes, エコシステムの学習コストがある中、マニフェストの管理としてHelmを利用している
Chart RepositoryとしてS3にChartを保管している
S3をバックエンドとして、ChartMuseumを利用している
Secret管理
CIと統合して、Git pushするとHelm lintとHelm testが走る
CDにはFluxを使ったGitOpsを実践している
Flux + Helm CRD + Helm Operator
HelmのRelease(Helm上の、Chartのデプロイの単位)をFluxのCR YAMLとして宣言的にK8sにApplyする
一つのHelm Releaseで全てのAddons(Prometheus, 他)を管理している
次のステップとしては、Helm v3やChartの保守の自動化、Service Meshを利用した高度なDeployなど
感想
仕事でもHelmを利用しているので、使っているツールやツールの使い方はある程度想像できたが、CIでの活用で、Helm lintやHelm testをきちんと行なっているのには思っている以上にしっかりやっていて好感がもてた(自分のところはできていない)
また、Fluxも名前は知っていたもののHelm ReleaseをCustom Resourceとして宣言できることは知らなかった。
FluxでHelm ReleaseをSingle Source of Truthとして宣言的にまとめて、GitOpsでCDできることの柔軟性にも魅力を感じた
Admission Webhooks: Configuration and Debugging Best Practices
Admission WebhookはKubernetesの拡張方法の一つ
簡単にいうと、API ServerがRequestを処理している間に、任意の処理を挟むことができる
Admission Controlには、Mutating(変更フェーズ)・Validating(検証フェーズ)の二つがある
Kubernetesに提供されているAdmission ControlとしてはResouceQuotaがある
Admission Webhookという形で、APIのRequeustを処理する途中に、任意のWebserverにhookさせることができる
Best Practice
1.(Admission Webhookの結果に)冪等性を保つ
Mutating Webhookがなぜ2回呼ばれるか？
→順番を保つのが難しいから。順番によって結果が違ってくる
Reinvocation policyで制御できる
2.オブジェクトの全バージョンをインタセプトする
例えばDeployment Resourceで、extension/beta, apps/beta, apps/v1などのバージョン互換性を保つ
MatchPolicyを設定する
3.Availability
Admission Webhookは、APIのRequestをWebhook Serverに飛ばしてから(Webhook Serverでの)処理が始まるため、API Latencyが長くなりやすい
Timeoutが設定できるので、それでLatencyが遅くなりすぎないようにする
4.オブジェクトの最後の状態を保証する
Mutation Webhookを使うのであれば、Validation Webhookで結果を保証するようにする
5.Side Effect
- 副作用はなるべく避ける
- Reconcile Mechanismを目指す
- sideEffectフィールドを設定して、副作用を避ける
6.kube-systemのNamespaceでのオペレーションを避ける
System Critical(kube-system)を安全のために避ける
Namespaceが存在している場合、Namespace ScopeでだけWebhookを飛ばすことができるように設定できるので、設定する
Debug編
・Webhookが失敗・拒否された時は400か500のステータスが返るが、理由は多岐にわたる
failurePolicy:Ignoreを使うと、Timeout/Connection/Malformed Errorが起きた時に無視できる
・response・Metricsを収集する
・何がどこでどのように起きたかを確かめたい時は、Audit Logを設定する
mutation.webhook.admission.k8s.io/round_{}index{}
patch.webhook.admission.k8s.io/round_{}index{}
e.g. mutation.webhook.admission.k8s.io/round_0_index_1のような形式でAudit Eventを記録する
Requestごとにindexがインクリメントされる
結論
・BestPracticeに従って、Admission Webhookを設定する
・MetricsとAudit Logを使って、Monitoring, Tracingできるようにする
感想
Admission WebhookのBest Practiceについて非常に参考になった
最近Webhook Serverを書いているが、知らなかったこと・やったほうが良いができていないことに気づけたのは良い収穫だった
Scaling Kubernetes to Thousands of Nodes Across Multiple Clusters
AirbnbでのMultiple ClusterへとScaleしたお話
(Clusterの)Nodeが450台からスタート
→ "Multiple Clusterを考え始めよう"
KubernetesのSLOとして、Nodeの上限は5000台まで
実際に動かせるとしたら2500台ほど
Alibabaは10,000Nodeを動かしたBlog postがあって、素晴らしい仕事をした
450台 → 900台 → 1800台とNodeがどんどん増えていき、etcdがOOMKillされた
"etcdがOOMKillされたらまずいよね？"
とうとう2400台(限界)まで来て、Multile Clusterへ
Multiple Clusterにすることで
・Workloadをどのクラスタでもランダムにアサインできる
・Clusterはマシンとメモリの単なる集まり
・Service(Discovery)が作られると、どのクラスタにするか設定で選ぶことができる
AirbnbのService Meshフレームワーク「SmartStack」だと、Type: NodePortでServiceを払い出して、Node LevelのIPを指定する
VPC CNIを使うと、NodeのIPではなく、PodのIPでCluster間を直接Pod to Podで通信できる
どうClusterを管理しているか
Clusterを他のWorkload(Pod, Service)のように扱う
Clusterに必要な要素を一つのユニットとしてデプロイする
具体的にはComponentをHelm Chartとして書き、umbrella chartとして扱う
自作のフレームワーク(kube-gen)でアプリケーションをデプロイする
裏側ではChef, terraformも使っている
10分未満でデプロイできる
Cluster Typeという、オブジェクト指向でいうClassを用意し、ClusterをInstanceとしてデプロイする
変化との向き合い方
→ 変化を簡単にすると、より変化が起きやすくなる
変えるのが簡単なもの(新規クラスタ, アップグレード, IAM追加)もあれば、全然簡単ではないもの(Network, Certificate,etc)もある
現在も仕掛かり中とのことだが、すごい規模だ...
・22 Cluster Type
・36 Cluster
・7000+ Nodes
感想
ある程度以上(1000台以上)にClusterのサイズが育っていくと、取るべき方法はだいたい二極化しているように感じる
1. Masterを強化, 改造する(ebay, alibabaなど)
2. Multiple Clusterにする(今回のAirbnb)
今回は2のMulti Clusterの話だったが、非常に参考になる話だった(仕事でもペインポイント)
Multi ClusterになるとOperation Costの関係で、当然一個一個のClusterを盆栽を育てるように大切に育てていける訳ではないため、どうしても自動化にモチベーションが向かっていく
日本ではたとえばZLabさんやサイボウズさんのクラスタ自動構築・運用の仕組みが有名だが、一つの巨大なサービスを支えるCluster(Multi Cluster)の自動化というのは初めて聞けたので非常に興味深かった
Cluster越しにPod間で通信する仕組みは、(毎回LoadBalancer立てるわけにもいかないと思うし)Multi Clusterでは必須になると思う
Cluster TypeとInstanceとしてのCluster、という考え方も汎用性が高そうで面白い仕組みだと思った
以下は推測だが、
VM Layer -< Chef, Terraform
K8s(Master) Layer -< Helm(umbrella chart)
Application Layer -< kube-gen
という対応関係でCluster(とWorkload)をデプロイしていると思うが、慣れ親しんでいるツールで実現可能性が高そうなのも良い
(たとえばこれを全部CRD+CustomControllerでやるとなると、作るのと保守にコストがかかることが想像できる)
問題があるとしたら、そうしたCluster構築・デプロイツールを各社が実装しないと実際問題使い物にならない、というところだろうか
Multiple Clusterの必要性自体はまだまだ少数派だと思うが、これから、よりエコシステムが育ってほしい
(個人的には、SIG Multiclusterに期待している)