Clusterリソースは、Kubernetesのクラスタを構成するリソースです。主には、クラスタの管理者が利用します。Node、Namespace、PersistentVolumeなど多岐に渡ります。

管理単位やセキュリティやリソース制限など、目的別に代表的なものについて、紹介します。リソースを定義するYAMLの記述方法の詳細はAPIドキュメントを参照ください。

リソースタイプ (再掲)

管理単位(Node/Namespace)

クラスタ内の管理単位であるNodeとNamespaceを紹介します。

クラスタにおけるNodeとNamespaceのイメージ

PodはNode上で動作します。物理サーバにおける筐体や、仮想サーバのノードをイメージすると良いでしょう。Nodeにはkubeletと呼ばれるPodを管理するエージェントや、kind-proxyと呼ばれるServiceへのアクセスを管理するプロセスなどが存在します。

Nodeを取得してみましょう。[minikube]という名前のNodeが存在することがわかります。

$kubectl get node
NAME       STATUS   ROLES    AGE     VERSION
minikube   Ready    master   6d20h   v1.14.0

Namespaceを分けることで、独立した環境を準備することができます。開発環境と本番環境、システムAとBといった形で、分離すると良いでしょう。

[my-namespace]をという名前でNamespaceを作ってみます。作成したNamespaceは[kubectl get namespace]で取得することができます。

$kubectl create namespace my-namespace
namespace/my-namespace created

$kubectl get namespace
NAME              STATUS   AGE
default           Active   6d21h
kube-node-lease   Active   6d21h
kube-public       Active   6d21h
kube-system       Active   6d21h
my-namespace      Active   34s

RBACによるセキュリティ管理

RBAC(Role Based Access Control)はその名の通り、ロールベースでのアクセス制御を実現する仕組みです。以下の4つのリソースを中心に構成されます(全体像は下図)。

  • Role
  • RoleBinding
  • ClusterRole
  • ClusterRoleBinding

リソース間の関係性

ロールにはNamespace単位で定義されるRoleやクラスタ単位で定義されるClusterRoleがあり、RoleBindingやClusterRoleBindingを使ってユーザ/グループ、ServiceAccountに紐付けます。

割り当てる単位としては、ClusterRoleBindingを利用してクラスター全体に付与したり、RoleBindingを利用して特定のネームスペースに割り当てることができます。 ユーザ/グループが人が利用するものに対し、ServiceAccountはPod内のプロセスが利用します。

PodSecurityPolicyはクラスタのセキュリティポリシーを定義するリソースです。例えば以下の設定が可能で、セキュリティレベルの低いPodの作成をクラスタレベルで防ぐことができます。

  • 特権実行の可否
  • 許可するユーザ・グループの指定
  • アクセスするボリューム・パス・ポートの指定

※ Metadataリソースタイプですが、関連性が高いのでここで説明します。

マシンリソース割当管理

リソース割当を管理する方法として、ResourceQuotaによるCPU/メモリ/ストレージなどのリソース制限、 LimitRangeよるリソースのデフォルト値の設定、QoSクラスなどがあります。

※ Metadataリソースタイプですが、関連性が高いのでここで説明します。

マシンリソースの割当例

ResourceQuotaでは以下の項目に対する制限を与えることができます。resource.requestはNamespaceおよびPodに割り当てるリソース量を定義し、resource.limitはNamespaceおよびPodに割り当てるリソースの上限を定義します。

ReplicaSetのreplica数を10とし、ResourceQuotaによりNamespaceに1GB、resource.request/limitによりPodに300MBを割り当てた場合を想定します。結果として、resource.requestは300MBをPodに割り当て、Podを3つ作った時点でこれ以上余りがないため作成をストップします。resource.limitの方は、あくまでResourceQuota(1GB)/replica数(10)である100MBを割り当てつつも、設定した300MBを前提としたPod数(1GB/300MB)を作成します。

表 : resource.requestとresource.limitの挙動の違い

Podへの割当メモリ 作成Pod数
resource.request(300MB) 300MB 3
resource.limit(300MB) 100MB(1GB/replica数) 3

LimitRangeを使用するとPodやContainerなどに対し、CPUやメモリの最小最大・デフォルト値を指定することができます。個別のPodなどにresource.limitやresource.requestを設定しなかった場合のデフォルト値や、個別のPodなどに極端に大きなマシンリソースを割り当てることを防ぎます。

表 : LimitRange

項目 説明
(k8sの)リソースタイプ Pod/Container/PersistentVolumeClaim
マシンリソース CPU/メモリ
resource.requestとresource.limitの設定値 最大値/最小値/デフォルト/resource.limitとresource.requestの比率

QoSクラスについて説明します。Kubernetesはマシンリソースを超えたリソースを割当可能です。従って、超えた部分について、どのPodに優先割当するか、またはPodを削除する必要があるかを決定する必要があります。その際に利用されるのがQoSクラスです。優先度が高いものから以下の3つがあります 。resource.limit/requestの設定状況によって割り当てられるQoSクラスが決定されます。

  • Guaranteed (CPU・メモリ共にresource.limit/requestが設定されている、かつlimit=requestである)
  • Burstable (CPU・メモリ共のいずれかがresource/requestが設定されている)
  • BestEffort (上記条件に当てはまらない)

*  *  *

今回はClusterリソースについて説明しました。NodeとNamespaceの概念を理解いただいた上で、RBACによるアクセス制御をご理解いただきました。また、併せてClusterにおけるCPUなどのリソース制御についてご理解いただきました。

次回はリソースタイプのMetadataを紹介します。

著者紹介


正野 勇嗣 (SHONO Yuji ) - NTTデータ 課長

2011年まで開発自動化技術のR&Dに従事。その後、開発プロジェクト支援やトラブルシューティング等に主戦場を移す。「ソースコード自動生成」に加えて、JenkinsやMaven等の「ビルド自動化」、JsTestDriverやSelenium等の「テスト自動化」を扱うようになり、多様化する開発自動化技術動向に興味。

最近は第四の自動化であるInfrastructure as Code等の「基盤自動化」の魅力に惹かれている。開発自動化技術に関する雑誌・記事執筆も行う。3児のパパ。