Kubernetesのリソースタイプを体系的に学ぶ - Cluster

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

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

 

管理単位(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の作成をクラスタレベルで防ぐことができます。

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

マシンリソース割当管理

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

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を紹介します。