20200613 KubeFest Tokyo 2020 メモ

Qrunchからの移行（ログ） Kubernetes

KubeFest Tokyo 2020

セッションより

10:30 - Open Policy Agent を使ってベスト・プラクティスをコード化しよう

  • 資料
  • KaaS の方(サイバーエージェント)
  • ナレッジ as Code
    • インフラのIaCはほぼ完成の領域。。
    • 知識をコード化していくべき
    • Knowledge as Code (まだ一般邸では無い)
    • Best Practice as Code (ゴロが悪い)
    • ベストプラクティスのコード化
      • クラウドネイティブなチームでは欠かせない
      • スケーラブルで回復性のあるチーム
      • メンバ間はいい意味で疎結合(新しい人が入る、出ていく人がいる、動くが早い)
    • 継続していくこと、できるところから初めて行く
      • 身近なものから -> k8s
      • マニフェストが手元にあるはず -> ベストプラクティスへ
      • 本番運用に耐えるように、、セキュリティ、、
      • ルールをコード化したい
  • Open Policy Agent
    • マニフェストをルールでチェックする
    • Rego でルール化できる！
    • Admission Controller で組み込む
    • ルールはConfigMap に書く
    • 現在は、Gatekeeper を使う方法をオススメ
      • ポリシーをテンプレート化できる
      • CRD で管理されるようになる
  • GitOps/Conftest/Gatekeeper
  • 利用者に対してRego 使えるようにしたい
    • マニフェストのベストプラクティスを集めて、広げていきたい
    • Rego でナレッジをコード化したい

感想、他

11:20 - Kubernetesトラブル原因特定容易化に向けたロギング強化機能

  • 富士通の方
  • k8s では４種類のログ
  • コンポーネントログは、次の段階
  • ロギングの課題
    • 複数のコンポーネントをまたがった確認が必要
    • Desired にしたがって動くことがログの紐付けが難しくなっている
  • 課題に対して、リクエストIDと言う仕組みを組み込もうとしている
    • コミュニティでの開発状況は、Provisional(設計段階)

感想、他

12:10 - 監視の基礎から知る、ヤフーの大量クラスタ監視システムの仕組み

  • ヤフーのKaaS
  • クラスタは日々増加
    • 2020/5 680+クラスタ
    • チーム：210
    • node：13,000
    • Pod：120,000
    • 運用チーム：20名くらい
  • 運用自動化
    • CIOps/GitOps
    • KaaS でインフラ構築の自動化
  • クラスタ監視
    • アプリの一部までKaaSチーム（SRE）で監視
    • Prometheus 利用(Blackbox_exporter)
    • 大量クラスタの監視
      • 集約システム化（Manager of Manager）
    • 集約データ
      • データ量が多くなるのでアラートメトリックスのみ収集

感想、他

12:55 - Kubernetes とオープンソース

  • サイボウズ
  • OSS の選定
    • 実績重視
  • OSS 開発のメリット
    • 品質よくなる
    • 過度な自社環境避けられる
    • 技術力のアピール
  • インフラのテストとアプリのテスト
    • 具体的な不具合の例
  • OSS推進室
    • 素晴らしく機能している（まさに推進室）

13:40 - 負荷を予測して事前スケーリングする HPA の Custom Controller 実装

  • サイバーエージェント
  • 資料
  • Horaizonatal Pod Autoscaler
    • 実測値をもとにスケールしていく
    • 負荷が上がらないとレプリカ数は増えない
    • 許容負荷ギリギリに設定すると間に合わない　→　余裕を持たせる　≒　リソースの無駄遣い
    • Cluster Autoscaler
  • 複数メトリックスの監視
    • 最大レプリカ数が選択される
  • IHPA
  • kubebuilder
  • Predictive HPA
    • 新しいのが出てきた

感想、他

  • こんな感じで、機能のオーバーライドができるのか

14:30 - Kubernetesクラスタのマルチテナンシーベストプラクティス

  • サイボウズ
  • 資料
  • 1,000大規模サーバにk8s 基盤構築
  • k8s 標準機能だけではマルチナンシーは不十分
    • Working-G ができている
  • ハードマルチテナンシは現状実現難しい
  • マルチクラスターの方がいいのではないか (KaaS/ヤフーさんの事例)
  • SSO でアカウント管理
    • k8s, kubectl, ArgoCD, Grafana
    • Teleport と言うツール利用
  • ネットワークポリシー
    • Calico
  • PSP
  • カスタムポリシー
  • 各コンポーネントの定期更新
  • アプリの開発効率化
    • 共通サービスをインフラチームが開発している
    • 開発者はCRDを使うだけでいい
    • モニタリング、ログ基盤の強化（まだまだ弱い）
  • 迅速なデプロイ

感想、他

15:35 - Open Policy AgentとSpinnakerで実現するマイクロサービスの安全な継続的デリバリー

  • メルペイ
  • 資料
  • CI
  • CD
    • Sponnaker でデプロイ
  • 課題
    • 自律的に開発サイクルを回したい
      • 記述としては間違っていないが、k8s マニフェストの設定の質がチェックできない（ルールにそぐわない）
      • デプロイの仕方がチームごとに異なる
      • サービス全体と、Devの進め方で相性が悪い
    • Spinneker Pipeline で設定ミス
  • ルール違反をチェックする仕組み
  • Spinnaker Managed Pipeline
    • Pipeline as Code / Devは何もする必要はない

感想、他

  • 安全なCI/CD の最新の事例を知ることができた

16:25 - Understanding CPU throttling in Kubernetes to improve application performance

  • 資料
  • Limit とthrottling　は違う
  • CPU Limits はいらないのではないか

感想、他

  • この資料でリソース配分の仕組みがよくわかる(はず)
    • 今後、何かあった際に参考する(Bookmark)

LT

[LT] GitOps環境におけるremote clusterでの開発

[LT] 手間をかけずにサービス監視する方法

[LT] EKS x locustで構築する大規模負荷試験環境

[LT] KubernetesにおけるCIについて

[LT] Kpt を使って組み換え可能な Manifest Pipeline を作ろう！

[LT] kubectl のプラグイン機構を活用してオペレーションを効率化しよう

[LT] Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する

[LT] gVisorを活用して実現するこれからのコンテナセキュリティ

[LT] Re: Kubernetes-native テストベッドで始めるベストプラクティス模索

今回得られた知見

YouTube 公開後、聴講したものから

ヤフー/ゼットラボのステートフルアプリケーションへの挑戦

  • 資料
  • CaaS を開発し、Yahooが利用
    • マネージドKaaSを提供　２つのリージョンで可動
    • 利用者のk8s をk8s で管理。
    • クラスタ(VM)のスケーリングをOpenStack で実現
    • 独自のAddon-manager でGrafanaやPrometheus のアプリを提供
    • ステートフルへのチャレンジ中
  • Yahoo で利用
    • 広告配信システム
      • リクエストに応じて最適な広告を返却
      • 高速なレスポンスが要求される
      • Vespa(OSSの検索エンジン)
      • 24:30 監視システムへの設定変更の説明あり
    • 26:00 ごろシステム運用の説明あり

感想、他

  • ノードの作り直しを日々実施しできている（慌てない）
  • マシンリソースをうまく使い切れていないと言うとことをCaaS で解決

Resilience Engineering on Kubernetes ～ワンターレンの夜明け～

  • 資料
  • セルフヒーリング
    • 自身の回復機能はない
  • カオスエンジニアリング
    • 仮説を立てて、障害を起こす
    • 構造をしっかり理解した上で検証する必要がある
    • 守る対象から逃げない
  • STPA
    • ここが正常でも組み合わせで障害となることがある
  • Infrastructure as Data

感想、他

VMとAWS ECSがメインのインフラにKubernetesを導入した効能

  • サイバーエージェント
  • 既存との並行運用
    • 既存との共存
    • service mesh はコストがかかると判断
  • 開発環境と本番環境 の紹介
    • 11:45 ごろ
    • インフラ：Terraform
    • マニフェスト管理：Kustomize
    • CI：AWS CodeBuild
    • CD：ArgoCD
  • 受けられる恩恵 (16:56)
    • Devはインフラを意識することなく開発可能
    • CI/CDをほぼ自動化
    • 開発環境に何がデプロイされているのか分かるようになった
  • 問題
    • SRE チームで分担して担当した