kubestronautへの道 ~CKAD編 その4~

tech article
2024.07.15

本記事の内容

前回に引き続いてUdemyのKubernetes Certified Application Developer (CKAD) with Testsというコースを受講していた中で気になったところをメモしていきます。

今回は以下のセクションに基づいています

#8 State Persistet

勉強記

Persistent Volume/Persistent Volume Claim

永続ボリューム
このドキュメントではKubernetesの PersistentVolume について説明します。ボリュームを一読することをおすすめします。 概要 ストレージを管理することはインスタンスを管理することとは全くの別物です。PersistentVolumeサブシステムは、ストレージが何から提供されているか、どのように消費さ...
kubernetes.io

PersistentVolume (PV)

管理者によって手動でプロビジョニングされたり、Storage Classを利用して動的にプロビジョニングされるクラスターのストレージの一部。
ノードと同じレイヤーのクラスターリソースである。

Podにアタッチして使用されるが、Podとは独立したライフサイクルを持つ。
名前はケバブケースで指定しなければならない。

PersistentVolumeClaim (PVC)

クラスター内で使用可能なストレージ。
実際にはPodとPVの仲介役だが、PVがPodにアタッチできる形になったもの、と考える方がわかりやすい。
Podと対比すると以下のようになる。

  • PodはNodeリソースを消費する一方で、PVCはPVリソースを消費する。
  • Podは特定レベルのCPUとメモリーリソースを要求する一方で、PVCは特定のサイズやアクセスモード(例えば、ReadWriteOnce、ReadOnlyMany、ReadWriteMany)を要求できる。

サイズやアクセスモードよりも詳細にPVの内容を指定したい場合にはStorage Classを用いる。
名前はケバブケースで指定しなければならない。

PVCの削除ルール

  • PVCがPodによって実際に使用されている場合、PVCを削除してもそのPVCはすぐには削除されない(できない)。
  • PVCの削除は、PVCがPodで使用されなくなるまで延期される。
  • 管理者がPVCに紐付けられているPVを削除しても、PVはすぐには削除されない（できない）。
  • PVがPVCに紐付けられなくなるまで、PVの削除は延期される。

→使ってるリソース(PV, PVC)は、すぐには消すことはできなくて、使用されなくなったら消える

ライフサイクル

静的プロビジョニングと動的プロビジョニングが存在する。

静的プロビジョニングは、PVを作成し、それに該当するPVCを作成する、という方式である。
動的プロビジョニングは、PVが存在しなくてもPVC用にボリュームを作成する、という方式である。

動的プロビジョニングを使用するには以下を満たす必要がある。

  • PVCのマニフェストファイル内でstorageClassを指定する
  • PVCで指定したstorageClassが存在する
  • DefaultStorageClassアドミッションコントローラーをAPIサーバーで有効化する

Storage Class

ストレージクラス
このドキュメントでは、KubernetesにおけるStorageClassの概念について説明します。ボリュームと永続ボリュームに精通していることをお勧めします。 概要 StorageClassは、管理者が提供するストレージの「クラス」を記述する方法を提供します。さまざまなクラスが、サービス品質レベル、バックアップポリシ...
kubernetes.io

PVCでは指定しきれないボリュームの設定を一つのまとまりとして指定するリソース。
他のストレージシステムでは「プロファイル」と呼ばれるものに相当する。らしい。

ボリュームの動的プロビジョニング(Dynamic Volume Provisioning)

storageClassを作成し、PVCでstorageClassを指定することで動的プロビジョニングが可能となる。

storageClass内では少なくともprovisonerとparametersを指定する必要がある。
PVCではsttorageClassNameとして指定する。
例：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 30Gi

Stateful set

ほぼDeploymentといってよい。

相違点として、podの起動順序を指定できる、podの識別子を一意に割り当てられてpodが再起動しても同じ識別子を利用できる、などがある。

ステートレスなアプリはDeploymentを、ステートフルなアプリはStatefulSetを利用するのがベストプラクティス(名前の通り。)

タイトルとURLをコピーしました