kashinoki38 blog

something like tech blog

トップ > Kubernetes > KubeFest Tokyo 2020参加してきた

KubeFest Tokyo 2020参加してきた

Kubernetes

6/13にKubeFest Tokyo 2020にリモートで参加。
f:id:kashionki38:20200621041036p:plain

興味あったやつを以下様にまとめた。

Kubernetes アップストリーミング

OSS にコントリビュートしたことないので良い機会だった。

https://github.com/kubernetes-sigs/contributor-playground/blob/master/kft-2020/docs/k8s-upstream-training-kft-2020.pdfgithub.com

コミュニティ選び

  • 業務にフィットする形で長期的にコントリビュートするのがよい
  • どの領域にコントリビュートするのか決める必要がある
  • コミュニティ
    • コミュニティの価値
      • 集中よりも分散
      • コミュニティは製品企業を超える
      • 深化は停滞より良い
      • 自動化はプロセスを超える
      • 包括は排他より良い
      • 文化は戦略を食う　 by 　ピータドラッカー
    • グループのタイプ
      • Special Interest Groups(SIGs)→ メイン
      • Working Groups(WGs)→ 特定のゴールやエリアなど
      • User Groups(UGs)
      • Committee
      • f:id:kashionki38:20200621035635p:plain
    • コミュニティを選んで ML やミーティングに参加する
    • コミュニティごとにリポジトリの中の特定のパスに対してオーナーシップを持つようになっている
      • member, reviewer, approvers など権限がわかれており、権限を上げるためには Requirements があり PR で申請する

開発環境要件

  • 8 コア 32GB でも build に 15 分

リリースサイクル

  • 3 ヶ月おきにリリース
  • f:id:kashionki38:20200621035657p:plain

はじめてのコントリビュート

  • 初心者向けラベル
    • good first issue
    • help wanted
  • コードだけでないコントリビューション
    • Issue 登録
      • バグ報告/機能要望
    • ドキュメントの修正
    • 日本語訳の貢献
  • Smaller is better
    • いくつもの修正を PR しすぎるのは良くない
  • PR の Flow
    • f:id:kashionki38:20200621035709p:plain
    • PR をテンプレ使って投げる
    • 同時に Slack の-dev で依頼するのが良いっぽい
    • labels と notes を追加する
    • Bot がバリデーションとコメントをする
      • よくあるラベル
        • release-note
        • cncf-cla:no
        • needs-ok-to-test
        • needs-kind
        • needs-sig
    • label や notes を足してレビューコメント対応
    • SIGs と OWNERS のレビューと承認 →/approveでapprovedラベル付与
    • 他のコントリビューターによる\lgtmでlgtmラベル付与
    • Test 通過
    • Prow の Tide が PR を merge
    • コマンド
  • 比較的使われる英語表現
    • I’m facing the same issue. / 私も同じ問題を経験しています
    • ditto / (既に指摘した部分に続いて、) 同上です
    • nits / 細かい指摘だけど
    • nit: … / 細かい指摘ですが …
    • PTAL (Please take another look) / 見直して下さい
    • WDYT (What do you think?) / どう思いますか？
    • LGTM (Looks good to me) / 大丈夫だと思います。
    • SGTM (Sounds good to me) / いいと思います。
    • SG (Sounds good) / いいと思います。
    • FYI (For your information) / 参考までに
    • ¯_(ツ)_/¯ (shrug) / 肩をすくめる
    • IMHO (In my humble opinion) / つまらない意見ですが、私に言わせていただければ
    • TBH (To Be Honest) / 正直に言うと、はっきり言って

ハンズオン

git remote 設定

https://github.com/kubernetes-sigs/contributor-playground は事前にフォーク済み。

$ git clone https://github.com/kubernetes-sigs/contributor-playground
$ cd contributor-playground
$ git remote add upstream https://github.com/kubernetes-sigs/contributor-playground
$ git remote set-url --push upstream no_push
$ git remote -v
origin  git@github.com:kashinoki38/contributor-playground.git (fetch)
origin  git@github.com:kashinoki38/contributor-playground.git (push)
upstream        https://github.com/kubernetes-sigs/contributor-playground (fetch)
upstream        no_push (push)

ドキュメント追加して push

$ git checkout -b add_kashinoki38_md
Switched to a new branch 'add_kashinoki38_md'
$ vi kashinoki38.md
$ git add .
$ git commit -m "Add kashinoki38.md for kft-2020 workshop"
$ git fetch upstream
From https://github.com/kubernetes-sigs/contributor-playground
 * [new branch]      master     -> upstream/master
$ git rebase upstream/master
$ git push origin add_kashinoki38_md

PR 作成

https://github.com/kubernetes-sigs/contributor-playground/pull/482

f:id:kashionki38:20200621035747p:plain

f:id:kashionki38:20200621035750p:plain

以下のようなテンプレ

<!--  Thanks for sending a pull request!  Here are some tips for you:

1. If this is your first time, please read our contributor guidelines: https://git.k8s.io/community/contributors/guide#your-first-contribution and developer guide https://git.k8s.io/community/contributors/devel/development.md#development-guide
2. Please label this pull request according to what type of issue you are addressing, especially if this is a release targeted pull request. For reference on required PR/issue labels, read here:
https://git.k8s.io/community/contributors/devel/sig-release/release.md#issuepr-kind-label
3. Ensure you have added or ran the appropriate tests for your PR: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
4. If you want *faster* PR reviews, read how: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews
5. Follow the instructions for writing a release note: https://git.k8s.io/community/contributors/guide/release-notes.md
6. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests
-->

**What type of PR is this?**
/kind documentation

**What this PR does / why we need it**:
This adds kashinoki38.md for kft-2020 workshop

**Which issue(s) this PR fixes**:
<!--
*Automatically closes linked issue when PR is merged.
Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`.
_If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`_*
-->
Fixes #

**Special notes for your reviewer**:

**Does this PR introduce a user-facing change?**:
<!--
If no, just write "NONE" in the release-note block below.
If yes, a release note is required:
Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required".
-->
\```release-note
NONE
\```

**Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**:

<!--
This section can be blank if this pull request does not require a release note.
Please use the following format for linking documentation or pass the
section below:
- [KEP]: <link>
- [Usage]: <link>
- [Other doc]: <link>
-->
\```docs

\```

以下のように記載
f:id:kashionki38:20200621035812p:plain

  • kindを入れ忘れない
  • Does this PR introduce a user-facing change?には NONE を入れないとバリデーション通らない

approved されて merge され感動。 f:id:kashionki38:20200621035823p:plain

Best_Practice_as_Code_with_Open_Policy_Agent

speakerdeck.com

  • Open Policy Agent を使ってベストプラクティスのためのルールをコード化する
    • f:id:kashionki38:20200621035838p:plain
    • Rego で書く
  • Gatekeeper がおすすめ
    • policy を template 化して管理することが可能
    • ConfigMap ではなく CRD
    • 現在 deploy されているリソースを参照することができるので、比較可能
  • GitHub Actions で Conftest を使いバリデーションさせることができる

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

speakerdeck.com

github.com

かなり柔軟性高く作られており試してみたいと思う。Prophet さすが。

  • Prophet による予測値に基づきスケーリングさせる Custom Controller
    • HPA への予測エントリの注入
    • 予測ジョブやメトリクスの管理
  • Kubebuilder にて開発

Understanding CPU throttling in Kubernetes

limit と throttling の違いを勉強した。

speakerdeck.com

  • Limit と Throttling は違う
    • http://kennystechtalk.blogspot.com/2015/04/throttling-cpu-usage-with-linux-cgroups.html
      • limit は上限（ある閾値以上で遮断）
      • throttle は流量制御（時間あたりの量を制御することであり、完全に遮断するわけではない）
      • nice と chrt は limit
        • プロセスをスケジュールして使用量に制限をかける
        • スケジューラが許可するだけ CPU をプロセスは使用可能
        • CPU 要求プロセスがない場合 Idle プロセスが CPU100%
      • cpulimit は throttle
        • cpulimit はプロセス開始後に実行する必要があるため、まずプロセスを発見するスクリプトを使用する必要がある
      • cgroups は limit も throttle もできる
        • cgroups は limit のためにデザインされたが、throttle することも可能
        • control groups
        • プロセスを内部で起動したり移動したりするための制御グループを作成する
        • グループの制限はいつでも編集でき、プロセスはいつでも cgroups 間で移動可能
        • cgroupsの仕組み
          • limit
            • cpu.shares
              • デフォルト 1024
              • cgroup 内のすべてのプロセスに各cpu.shares / 合計cpu.shares の割合で CPU を割り当てられる
              • この値を引き下げると limit される
          • throttling
            • cpu.cfs_period_us
              • デフォルト 100,000（マイクロ秒） = 100ms
              • スケジューラがプロセスを計測する期間
              • これ自体はあまり意味を持たない
            • cpu.cfs_quota_us
              • デフォルト -1
              • cpu.cfs_period_usを超えない（マイクロ秒）
              • cgroup内のプロセスが期間(cpu.cfs_period_us）ごとに使用を許可される CPU 時間量（≒ 帯域幅）
            • つまりcpu.cfs_period_us / cpu.cfs_quota_usの割合になるように throttling される
  • Overcommitted State
    • Pod の Scheduling は Requests ベースで実施されるので、Pod の Limit まで NO でリソース内で実行可能の保証はされない →Overcommidtted State
    • CPU は Compressible なので、Requests 以上の分は throttling される
    • f:id:kashionki38:20200621035946p:plain
  • Requests/Limits の cgroups による実装
    • CPU Requests は cpu.shares
    • CPU Limits はcpu.cfs_period_us , cpu.cfs_quota_us
      • f:id:kashionki38:20200621040004p:plain
  • Throttling の確認
  • CPU limits 設定による Throttling
    • CPU lmits を設定し抵触すると、Throttling が発生してしまう
      • f:id:kashionki38:20200621041316p:plain
    • これって Overcommitted State 下における状況でのこと？
    • Throttling を監視して、発生しているようであれば Limit の削除、もしくは AP の CPU 使用量チューニングが増加を検討する

Preparing guardrails for Istio at scale

speakerdeck.com

  • istio メンテ
    • Helm は Istio1.6 から未対応
    • 変更と upgrade のプロセス
      1. istioctl upgrade -f foo.yaml --dry-run
      2. diff の結果を PR（これってistioctl manifest diff?）
      3. review -> approval -> merge
      4. istioclt upgrade -f foo.yaml
      5. 祈る
  • istio 監視
    • 対象と項目
      • Control plane(istiod, istio-pilot)
        • USE
          • CPU
          • Memory
          • Concurrencty
        • RED
          • Config pushes count
          • Config pushes duration
          • Config pushes errors
      • Data plane(Envory proxies)

EKS x Locust で構築する大規模負荷試験環境

speakerdeck.com

この世界観は弊部署としては参考にする必要あり。

  • deployment の replicas 調整で負荷クライアントが自動スケール
    • 1000Pod/10 万 User 超の試験実施可能とのこと
    • 負荷調整は Locust の WebUI
  • 負荷試験シナリオで使う環境変数をシナリオごとに configMap に定義する
    • シナリオファイル
    • ターゲット URL
    • その他パラメータ
    • EnfFrom.ConfigMapRef で環境変数と configMap の紐付け
  • 頻繁編集は ArgoCD から直接編集

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

speakerdeck.com

最近 Kpt の話題を聞いたので。まだ Helm も Kustomize もわかってないのであれだが。

  • manifest 構築ツールとしての Kpt
    • Kptfile と対象 yaml で構成
      • 対象 yaml の置換したい項目にコメントする
        • f:id:kashionki38:20200621040119p:plain
        • f:id:kashionki38:20200621040134p:plain
    • カスタム変換・バリデーションを記述可能
  • Docker 化することで各ステップが配布可能
  • 各ステップをパイプで合成可能

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

speakerdeck.com

早速 krew 入れてみたけど便利すぎ。
コマンドの秘伝のタレを krew で配布するのも良さそう。

f:id:kashionki38:20200621040151p:plain

  • \$PATH 内の kubectl-で始まる名前の実行可能ファイルがプラグインとして認識される
    • E.g. kubectl-foo ファイルを kubectl foo で実行できる
  • krew
    • 利用方法
    • おすすめプラグイン
      • kubectl ctx：コンテキストを簡単に切り替え
      • kubectl ns：Namespace を簡単に切り替え
      • kubectl iexec：インタラクティブな kubectl exec
      • kubectl status：リソースのステータスをわかりやすく表示
      • kubectl neat：manifest から冗長な情報を削除して表示
      • kubectl view-secret：Secret を Base64 デコードして表示
      • kubectl images：Pod が使用しているコンテナイメージの一覧表示
      • kubectl rolesum：指定した Subject の RBAC ロールをサマリー表示
      • kubectl open-svc：ClusterIP な Service にクラスタ外から簡単にアクセス
      • kubectl tree：ownerReference ベースでリソースをツリー表示
    • 紹介できなかったプラグイン、の中で使いたいやつ
      • kubectl get-all：kubectl get all で表示できないものも含んだリソース一覧を表示
      • kubectl resource-capacity：リソースごとに Resource Request/Limit を一覧表示

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

speakerdeck.com

今やってる Sock-shop の次に触ってみたい。