Kubernetes基础架构与VMware基础架构计算资源管理方式的比较速查表

2 年 ago
宇, 华
2 minutes

本文的撰写背景

在使用Kubernetes基础设施进行系统运维的过程中，需要注意的一个重要话题是计算资源管理（在本文后续描述中，“资源”一词指的是计算资源，如CPU资源和内存资源，而非Kubernetes产品中的API资源）。以下是背景和相关的三个要点：

    • 柔軟性/迅速性に優れるKubernetes基盤を活用することにより実現する、動的なリソース最適化（例:オートスケール）に対する関係者の期待が大きい。

 

    • 「DevOps」の文脈に基づきKubernetes基盤を運用する場合には、基盤上で稼働するワークロードは（その消費リソースも含めて）必然的に動的な性質を持たざるを得ない。

 

    Kubernetes基盤上で稼働するコンテナの個数が著しく膨大になることが予想されるため、「数の暴力」に対応するための自律的なリソース管理のための実装を整える必要が生じる。

一方面，对于初学者来说，特别是那些之前负责实施和操作VMware基础架构的系统基础架构专家，基于上述背景的动态资源管理可能并不太熟悉。

在考虑到上述所提及的情况之后，本文假设读者是曾经负责实施和运营VMware基础架构的系统基础架构专家，通过展示VMware基础架构和Kubernetes基础架构的四个快速参考表，揭示了在Kubernetes基础架构下资源管理的概况。

本文内容的注意事项

本文所述内容通常適用於以下產品版本：
* Kubernetes產品版本 v1.14
* VMware vSphere產品版本 v6.7

同时，为确保准确性，我们尽可能参考与之相关的来源作为依据，但由于无法进行实际操作或验证源代码内容，因此无法提供此类支持，请您谅解。

资源管理实施比较速查表

以下是关于与资源管理有关的基本概念项在Kubernetes基础设施和VMware基础设施中的实现之间差异的速查表。

リソース管理の概念VMware基盤Kubernetes基盤管理対象とし得るリソース種別CPUサイクル、メモリ容量、GPU処理能力、ネットワークI/O（NIOC）、ストレージI/O（SIOC）CPUサイクル、メモリ容量、短期的ストレージ容量2、GPU処理能力…etc.3リソースの予約予約requestsリソースの上限制限limitsリソースの割り当て比シェアrequests4CPUコアの静的割り当てCPUアフィニティ（対応する実装なし）5GPUリソース管理vDGA、vSGA、Shared Pass-Through Graphics6Kubernetes Device Plug-in拡張実装7によるGPUリソース管理の有効化ストレージI/O管理vSphere Storage I/O Control（SIOC）（対応する実装なし）8ネットワークI/O管理vSphere Network I/O Control（対応する実装なし）8リソース割り当て運用の利用者への委任リソースプールを用いた委任Resource Quotaを用いた委任（詳細比較は後続の早見表で）コンピュートインスタンスの配置最適化DRSによる配置最適化kube-schedulerによる配置最適化（詳細比較は後続の早見表で）基盤リソース逼迫状況におけるクラスタ内でのリソース配分の最適化DRSによる仮想マシンの動的再配置を通じた、リソース配分の最適化Eviction、およびPreemptionを用いた、実行優先度が低いコンテナの強制終了、および、実行優先度が高いコンテナへのリソース割り当て（詳細比較は後続の早見表で）コンピュートインスタンスの自律的なスケールアウト/スケールアップ（対応する実装なし）Horizontal Pod Autoscaler機能を用いたコンテナの自律的なスケールアウト、および、Vertical Pod Autoscaler機能を用いたコンテナの自律的なスケールアップ9システム基盤の自律的なスケールアウト/スケールアップ（対応する実装なし）Cluster Autoscaler機能を用いたノードの自律的なスケールアウト10

资源分配委托运营给利用者的比较操作速查表

根据「资源管理实施比较」速览表的说明，Kubernetes基础架构通过资源配额实施支持将容器资源分配委托给用户进行操作。以下速览表列出了针对将资源分配操作委托给用户的情况下，Kubernetes基础架构和VMware基础架构之间的差异。

比較の観点VMware基盤Kubernetes基盤利用者への委任単位リソースプールnamespace委任に際して統制の対象と出来るリソース種別CPUサイクル、メモリ容量CPUサイクル、メモリ容量、永続ストレージ容量（他、多数）11コンピュートインスタンス1個あたりのリソース割り当ての制限12不可能可能（「LimitRange」機能13により実現する）「リソースプール」の階層化可能不可能

计算实例的布局优化性能比较速查表

正如「资源管理实现比较」快速参考表所示，Kubernetes基础架构通过kube-scheduler实现对容器在节点上的优化部署。这与使用DRS优化在ESXi主机上部署虚拟机的VMware基础架构类似。为了针对这种计算实例（容器、虚拟机）部署的自主优化，以下快速参考表将展示Kubernetes基础架构与VMware基础架构之间的差异。

比較の観点VMware基盤Kubernetes基盤動的配置機能の既定での有効/無効無効14有効配置最適化の過程におけるノード負荷状況への配慮ありなし15ノードを指定する形でのコンピュートインスタンスの配置制御16仮想マシンとホスト間のアフィニティルールにより実現する。nodeSelector実装、nodeAffinity実装、もしくはTaints and Tolerations実装により実現する。コンピュートインスタンス間での配置制御17仮想マシン間のアフィニティルールにより実現するInter-Pod Affinity実装により実現するノード負荷平準化を目的としたコンピュートインスタンスの再配置vMotionによる仮想マシン移行なし18

基础资源紧缺情况下的操作比较速查表

根据「资源管理实施比较」早见表，Kubernetes基础设施通过强制终止优先级较低的容器，以确保为优先级较高的容器运行所需的资源在基础设施资源紧张时得到保障。下表展示了在此类基础设施资源紧张时的行为差异，包括Kubernetes基础设施和VMware基础设施之间的差异。

比較の観点VMware基盤Kubernetes基盤リソース逼迫時の起動制限アドミッションコントロールにより、余剰リソースが不足している状態での仮想マシンの起動が制限される。アドミッションコントロール相当のリソース管理実装により、余剰リソースが不足している状態でのコンテナの起動が制限される。ノードにおいてリソースが逼迫した際のリソース再配分動作透過的メモリ共有やメモリバルーニングなどを用いた、メモリリソースの節約、および再配分が行われる。リソース逼迫を理由として仮想マシンが強制されることはない。優先度（QoS Class）が低いコンテナをEviction Policyに基づき強制終了することにより、強制終了されたコンテナが保持していたリソースを回収すると共に、より優先度が高いコンテナにリソースを再配分する。クラスタにおいてリソースが逼迫した際のリソース再配分動作DRS実装を用いてノードへの仮想マシン配置を動的に最適化することによりリソース逼迫の解消を試みる。リソース逼迫を理由として仮想マシンが強制終了されることはない。Preemption実装を用いてクラスタ内での優先度（Priority Class）が低いコンテナを強制終了することにより、強制終了されたコンテナが保持していたリソースを回収すると共に、より優先度が高いコンテナにリソースを再配分する。

在本文中，我们多次使用了”优先度”这个术语，该术语对应于Kubernetes基础架构中的两种属性/设置，如下所示。因此，请注意不要混淆这两种属性/设置。

QoS Class

リソース逼迫をノード単位で解消するための、Eviction運用のために用いられる。
（非常に端的に要約すると）必要十分な分量のリソースをコンテナに対して「予約」（requests ）することを通じて、当該のコンテナが属するPodのQoS Classを高めることが出来る。

Priority Class

リソース逼迫をクラスタ単位で解消するための、Preemption実装を機能させるために用いられる。
Priority ClassはPodに対して明示的に指定しなければならない。

对于在Kubernetes基础架构中进行资源管理的要点（面向VMware基础架构的建设和运维经验者）是什么？

将本文提供的4个速查表中获得的洞察作为Kubernetes基础设施中资源管理的要点总结，专为具有VMware基础设施建设和运维经验的人员提供（其中与Kubernetes基础设施和VMware基础设施之间的差异点将以加粗形式描述）。

    1. 在核心的资源管理中，Kubernetes基础架构可以使用与VMware基础架构相同的概念，即“预留”和“上限”，来分配CPU周期和内存容量到容器中。

 

    1. 由于Kubernetes基础架构当前缺乏I/O资源控制的手段，在配置高I/O负载工作负载时需要考虑。

 

    1. 在Kubernetes产品中，积极地进行功能扩展以实现自主扩展和升级操作。

 

    1. 即使在Kubernetes基础架构中，将资源分配给计算实例（容器和虚拟机）的运维操作也几乎可以使用与VMware基础架构相同的感觉来实现。

 

    1. 由于Kubernetes基础架构默认会自动进行类似于VMware基础架构中的“通过DRS实现的自动配置”，因此必须进行系统设计（例如：Inter-Pod Affinity设计）以控制自主容器配置。

 

    在应对资源紧缺时，Kubernetes基础架构倾向于通过强制终止优先级较低（QoS Class/Priority Class）的容器来回收资源，因此在关注系统可用性时需要注意。

在上述的1.至6.中，特别突出的是Kubernetes基础架构和VMware基础架构之间的差异，即点3、点5和点6。因此，有经验的VMware基础架构（或类似的虚拟化基础架构）的实施和运维人员在参与Kubernetes基础架构的生产运营时，需要重视以下三个实施概念的掌握。

    • 自律的なスケールアウト/スケールアップ運用（まずは、Horizontal Pod Autoscalerへの対応）

kube-scheduler実装によるノード配置の最適化

Eviction Policy、およびPreemption実装による優先度が低いコンテナからのリソース回収

尤其是Kubernetes基础架构中独特的实现方式，即旨在将资源分配自主优化的容器强制停止，需要注意其在“基础资源利用效率”和“容器运行可用性/稳定性”之间存在着不可忽视的权衡关系。

推荐书籍

我认为，在短时间内系统地获取知识的情况下，参考书籍也是有效的。然而，从本文作者手上的一些书籍来看，有许多书籍没有涉及或没有给予足够的篇幅来谈论资源管理的情况。因此，关于资源管理，下面是（本文作者手上的）一些推荐书籍中有相关描述的介绍。

Kubernetes完全ガイド (impress top gear)

書籍自体の内容については、以下の記事で紹介されています。

書評「Kubernetes完全ガイド」Kubernetesを学ぶ全ての人にオススメしたい ｜ DevelopersIO

Kubernetes in Action

洋書、かつ、そこそこのお値段がする書籍ではありますが、O’Reillyが参加する電子書籍読み放題サービスであるSafari Book Onlineよりアクセス出来るため、会員の方はどうぞ。
書籍自体の内容については、以下のブログ記事で紹介されています。

Kubernetes in Actionの個人的なまとめ – 世界中の羊をかき集めて

与本文解读相关的Qiita文章列表

以下是与本文解释内容相关的Qiita文章列表20。

在Kubernetes基础设施中对资源进行预留和限制设置（requests/limits）。

    • KubernetesのResource RequestsとResource Limitsについて – Qiita

 

    【第四弾】Kubernetesベストプラクティス：Requests & Limits – Qiita

在 Kubernetes 环境中实施 GPU 资源管理。

    • Kubernetes on NVIDIA GPUsとは – Qiita

 

    • KubernetesからGPUを使ってTensorflowを動かす

 

    • Initializersを使ってK8s + NVIDIA device pluginでの意図しないGPUの割当を防止してみる – Qiita

 

    Kubernetes on NVIDIA GPUsをEC2上に構築してみる – Qiita

在Kubernetes环境下实现自动扩展/升级运维。

    • KubernetesのPodとNodeのAuto Scalingについて – Qiita

 

    • Kuberentes の水平オートスケール – Qiita

 

    • KubernetesでDatadog + Horizontal Pod Autoscalerをやってみた – Qiita

 

    • GKE + k8s オートスケールの設定方法 – Qiita

 

    • Kubernetes の垂直オートスケール – Qiita

 

    • GKEがVertical Pod Autoscalerに対応したらしいので調査した – Qiita

 

    • Kuberentes クラスタのオートスケール – Qiita

 

    GKEでPodとNodeをAutoscaling する – Qiita

将资源分配和运营委托给Kubernetes基础设施。

    KubernetesのResourceQuotaの動作確認 – Qiita

在Kubernetes基础设施上将容器部署到节点上。

    • Kubernetes: スケジューラの動作 – Qiita

 

    • kube-schedulerのソースコードを読みながらPodがNodeにBindされるまでを理解する – Qiita

 

    • KubernetesのNode Affinity, Inter-Pod Affinityについて – Qiita

 

    • KubernetesのTaintsとTolerationsについて – Qiita

 

    Kubernetes: Kubernetes Descheduler とは – Qiita

本文中提到的「VMware基盤」指的是使用VMware vSphere产品构建的系统基础设施（从准确性的观点来看，称为vSphere基础设施可能更为恰当，但为了易懂性而选择了VMware基础设施）。

Kubernetes v1.14中的Feature State是Beta（本地临时存储）。

通过插件可以扩展可管理的资源类型（参见Extended resources）。同时，还存在计划以扩展将来可管理的资源类型（参见Kubernetes资源模型）。

在Kubernetes基础设施中，当CPU资源紧张时，可以通过requests值的比例来确定为每个容器分配多余的CPU资源（类似于在VMware基础设施中使用“share”进行运营）。而关于内存容量似乎没有提供类似的实现。

例如，可以尝试使用docker run命令中的–cpuset-cpus限制来强制执行类似亲和性的实现，但尚未经检验。

每个实现的概述都在《VMware Horizon View 7》文档中列出（虽然是针对VMware Horizon View产品的文档）。

具体实现例子包括“https://github.com/NVIDIA/k8s-device-plugin”和“AMD GPU device plugin for Kubernetes”（参见调度GPU – Kubernetes）。

似乎将网络I/O和存储I/O视为“未来资源类型”进行资源管理。

竖向Pod自动缩放功能在本文撰写时仍属于Beta版本。

为了使用群集自动缩放功能，需要将Kubernetes集群部署在与该功能兼容的云基础设施上。

具体列表请参考产品文档。

“资源分配”的表达虽然有些复杂，但它指的是委托给用户的资源分配者限制了他们可以分配给某个计算实例（容器或虚拟机）的资源上限（或下限）。

有关功能的具体内容，请参阅产品文档（适用于CPU的设置和适用于内存的设置）。

vSphere基础设施在设置完成后默认情况下不包含DRS集群（将其表示为“禁用的默认状态”）。

这篇文章描述了根据Git文档“Scheduler Algorithm in Kubernetes”的描述内容以及根据产品源代码“least_requested.go”的作者对其的理解。

具体操作示例包括根据节点可用性级别来控制容器部署位置（例如：将支持重要业务的容器安置在可用性较高的节点上）。

具体操作示例包括将紧密协作的容器集中部署在同一节点上以提高性能，或将并行运行的容器分散部署在不同节点上以确保可用性。

Kubernetes产品文档中也进行了解释，以避免用户的混淆（参见Pod优先级和QoS的相互作用）。

基础设施资源紧缺导致容器被强制终止并重新生成，从而使节点负载平均化的情况是存在的。但是，这只是一个次要的现象，因此在Kubernetes基础设施中不可以判断该文章作者认为Kubernetes基础设施具备“自主地平衡节点负载的容器部署后实施”的实现能力。在考虑kube-scheduler在进行容器自动部署时没有考虑节点负载状况（例如：各Docker主机的CPU使用率）的情况下，可以认为在容器生成/销毁不频繁的环境中，集群节点之间的资源利用情况可能存在不平衡的问题。同时，似乎也有计划扩展功能来弥补Kubernetes基础设施的这些弱点（参见用于Kubernetes的Descheduler）。

✖
广告
将在 10 秒后关闭
bannerAds