Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kube API Server

Avatar for bells17 bells17
July 18, 2021

Kube API Server

Avatar for bells17

bells17

July 18, 2021
Tweet

More Decks by bells17

Other Decks in Programming

Transcript

  1. ▶ @bells17 ▶ Software Engineer@IDC Frontier inc. ▶ 普段やってること: +

    Kubernetes 関連コンポーネントの開発 + Kubernetes as a Serviceの開発 + 最近マネジメント業が追加されました ▶ Kubernetes SIG-Docs Japanese localization reviewer ▶ Kubernetes Internal Organizer ▶ #kubenews ▶ @bells17_
  2. 今⽇話すこと ▶ Kubernetesの概要 ▶ Kubernetes Core Componentについての簡単な説明 ▶ Kube API

    Serverのアーキテクチャについて ▶ Kube API Serverの各機能の実装の概要
  3. 注意点 ▶ Kubernetes v1.21.2ベースでのお話になります ▶ KubernetesそのものやKubernetes Component全体の説明は簡単なものに なるかと思います ▶ あくまでKube

    API Serverの実装を追った結果での理解の説明になるので、 ところどころ間違いが含まれている可能性があります ▶ 基本Kube API Serverのアーキテクチャや実装の概要を淡々と⾏なっていく 感じなので、あっさりめのセッションになると思います
  4. Kubernetes とは? ▶ Kubernetesはコンテナオーケストレーターの1つ ▶ etcd/control plane/worker nodeによって構成されたクラスターを構築し、 様々なコンテナをKubernetes上のnodeで動作させたり、動作させてるコン テナとネットワークをいい感じに連携できるようにすることができる

    ▶ デプロイするコンテナなどをmanifestファイルで宣⾔的に記述することで、 宣⾔した状態になるようにKubernetesがいい感じに調整処理を⾏ってくれる ▶ Googleが内部で運⽤していたコンテナ基盤であるBorgをOSS向けに作り直 したコンテナオーケストレーター ▶ また、KubernetesはCloud Native Computing Foundation(CNCF)に寄贈さ れており、CNCFのGraduatedプロジェクトとしてコミュニティベースで管理 されている
  5. Core Component ▶ etcd: API Serverのバックエンドで使⽤されている分散型のKVS ▶ Control Plane ▶

    API Server: KubernetesのAPIリクエストを処理するサーバー ▶ Kube Controller Manager: Kubernetesの様々なリソースのためのロジックを動かす 様々なコントローラーを動作させるマネージャー ▶ Cloud Controller Manager: Kubernetesとクラウド(実⾏基盤)を連携するための コントローラーを動作させるマネージャー ▶ Scheduler: PodをどのWorker Nodeに配置するかを決める ▶ Worker Node ▶ Kubelet: Worker Nodeで実⾏するコンテナを管理するアプリケーション ▶ Kube Proxy: Serviceリソースに基づくネットワーク設定を⾏うアプリケーション
  6. ▶ Cloud Controller Manager Deep Dive ▶ Kubernetes Internal #2

    Cloud Controller Managerについては以下のスライドで まとめてあるので参考にしてください
  7. Kube API Server ▶ Kubernetesの様々なデータ保存や取得、イベント通知を⾏うAPI Server ▶ Rest APIを中⼼としたAPI Serverを提供する

    ▶ API定義はProtocol Buffersによって⾏われる ▶ 定義したAPIはAPI Server側でOpenAPI形式に変換され、APIからスキーマ定義が 取得可能 ▶ etcdをデータ永続のためのデータストアとして使⽤ ▶ リソース操作時の⾃動的なデータ改変/バリデーションを可能にするWebhookを提供 ▶ 独⾃リソース管理のための機能を提供 ▶ Extension API Server ▶ Custom Resource Definition(CRD)
  8. どんなリソース定義があるのかを調べることができたり DVSMIUUQMPDBMIPTUBQJW \ LJOE"1*3FTPVSDF-JTU  HSPVQ7FSTJPOW  SFTPVSDFT<  \

    OBNFQPET  TJOHVMBS/BNF  OBNFTQBDFEUSVF  LJOE1PE  WFSCT< DSFBUF EFMFUF EFMFUFDPMMFDUJPO HFU MJTU QBUDI VQEBUF XBUDI >  TIPSU/BNFT< QP >  DBUFHPSJFT< BMM >  TUPSBHF7FSTJPO)BTIY10X3; :IX ^  
  9. そもそもどんなパスがあるのかを調べたりすることもできる DVSMIUUQMPDBMIPTU \ QBUIT< XFMMLOPXOPQFOJEDPOpHVSBUJPO  BQJ  BQJW 

    BQJT  BQJT   lIFBMUI[ "1*4FSWFSͷϔϧενΣοΫΤϯυϙΠϯτ ʜ lNFUSJDT "1*4FSWFSͷϝτϦΫεΛऔಘ lPQFOBQJW "1*4FSWFSʹ0QFO"1*εΩʔϚΛऔಘ ΊͬͪΌ௕͍  PQFOJEWKXLT   lWFSTJPO"1*4FSWFSͷόʔδϣϯΛऔಘ > ^
  10. API Serverにリクエストしたときに 起きてること ▶ http2によるリクエストをAPI Serverが受信 ▶ API ServerのServerChainにより様々な前処理を実⾏ +

    CORS/HSTSなど各種HTTPヘッダーを設定 + 認証/認可処理 + なりすまし機能によるユーザー情報の差し替え + etc ▶ 対象リソースの取得/作成など実⾏ + リソースの作成や更新時は各種Admission Controllerによる値の上書き やバリデーションを実⾏ + バリデーションなどでエラーが無ければetcdにデータを保存 ▶ レスポンスを返す
  11. API Extensions Server ▶ API Extentions Serverは、ユーザーが作成するCRDリソースの設定に 基づいてカスタムリソースを処理するためのhttp handlerを動的に提供する 機能を提供する

    ▶ そのため、CRDが作成されるとAPI Extentions Server内部で動いている Kubernetes Controller群によってバリデーションなどのチェックが⾏わ れ、問題無ければ動的にカスタムリソースを処理するエンドポイントが提供 される ▶ つまり、Kubernetesを使っててよくお世話になるKubernetes Operatorが 機能するのはこのAPI Extensions Serverのおかげ ▶ また、CRDリソースのCRUDエンドポイントを⽤意してるのもこのサーバー
  12. API Server ▶ API Serverは、Kubernetes内部で定義済みのPodやConfigMapといった 各種リソースを処理するためのAPIサーバーを提供する ▶ なのでKubernetesがデフォルトで提供するリソースを処理するためのエン ドポイントはだいたいこのAPI Serverが提供してくれている

    ▶ ちなみに定義済みのAPIは⼤まかに以下のような感じで分類できるっぽい ▶ Core(Legacy) API: PodやConfigMapなど”v1”のAPI ▶ GroupVersion API:“batchv1”や”appsv1”などのグループに所属してるAPI ▶ その他のAPI: VersionやHealthzなどのAPI
  13. Aggregator Server ▶ Aggregator Serverは初期化時にAPI ServerとAPI Extensions ServerのOpenAPIス キーマ定義を読み取り、APIServiceリソースを⽣成する ▶

    Aggregator ServerではAPIServiceリソースを監視するKubernetes Controllerが動 作していて、APIServiceリソースの変更に基づいて、動的にリクエストを処理する ためのhttp handlerの設定が⾏われる ▶ また、ユーザーが⼿動で追加したExtension API Serverについては、ユーザーが⼿ 動でAPIServiceリソースを作成することにより、設定した条件に基づいてリクエス トがExtension API Serverにプロキシされる ▶ API Extentions ServerやAPI Serverは、実際にはAggregator Serverに組み込まれて 動作するので、複数のHTTPサーバーが起動するわけではない (それぞれが別々に⾃⽴して起動できるような実装にはなっているよう)
  14. Kube API Serverのアーキテクチャ このように、Kube API Serverのアーキテクチャは ▶ Aggregator Serverが前段にいてリクエストを受け付ける ▶

    リクエストを受け付けると認証/認可などの様々な前処理を⾏う ▶ 前処理が終わると、リクエストパスなどに基づき、API (Extentions) Serverのhttp handlerを呼び出したり、ユーザーが⼿動で登録した Extension API Serverにリクエストをプロキシすることで処理を⾏い、 レスポンスを返す というものになっている
  15. ServerChain ServerChainは各リクエストの処理前に実⾏される前処理になる ▶ HSTS/CacheControl/CORSといったHTTP headerを設定 ▶ リクエスト処理時間を記録 ▶ リクエスト⽤のaudit eventレコーダーを⽣成

    ▶ リクエスト情報を元にRequestInfoオブジェクトを⽣成 ▶ リクエストの種類を元にタイムアウト時間を設定 ▶ 認証 ▶ ユーザーのなりすまし設定 ▶ APIリクエストの優先度コントロール ▶ 認可 といったことを⾏なっている これらの前処理後に実際に要求した各種のリソース操作などの処理を⾏なっている
  16. Admission Controller ▶ Kube API ServerにはAdmission ControllerというAPI Serverへのリソース の保存や更新時に、保存するデータを上書きしたり、バリデーションする 仕組みが存在する

    ▶ Admission ControllerはKube API Serverに組み込まれており、プラグイン という形でどのAdmission Controllerを利⽤するかを選択することができる ▶ この機能は、元々OpenShiftに実装されていたものが、Kubernetesに移植 される形で導⼊されたらしい
  17. Admission Webhook ▶ Admission Pluginの⼀種である + ValidatingAdmissionWebhook + MutatingAdmissionWebhook ▶

    の2つのpluginが提供する機能 ▶ それぞれ + MutatingWebhookConfiguration + ValidatingWebhookConfiguration ▶ というリソースを設定することで独⾃のWebhookサーバーを通してデータ の上書き/バリデーションを⾏うことが可能 ▶ データの上書き/バリデーションの機能が利⽤できるので、実質的に各種 Admission Pluginと同じ仕組みをKubernetesの外部から提供可能
  18. etcdにデータが保存されるまで ▶ ServerChainによる前処理を実⾏ ▶ HTTP Bodyをデコードしてruntime.Objectを⽣成 ▶ オブジェクトにManagedFieldを設定 ▶ 各種MutatingAdmissionを実⾏

    + 対象リソースを処理するMutatingWebhookが登録されている場合は実⾏ ▶ オブジェクトにOwnerReferenceを設定 ▶ 各種ValidatingAdmissionを実⾏ + 対象リソースを処理するValidatingAdmissionが登録されている場合は実⾏ ▶ 対象リソースに応じたTransformerを実⾏し、etcdに保存するデータを暗号化 + 暗号化にKMSプロバイダーを使⽤している場合には、unix domain socketとgRPCを通して KMSプラグインへリクエスト + KMSプラグインを通してKMSプロバイダーのAPIを呼び出し ▶ etcdへデータを保存 ▶ デコードしてクライアントへレスポンスを返す
  19. etcdからデータを取り出す際 ▶ ServerChainによる前処理を実⾏ ▶ HTTP queryをデコードしてOptionを⽣成 ▶ Optionの条件などを元にetcdからデータを取得 ▶ 対象リソースに応じたTransformerを実⾏し、etcdに保存するデータを暗号化

    + 暗号化にKMSプロバイダーを使⽤している場合には、unix domain socketと gRPCを通してKMSプラグインへリクエスト + KMSプラグインを通してKMSプロバイダーのAPIを呼び出し ▶ デコードしてクライアントへレスポンスを返す
  20. まとめ ▶ Kube API Server全体のアーキテクチャと、例えばetcdへのデータ保存までがどのように なっているのか?などKube API Serverの主だった処理などについて紹介しました ▶ Kube

    API ServerはAggregator Serverによって独⾃のAPI Serverを追加して連携できたり、 カスタムリソースの作成に応じてHTTPハンドラーを動的に⽣成することで、動的に追加さ れるリソースの処理を⾏うことができる仕組みになっています ▶ データ保存の際は、ユーザーも独⾃のAdmission Webhookを構築することで、データの 動的なMutating/Validatingが追加可能です ▶ kubectl execなどKube API Serverからコンテナに接続する際は、対象NodeのKubeletや Runtime Shimをプロキシすることでコンテナに接続する仕組みになっていました
  21. 感想 ▶ コードを追ってみて、例えばすでに読んだことのあるKubeletと⽐べると、アプリケーション 全体の複雑度はKube API Serverの⽅が低いので読みやすかったと思います ▶ ⼀⽅でコンポーネントの依存度を下げるためか、実際にKube API Serverが動くまで、あるい

    はリクエストを処理するハンドラーにたどり着くまでに様々なConfigを⾊んな箇所で⽣成し ていて、それらの⼊れ⼦構造がかなりの多重構造だったのは複雑だなと思いました ▶ Webアプリケーションサーバーでハンドラーを動的に⽣成して処理させるようなパターンは 作ったことがなかったので、読んでて新鮮な気分になりました
  22. 参考資料 ▶ Kubernetes v1.21.2: https://github.com/kubernetes/kubernetes/tree/v1.21.2 ▶ Kubebuilder Book: https://book.kubebuilder.io/ ▶

    sample-controller: https://github.com/kubernetes/sample-controller ▶ apiserver-builder-alpha: https://github.com/kubernetes-sigs/apiserver-builder-alpha ▶ Custom Metrics Adapter Server Boilerplate: https://github.com/kubernetes-sigs/custom-metrics-apiserver ▶ Prometheus Adapter for Kubernetes Metrics APIs: https://github.com/kubernetes-sigs/prometheus-adapter ▶ metrics: https://github.com/kubernetes/metrics ▶ CRI Streaming Requests (exec/attach/port-forward): https://docs.google.com/document/d/1OE_QoInPlVCK9rMAx9aybRmgFiVjHpJCHI9LrfdNM_s/edit#heading=h.4yfjiw58o8d3 ▶ Using a KMS provider for data encryption: https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/ ▶ Encrypting Secret Data at Rest: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ ▶ Adding custom resources to the Kubernetes API server: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/extending-api.md ▶ Use an HTTP Proxy to Access the Kubernetes API: https://kubernetes.io/docs/tasks/extend-kubernetes/http-proxy-access-api/ ▶ Control Plane-Node Communication: https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/ ▶ Dynamic Admission Control: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ ▶ Kubernetes Proposal - Admission Control: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission_control.md ▶ Extension of Admission Control via Initializers and External Admission Enforcement: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/ admission_control_extension.md ▶ Webhook Bootstrapping: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission-webhook-bootstrapping.md ▶ Webhooks Beta: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission-control-webhooks.md ▶ Dynamic Admission Control: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers ▶ Configure the Aggregation Layer: https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/ ▶ Set up an Extension API Server: https://kubernetes.io/docs/tasks/extend-kubernetes/setup-extension-api-server/ ▶ Vanilla CRD OpenAPI subset: structural schemas: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/2335-vanilla-crd-openapi-subset-structural-schemas ▶ The Kubernetes API: https://kubernetes.io/docs/concepts/overview/kubernetes-api/ ▶ Controlling Access to the Kubernetes API: https://kubernetes.io/docs/concepts/security/controlling-access/ ▶ Authenticating: https://kubernetes.io/docs/reference/access-authn-authz/authentication/ ▶ Authorization Overview: https://kubernetes.io/docs/reference/access-authn-authz/authorization/