Kubernetesと連携するアプリケーション開発手法 / openshiftjp10-amsy810

Kubernetesと連携するアプリケーション開発手法

(青山 真也 (@amsy810))

Kubernetes APIを用いてKubernetes上にデプロイしたアプリケーションをOperatorで管理するKubernetes-naticeなプロダクトが世の中にはたくさん増えてきました。 それ以外にも、Kubernetes APIをうまく使うことで、簡易的な機能実装をすることができます。 本セッションでは「簡易的なメタデータストアとして利用する方法」など、Kubernetesを少し便利に使う方法についてまとめてみます。

猛暑/残暑に負けるな！OpenShift.Run Summer #10

Transcript

1. Masaya Aoyama CyberAgent Kubernetes ͱ࿈ܞ͢Δ ΞϓϦέʔγϣϯ։ൃख๏ @OpenShift.Run Summer #10 @amsy810
2. - Co-chair Masaya Aoyama + CREATIONLINE / DENSO - 技術アドバイザ + SAKURA Internet Research Center – 客員研究員 + 3-shake 技術顧問 + PLAID - Organizer - KaaS Product Owner - Publications Twitter: @amsy810
3. 本⽇の Goal Kubernetes との連携の仕⽅の パターンを探る ⼩さなところから初めてみる
4. ページの都合上、⼀部 YAML の記法が擬似コード的になっているため注意してください。 /PUF
5. GPU as a Service
6. 各ユーザが GPU コンテナを利⽤できる仕組み Web UI や CLI からも Kubernetes を 隠蔽した形で操作可能 Jupyter notebook の払い出し等 更にこの上に ML 関連の Platform が展開 (16
   BT
   B
   4FSWJDF
   1MBUGPSN Container Computing resource pool Storage pool icons: https://icons8.jp/icons/set/video-card
7. • ユーザに払い出されるリソースは Namespace を使って分割 • RBAC を使った権限が管理 (16
   BT
   B
   4FSWJDF
   1MBUGPSN User A namespace User B namespace icons: https://icons8.jp/icons/set/video-card
8. ConfigMap / Secret as simple data store
9. ある程度のデータは Kubernetes を簡易的な DB として利⽤ • ユーザーが定義したテンプレート • ユーザが登録した利⽤イメージ • etc 変更が少なく、ユーザに容易に操作させるようなデータで利⽤（cf. Configuration as Code） 各 Namespace に保存するため、Kubernetes RBAC と連携可能 $POGJH.BQ
   BOE
   4FDSFU
   BT
   TJNQMF
   EBUB
   TUPSF Program Request Data
10. • Server-side では事前に問題データをロード • 「受け取った回答」と「正解データ」を OPA で検証 ࢀߟɿ,POUFTU ,VCFSOFUFT
    $POUFTU
    BSDIJUFDUVSF Frontend Server-side Request Conftest 問題や正解データなどのロード • 特定のラベルがついた ConfigMap をロード • 特定のフィールドを持っているか検証
11. Stats data from Kubernetes API
12. • 課⾦のための情報を保存したい • 現在のリソースの情報から設定を⽣成したい • etc. CronJob で定期的に起動するなどで、 Kubernetes API を叩いて処理を⾏うプログラム • 利⽤状況を DB に格納 • Pod のリストから設定ファイルを⽣成 4UBUT
    EBUB
    GSPN
    ,VCFSOFUFT
    "1* Computing resource pool Storage pool
13. Watching and reconciling resources by controller
14. ・任意のスキーマで CustomResource を追加する機能がある ・Controller を実装するライブラリ・フレームワークが提供されている Controllerの中⾝ = API の操作 ＋ ロジック 元となるリソースの データを監視し reconcile() { … } 何かしらの処理をする （調整・収束させ続ける） ,VCFSOFUFT $POUSPMMFS
15. ConfigMap での問題の事前ロード => 追加した際に読み込まれない 定期実⾏によるその時の状態からの設定ファイルの動的⽣成 => 不要な API リクエストが発⽣する・反映タイミングに差が出る Kubernetes Controller で該当リソースの変更を検知して Reconcile することで解決可能 6TJOH
    DPOUSPMMFST
    GPS
    XBUDIJOH
    SFTPVSDFT 元となるリソースの データを監視し reconcile() { … } 何かしらの処理をする （調整・収束させ続ける）
16. 外部から落としてきたデータセットをキャッシュしたい ・PersistentVolume にデータセットをロードしてデータが使える状態にする Pod を起動してコピー処理、完了 Annotations の付与、 ・必要に応じて VolumeSnapshot をで利⽤させる 8BUDIJOH
    BOE
    SFDPODJMJOH
    SFTPVSDFT 元となるリソースの データを監視し reconcile() { … } 何かしらの処理をする （調整・収束させ続ける）
17. Mutate and Validate at resource operation
18. リソースの登録・更新・削除時に任意のチェックや変更を⾏いたい • 特定の Volume は ReadOnly マウントを強制する • ユーザが登録するメタデータのチェック • 独⾃の Annotations の変更制限 • etc Kubernetes の Admission Webhook を利⽤する .VUBUF
    BOE
    WBMJEBUF
    BU
    SFTPVSDF
    PQFSBUJPO Webhook Request Check
19. 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/
20. 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
21. 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
22. 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
23. Admission Controller の中にはユーザが定義可能な拡張ポイント⽤プラグインが提供されている • ValidatingAdmissionWebhook︓外部 API Server にリクエストを送って Validating • MutatingAdmissionWebhook︓外部 API Server にリクエストを送って Mutating "ENJTTJPO
    8FCIPPL https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/
24. Admission Webhook 登録にはリソースを作成 • ValidatingWebhookConfiguration • MutatingWebhookConfiguration "ENJTTJPO
    8FCIPPL
    ͷొ࿥ 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 を呼び出すか リクエスト先の情報
25. clientConfig に登録できる⽅法は 2 つ • 外部 URL • クラスタ内の Service 基本的にはクラスタ内の Service として登録 １．通常のサービス開発通り API Server を実装し、 Deployment などでデプロイ ２．指定した Service で公開 "ENJTTJPO
    8FCIPPL
    ͷొ࿥ 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
26. clientConfig に登録できる⽅法は 2 つ • 外部 URL • クラスタ内の Service 基本的にはクラスタ内の Service として登録 ０．適切な証明書を登録する １．通常のサービス開発通り API Server を実装し、 Deployment などでデプロイ ２．指定した Service で公開 "ENJTTJPO
    8FCIPPL
    ͷొ࿥ 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
27. 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: - ...
28. Webhook サーバではリクエスト（ AdmissionRequest ）で渡ってくるリソースの情報を元に レスポンス（ AdmissionResponse ）を返す Admission Request︓Operation や新旧リソースの情報が含まれている AdmissionResponse︓Validating や Mutating の結果が含める Webhook は kubebuilder、OperatorSDK、slok/kubewebhook などで実装可能 "ENJTTJPO
    8FCIPPL
    ͷ࣮૷ https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/admission/types.go AdmissionRequest AdmissionResponse Webhook Server
29. ࣮૷ෆཁͳ 7BMJEBUJOH
    8FCIPPL Gatekeeper Rego Policy
30. ࣮૷ෆཁͳ 7BMJEBUJOH
    8FCIPPL 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
31. ԣஅͰͷνΣοΫ 例）設定の衝突 依存リソースの存在 Gatekeeper では Kubernetes API と同期を取ることが出来るため、 data.inventory.namespace[NAMESPACE][groupVersion][kind][NAME].kind などで 参照した既存のリソース情報を元にポリシーチェックが可能 ︓Ingress の FQDN が衝突していないか ︓Deployment に対応する PodDisruptionBudget リソースが存在するか
32. For Kubernetes-native
33. Kubernetes-native testbed for the future (still alpha release) https://employment.en-japan.com/engineerhub/entry/2020/04/16/103000 11 microservices
34. 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 等も
35. Conclusion
36. GPU as a Service をサンプルとして、いくつかのパターンで実現⽅法について紹介 ConfigMap / Secret を簡易的なデータストアとして利⽤ Kubernetes API から取得可能なデータの利⽤ -> より⾼度な⾃動化に関しては⾃然と Controller 化や Admission Webhook を検討する $PODMVTJPO
37. Thank you for your attention @amsy810
38. 抽選会用 宣伝
39. ２０１８年９⽉２１⽇発売予定 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とこれから 付録
40. ２０２０年８⽉７⽇発売予定 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とこれから 付録
41. What is mastering kubernetes? 『Kubernetes完全ガイド』 の特徴 網羅的・体系的 体系的かつ網羅的にほぼ全機能を解説 実際に利用している小ネタ・小技 公式ドキュメントには載っていない小ネタや 実運用上のハマりポイントなど 周辺エコシステムも説明 Helm / Kustomize / Datadog / Prometheus Istio / ArgoCD / Telepresence / Skaffold OpenPolicyAgent / Fluentd… 豊富な図画 合計 285 枚 > 合計 288 枚 豊富なマニフェスト 合計 185 YAML > 合計 312 YAML 豊富なよくある質問 合計 199 質問 > 合計 257 質問
43. 体感的には 10%削除 20%更新 35%追加
45. § 一部を除き、Kubernetes 1.18 の時点でAlpha機能としてリリースさ れた機能を含めました。 § ダウントレンド気味なエコシステムを外し、 アップトレンドなエコシステムを入れました § 利用頻度が高くなってきたエコシステムの説明を追加しました § 色々追加しました ２年間で頂いた質問をちょこちょこメモしてあったので その辺りを追記したり
46. index.htmlファイルなどをわざわざ配置したりなどしていましたが、 独自のコンテナイメージを作ったのでわかりやすくなりました。 その他にもいくつか…
47. 紙面が見やすくなりました コマンドとマニフェストの背景色の差
48. ２０２０年８⽉７⽇発売予定 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とこれから 付録
49. 参加後アンケートで抽選するので ぜひ答えてください！ オプトインする必要があるので注意！
50. Thank you for your attention @amsy810