Masaya Aoyama CyberAgent Kubernetes ͱ࿈ܞ͢Δ ΞϓϦέʔγϣϯ։ൃख๏ @OpenShift.Run Summer #10 @amsy810

- Co-chair Masaya Aoyama + CREATIONLINE / DENSO - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810

本⽇の Goal Kubernetes との連携の仕⽅の パターンを探る ⼩さなところから初めてみる

ページの都合上、⼀部 YAML の記法が擬似コード的になっているため注意してください。 /PUF

GPU as a Service

各ユーザが GPU コンテナを利⽤できる仕組み Web UI や CLI からも Kubernetes を 隠蔽した形で操作可能 Jupyter notebook の払い出し等 更にこの上に ML 関連の Platform が展開 (16BTB4FSWJDF1MBUGPSN Container Computing resource pool Storage pool icons: https://icons8.jp/icons/set/video-card

• ユーザに払い出されるリソースは Namespace を使って分割 • RBAC を使った権限が管理 (16BTB4FSWJDF1MBUGPSN User A namespace User B namespace icons: https://icons8.jp/icons/set/video-card

ConfigMap / Secret as simple data store

ある程度のデータは Kubernetes を簡易的な DB として利⽤ • ユーザーが定義したテンプレート • ユーザが登録した利⽤イメージ • etc 変更が少なく、ユーザに容易に操作させるようなデータで利⽤（cf. Configuration as Code） 各 Namespace に保存するため、Kubernetes RBAC と連携可能 $POGJH.BQBOE4FDSFUBTTJNQMFEBUBTUPSF Program Request Data

• Server-side では事前に問題データをロード • 「受け取った回答」と「正解データ」を OPA で検証 ࢀߟɿ,POUFTU ,VCFSOFUFT$POUFTU BSDIJUFDUVSF Frontend Server-side Request Conftest 問題や正解データなどのロード • 特定のラベルがついた ConfigMap をロード • 特定のフィールドを持っているか検証

Stats data from Kubernetes API

• 課⾦のための情報を保存したい • 現在のリソースの情報から設定を⽣成したい • etc. CronJob で定期的に起動するなどで、 Kubernetes API を叩いて処理を⾏うプログラム • 利⽤状況を DB に格納 • Pod のリストから設定ファイルを⽣成 4UBUTEBUBGSPN,VCFSOFUFT"1* Computing resource pool Storage pool

Watching and reconciling resources by controller

・任意のスキーマで CustomResource を追加する機能がある ・Controller を実装するライブラリ・フレームワークが提供されている Controllerの中⾝ = API の操作 ＋ ロジック 元となるリソースの データを監視し reconcile() { … } 何かしらの処理をする （調整・収束させ続ける） ,VCFSOFUFT $POUSPMMFS

ConfigMap での問題の事前ロード => 追加した際に読み込まれない 定期実⾏によるその時の状態からの設定ファイルの動的⽣成 => 不要な API リクエストが発⽣する・反映タイミングに差が出る Kubernetes Controller で該当リソースの変更を検知して Reconcile することで解決可能 6TJOHDPOUSPMMFSTGPSXBUDIJOHSFTPVSDFT 元となるリソースの データを監視し reconcile() { … } 何かしらの処理をする （調整・収束させ続ける）

外部から落としてきたデータセットをキャッシュしたい ・PersistentVolume にデータセットをロードしてデータが使える状態にする Pod を起動してコピー処理、完了 Annotations の付与、 ・必要に応じて VolumeSnapshot をで利⽤させる 8BUDIJOHBOESFDPODJMJOHSFTPVSDFT 元となるリソースの データを監視し reconcile() { … } 何かしらの処理をする （調整・収束させ続ける）

Mutate and Validate at resource operation

リソースの登録・更新・削除時に任意のチェックや変更を⾏いたい • 特定の Volume は ReadOnly マウントを強制する • ユーザが登録するメタデータのチェック • 独⾃の Annotations の変更制限 • etc Kubernetes の Admission Webhook を利⽤する .VUBUFBOEWBMJEBUFBUSFTPVSDFPQFSBUJPO Webhook Request Check

Kubernetes API requests 時に Mutating（変更）・Validating（検証）するプラグイン機構 認証・認可後に実施され、Mutating 終了後にスキーマと合致するかがチェックされる 様々な Admission Controller が提供されている https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ "ENJTTJPO$POUSPMMFS https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

ResourceQuota Admission Controller︓リクエストされたリソースが Quota 超過しないかチェック 7BMJEBUJOH"ENJTTJPOͷྫ https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ apiVersion: v1 kind: ResourceQuota metadata: name: sample spec: hard: count/secrets: 10 apiVersion: v1 kind: Secret metadata: name: sample stringData: hoge: fuga OK or NG

LimitRanger Admission Controller︓コンテナの Requests / Limits を更新する .VUBUJOH"ENJTTJPOͷྫ https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ apiVersion: v1 kind: LimitRange metadata: name: sample spec: limits: - type: Container defaultRequest: cpu: 100m apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: my-con image: nginx:1.16 apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: my-con image: nginx:1.16 resources.requests.cpu: 100m

LimitRanger Admission Controller︓コンテナの最⼤ Requests/Limits などを制限する ݉༻͞Ε͍ͯΔ "ENJTTJPO$POUSPMMFS https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ apiVersion: v1 kind: LimitRange metadata: name: sample spec: limits: - type: Container max: cpu: 50m apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: my-con image: nginx:1.16 resources.requests.cpu: 100m OK or NG

Admission Controller の中にはユーザが定義可能な拡張ポイント⽤プラグインが提供されている • ValidatingAdmissionWebhook︓外部 API Server にリクエストを送って Validating • MutatingAdmissionWebhook︓外部 API Server にリクエストを送って Mutating "ENJTTJPO8FCIPPL https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

Admission Webhook 登録にはリソースを作成 • ValidatingWebhookConfiguration • MutatingWebhookConfiguration "ENJTTJPO8FCIPPLͷొ࿥ apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingWebhookConfiguration metadata: name: sample webhooks: - name: sample rules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["pods"] scope: Namespaced clientConfig: service: namespace: default name: sample-service caBundle: "Ci0tLS0tQk...tLS0K" sideEffects: None timeoutSeconds: 5 どのようなリクエスト時に Webhook を呼び出すか リクエスト先の情報

clientConfig に登録できる⽅法は 2 つ • 外部 URL • クラスタ内の Service 基本的にはクラスタ内の Service として登録 １．通常のサービス開発通り API Server を実装し、 Deployment などでデプロイ ２．指定した Service で公開 "ENJTTJPO8FCIPPLͷొ࿥ apiVersion: admissionregistration.k8s.io kind: ValidatingWebhookConfiguration metadata: name: sample webhooks: - name: sample rules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["pods"] scope: Namespaced clientConfig: service: namespace: default name: sample-service caBundle: "Ci0tLS0tQk...tLS0K" sideEffects: None timeoutSeconds: 5

clientConfig に登録できる⽅法は 2 つ • 外部 URL • クラスタ内の Service 基本的にはクラスタ内の Service として登録 ０．適切な証明書を登録する １．通常のサービス開発通り API Server を実装し、 Deployment などでデプロイ ２．指定した Service で公開 "ENJTTJPO8FCIPPLͷొ࿥ apiVersion: admissionregistration.k8s.io kind: ValidatingWebhookConfiguration metadata: name: sample webhooks: - name: sample rules: - apiGroups: [""] apiVersions: ["v1"] operations: ["CREATE"] resources: ["pods"] scope: Namespaced clientConfig: service: namespace: default name: sample-service caBundle: "Ci0tLS0tQk...tLS0K" sideEffects: None timeoutSeconds: 5

K8s には内部利⽤⽤途の証明書署名機能が存在 caBundle で利⽤する証明書は下記の⼿順で発⾏可能 1. cfssl・cfssljson などで CSRの作成 2. CertificateSigningRequest リソースの作成 3. kubectl certificate approve で署名 4. CertificateSigningRequest リソースの status フィールドから署名済み証明書を所得 ࢀߟɿূ໌ॻͷൃߦ apiVersion: certificates.k8s.io/v1beta1 kind: CertificateSigningRequest metadata: name: sample-webhook spec: request: $(cat sample-webhook.csr | base64) usages: - ...

Webhook サーバではリクエスト（ AdmissionRequest ）で渡ってくるリソースの情報を元に レスポンス（ AdmissionResponse ）を返す Admission Request︓Operation や新旧リソースの情報が含まれている AdmissionResponse︓Validating や Mutating の結果が含める Webhook は kubebuilder、OperatorSDK、slok/kubewebhook などで実装可能 "ENJTTJPO8FCIPPLͷ࣮૷ https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/admission/types.go AdmissionRequest AdmissionResponse Webhook Server

࣮૷ෆཁͳ 7BMJEBUJOH8FCIPPL Gatekeeper Rego Policy

࣮૷ෆཁͳ 7BMJEBUJOH8FCIPPL Gatekeeper Rego ⾔語を⽤いてポリシーを記述可能 https://www.openpolicyagent.org/docs/latest/policy-language/ ⼊⼒（input）に対して適切な設定値になっているかをチェックする deny[msg] { input.kind == "Deployment" container := input.spec.template.spec.containers[_] container.securityContext.privileged == true msg = sprintf("Do not use privileged containers: Name=%s", [input.metadata.name]) } Request Check

ԣஅͰͷνΣοΫ 例）設定の衝突 依存リソースの存在 Gatekeeper では Kubernetes API と同期を取ることが出来るため、 data.inventory.namespace[NAMESPACE][groupVersion][kind][NAME].kind などで 参照した既存のリソース情報を元にポリシーチェックが可能 ︓Ingress の FQDN が衝突していないか ︓Deployment に対応する PodDisruptionBudget リソースが存在するか

For Kubernetes-native

Kubernetes-native testbed for the future (still alpha release) https://employment.en-japan.com/engineerhub/entry/2020/04/16/103000 11 microservices

Kubernetes-native CI/CD 2. webhook 7. Update manifest (Pull requests) 5. Push container image 4. Build container image 1. Modify application source code 8. Pull manifests 9. Apply manifests 3. Kick pipelines Continuous Integration Continuous Delivery source manifests 6. Scan container image Conftest Gatekeeper https://event.cloudnativedays.jp/cndt2020/talks/9 ソースコード類も⼀式公開 ここに載っていない OSS 等も

Conclusion

GPU as a Service をサンプルとして、いくつかのパターンで実現⽅法について紹介 ConfigMap / Secret を簡易的なデータストアとして利⽤ Kubernetes API から取得可能なデータの利⽤ -> より⾼度な⾃動化に関しては⾃然と Controller 化や Admission Webhook を検討する $PODMVTJPO

Thank you for your attention @amsy810

抽選会用 宣伝

２０１８年９⽉２１⽇発売予定 https://bit.ly/k8s-amsy810 Kubernetesの各リソースについて体系的かつ網羅的に説明 Cloud Nativeな開発を促進させる周辺エコシステムについても紹介 ■⽬次案 第1章 Dockerの復習とHello, Kubernetes 第2章 なぜKubernetesが必要なのか︖ 第3章 Kubernetes環境の選択肢 第4章 APIリソースとkubectl 第5章 Workloadsリソース 第6章 Discovery & LBリソース 第7章 Config & Storageリソース 第8章 ClusterリソースとMetadataリソース 第9章 リソース管理とオートスケーリング 第10章 ヘルスチェックとコンテナのライフサイクル 第11章 メンテナンスとノードの停⽌ 第12章 ⾼度で柔軟なスケジューリング 第13章 セキュリティ 第14章 マニフェストの汎⽤化を⾏うオープンソースソフトウェア 第15章 モニタリング 第16章 コンテナログの集約 第17章 CI/CD環境 第18章 マイクロサービスとServiceMesh 第19章 Kubernetesのアーキテクチャ 第20章 Kubernetesとこれから 付録

２０２０年８⽉７⽇発売予定 https://bit.ly/k8s-amsy810-2 Kubernetesの各リソースについて体系的かつ網羅的に説明 Cloud Nativeな開発を促進させる周辺エコシステムについても紹介 ■⽬次案 第1章 Dockerの復習と「Hello, Kubernetes」 第2章 なぜKubernetesが必要なのか︖ 第3章 Kubernetes環境の選択肢 第4章 APIリソースとkubectl 第5章 Workloads APIsカテゴリ 第6章 Service APIsカテゴリ 第7章 Config＆Storage APIsカテゴリ 第8章 Cluster APIsカテゴリとMetadata APIsカテゴリ 第9章 リソース管理とオートスケーリング 第10章 ヘルスチェックとコンテナのライフサイクル 第11章 メンテナンスとノードの停⽌ 第12章 ⾼度で柔軟なスケジューリング 第13章 セキュリティ 第14章 マニフェストの汎⽤化を⾏うオープンソースソフトウェア 第15章 モニタリング 第16章 コンテナログの集約 第17章 Kubernetes環境でのCI/CD 第18章 マイクロサービスアーキテクチャとサービスメッシュ 第19章 Kubernetesのアーキテクチャを知る 第20章 Kubernetesとこれから 付録

What is mastering kubernetes? 『Kubernetes完全ガイド』 の特徴 網羅的・体系的 体系的かつ網羅的にほぼ全機能を解説 実際に利用している小ネタ・小技 公式ドキュメントには載っていない小ネタや 実運用上のハマりポイントなど 周辺エコシステムも説明 Helm / Kustomize / Datadog / Prometheus Istio / ArgoCD / Telepresence / Skaffold OpenPolicyAgent / Fluentd… 豊富な図画 合計 285 枚 > 合計 288 枚 豊富なマニフェスト 合計 185 YAML > 合計 312 YAML 豊富なよくある質問 合計 199 質問 > 合計 257 質問

No content

体感的には 10%削除 20%更新 35%追加

No content

§ 一部を除き、Kubernetes 1.18 の時点でAlpha機能としてリリースさ れた機能を含めました。 § ダウントレンド気味なエコシステムを外し、 アップトレンドなエコシステムを入れました § 利用頻度が高くなってきたエコシステムの説明を追加しました § 色々追加しました ２年間で頂いた質問をちょこちょこメモしてあったので その辺りを追記したり

index.htmlファイルなどをわざわざ配置したりなどしていましたが、 独自のコンテナイメージを作ったのでわかりやすくなりました。 その他にもいくつか…

紙面が見やすくなりました コマンドとマニフェストの背景色の差

２０２０年８⽉７⽇発売予定 https://bit.ly/k8s-amsy810-2 Kubernetesの各リソースについて体系的かつ網羅的に説明 Cloud Nativeな開発を促進させる周辺エコシステムについても紹介 ■⽬次案 第1章 Dockerの復習と「Hello, Kubernetes」 第2章 なぜKubernetesが必要なのか︖ 第3章 Kubernetes環境の選択肢 第4章 APIリソースとkubectl 第5章 Workloads APIsカテゴリ 第6章 Service APIsカテゴリ 第7章 Config＆Storage APIsカテゴリ 第8章 Cluster APIsカテゴリとMetadata APIsカテゴリ 第9章 リソース管理とオートスケーリング 第10章 ヘルスチェックとコンテナのライフサイクル 第11章 メンテナンスとノードの停⽌ 第12章 ⾼度で柔軟なスケジューリング 第13章 セキュリティ 第14章 マニフェストの汎⽤化を⾏うオープンソースソフトウェア 第15章 モニタリング 第16章 コンテナログの集約 第17章 Kubernetes環境でのCI/CD 第18章 マイクロサービスアーキテクチャとサービスメッシュ 第19章 Kubernetesのアーキテクチャを知る 第20章 Kubernetesとこれから 付録

参加後アンケートで抽選するので ぜひ答えてください！ オプトインする必要があるので注意！

Thank you for your attention @amsy810