【Kubernetes初めの一歩】リソースざっくりまとめ

2021.10.06
2024.03.24
Kubernetes
DeploymentNodePodReplicaSet

はじめに

Kubernetesを勉強していて、Kubernetesのリソースが多くどれがなんだかわからなくなるので、ざっくりまとめてみました。

unknown link

アルファベット順に並べています。

ConfigMap

機密性のない設定ファイルを定義して、Podへ提供します。

環境変数やコマンドライン引数などをコンテナから分離できます。

ConfigMap

ConfigMap

ConfigMapは、 機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクトです。Podは、環境変数、コマンドライン引数、またはボリューム内の設定ファイルとしてConfigMapを使用できます。 ConfigMapを使用すると、環境固有の設定をコンテナイメージから分離できるため、アプリケーションを簡単に移植できるようになります。 注意:ConfigMapは機密性や暗号化を提供しません。保存したいデータが機密情報である場合は、ConfigMapの代わりにSecretを使用するか、追加の(サードパーティー)ツールを使用してデータが非公開になるようにしてください。 動機 アプリケーションのコードとは別に設定データを設定するには、ConfigMapを使用します。 たとえば、アプリケーションを開発していて、(開発用時には)自分のコンピューター上と、(実際のトラフィックをハンドルするときは)クラウド上とで実行することを想像してみてください。あなたは、DATABASE_HOSTという名前の環境変数を使用するコードを書きます。ローカルでは、この変数をlocalhostに設定します。クラウド上では、データベースコンポーネントをクラスター内に公開するKubernetesのServiceを指すように設定します。 こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。 ConfigMapは、大量のデータを保持するようには設計されていません。ConfigMapに保存されるデータは1MiBを超えることはできません。この制限を超える設定を保存する必要がある場合は、ボリュームのマウントを検討するか、別のデータベースまたはファイルサービスを使用することを検討してください。 ConfigMapオブジェクト ConfigMapは、他のオブジェクトが使うための設定を保存できるAPIオブジェクトです。ほとんどのKubernetesオブジェクトにspecセクションがあるのとは違い、ConfigMapにはdataおよびbinaryDataフィールドがあります。これらのフィールドは、キーとバリューのペアを値として受け入れます。dataフィールドとbinaryDataフィールドはどちらもオプションです。dataフィールドはUTF-8バイトシーケンスを含むように設計されていますが、binaryDataフィールドはバイナリデータを含むように設計されています。 ConfigMapの名前は、有効なDNSのサブドメイン名でなければなりません。 dataまたはbinaryDataフィールドの各キーは、英数字、-、_、または.で構成されている必要があります。dataに格納されているキーは、binaryDataフィールドのキーと重複することはできません。 v1.19以降、ConfigMapの定義にimmutableフィールドを追加して、イミュータブルなConfigMapを作成できます。 ConfigMapとPod ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodのspecを書くことができます。このとき、PodとConfigMapは同じ名前空間内に存在する必要があります。 以下に、ConfigMapの例を示します。単一の値を持つキーと、Configuration形式のデータ片のような値を持つキーがあります。 apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: # プロパティーに似たキー。各キーは単純な値にマッピングされている player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" # ファイルに似たキー game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。 コンテナ内のコマンドと引数 環境変数をコンテナに渡す 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する これらのさまざまな方法は、利用するデータをモデル化するのに役立ちます。最初の3つの方法では、kubeletがPodのコンテナを起動する時にConfigMapのデータを使用します。 4番目の方法では、ConfigMapとそのデータを読み込むためのコードを自分自身で書く必要があります。しかし、Kubernetes APIを直接使用するため、アプリケーションはConfigMapがいつ変更されても更新イベントを受信でき、変更が発生したときにすぐに反応できます。この手法では、Kubernetes APIに直接アクセスすることで、別の名前空間にあるConfigMapにもアクセスできます。 以下に、Podを設定するためにgame-demoから値を使用するPodの例を示します。 apiVersion: v1 kind: Pod metadata: name: configmap-demo-pod spec: containers: - name: demo image: alpine command: ["sleep", "3600"] env: # 環境変数を定義します。 - name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い # 大文字が使われていることに着目してください。 valueFrom: configMapKeyRef: name: game-demo # この値を取得するConfigMap。 key: player_initial_lives # 取得するキー。 - name: UI_PROPERTIES_FILE_NAME valueFrom: configMapKeyRef: name: game-demo key: ui_properties_file_name volumeMounts: - name: config mountPath: "/config" readOnly: true volumes: # Podレベルでボリュームを設定し、Pod内のコンテナにマウントします。 - name: config configMap: # マウントしたいConfigMapの名前を指定します。 name: game-demo # ファイルとして作成するConfigMapのキーの配列 items: - key: "game.

CronJob

Cron形式で指定したスケジュールで実行されるJobです。

unknown link

Deployment

ReplicaSetを管理します。

DeploymentはReplicaSetを管理することでPodを制御します。

Deployment

Deployment

Deployment はPodとReplicaSetの宣言的なアップデート機能を提供します。 Deploymentにおいて 理想的な状態 を記述すると、Deploymentコントローラーは指定された頻度で現在の状態を理想的な状態に変更します。Deploymentを定義することによって、新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用できます。 備考:Deploymentによって作成されたReplicaSetを管理しないでください。ご自身のユースケースが以下の項目に含まれない場合、メインのKubernetesリポジトリーにIssueを作成することを検討してください。 ユースケース 以下の項目はDeploymentの典型的なユースケースです。 ReplicaSetをロールアウトするためにDeploymentの作成を行う: ReplicaSetはバックグラウンドでPodを作成します。Podの作成が完了したかどうかは、ロールアウトのステータスを確認してください。 DeploymentのPodTemplateSpecを更新することによりPodの新しい状態を宣言する: 新しいReplicaSetが作成され、Deploymentは指定された頻度で古いReplicaSetから新しいReplicaSetへのPodの移行を管理します。新しいReplicaSetはDeploymentのリビジョンを更新します。 Deploymentの現在の状態が不安定な場合、Deploymentのロールバックをする: ロールバックによる各更新作業は、Deploymentのリビジョンを更新します。 より多くの負荷をさばけるように、Deploymentをスケールアップする。 PodTemplateSpecに対する複数の修正を適用するためにDeploymentを停止(Pause)し、それを再開して新しいロールアウトを開始します。 Deploymentのステータス をロールアウトが失敗したサインとして利用する。 今後必要としない古いReplicaSetのクリーンアップ Deploymentの作成 以下はDeploymentの例です。これはnginxPodのレプリカを3つ持つReplicaSetを作成します。 controllers/nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 この例では、 .metadata.nameフィールドで指定されたnginx-deploymentという名前のDeploymentが作成されます。 このDeploymentは.spec.replicasフィールドで指定された通り、3つのレプリカPodを作成します。 .spec.selectorフィールドは、Deploymentが管理するPodのラベルを定義します。ここでは、Podテンプレートにて定義されたラベル(app: nginx)を選択しています。しかし、PodTemplate自体がそのルールを満たす限り、さらに洗練された方法でセレクターを指定することができます。 備考:`.spec.selector.matchLabels`フィールドはキーバリューペアのマップです。 `matchLabels`マップにおいて、{key, value}というペアは、keyというフィールドの値が"key"で、その演算子が"In"で、値の配列が"value"のみ含むような`matchExpressions`の要素と等しくなります。 `matchLabels`と`matchExpressions`の両方が設定された場合、条件に一致するには両方とも満たす必要があります。 templateフィールドは、以下のサブフィールドを持ちます。: Podは.metadata.labelsフィールドによって指定されたapp: nginxというラベルがつけられます。 PodTemplate、または.template.specフィールドは、Podがnginxという名前でDocker Hubにあるnginxのバージョン1.14.2が動くコンテナを1つ動かすことを示します。 1つのコンテナを作成し、.

Ingress

Serviceに対する外部からのアクセスを制御します。

unknown link

Job

常駐ではない、正常終了することが保証しているPodの集合です。

unknown link

Namespace

Kubernetesクラスターで作成される仮想的なクラスターです。

Namespace(名前空間)

Namespace(名前空間)

Kubernetesは、同一の物理クラスター上で複数の仮想クラスターの動作をサポートします。 この仮想クラスターをNamespaceと呼びます。 複数のNamespaceを使う時 Namespaceは、複数のチーム・プロジェクトにまたがる多くのユーザーがいる環境での使用を目的としています。 数人から数十人しかユーザーのいないクラスターに対して、あなたはNamespaceを作成したり、考える必要は全くありません。 Kubernetesが提供するNamespaceの機能が必要となった時に、Namespaceの使用を始めてください。 Namespaceは名前空間のスコープを提供します。リソース名は単一のNamespace内ではユニークである必要がありますが、Namespace全体ではその必要はありません。Namespaceは相互にネストすることはできず、各Kubernetesリソースは1つのNamespaceにのみ存在できます。 Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これはリソースクォータを介して分割します。) 同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。 同一のNamespace内でリソースを区別するためにはラベルを使用してください。 Namespaceを利用する Namespaceの作成と削除方法はNamespaceの管理ガイドドキュメントに記載されています。 備考:プレフィックスkube-を持つNamespaceは、KubernetesシステムのNamespaceとして予約されているため利用は避けてください。 Namespaceの表示 ユーザーは、以下の方法で単一クラスター内の現在のNamespaceの一覧を表示できます。 kubectl get namespace NAME STATUS AGE default Active 1d kube-node-lease Active 1d kube-system Active 1d kube-public Active 1d Kubernetesの起動時には4つの初期Namespaceが作成されています。 default 他にNamespaceを持っていないオブジェクトのためのデフォルトNamespace kube-system Kubernetesシステムによって作成されたオブジェクトのためのNamespace kube-public このNamespaceは自動的に作成され、全てのユーザーから読み取り可能です。(認証されていないユーザーも含みます。) このNamespaceは、リソースをクラスター全体を通じてパブリックに表示・読み取り可能にするため、ほとんどクラスターによって使用される用途で予約されます。 このNamespaceのパブリックな側面は単なる慣例であり、要件ではありません。 kube-node-lease クラスターのスケールに応じたノードハートビートのパフォーマンスを向上させる各ノードに関連したLeaseオブジェクトのためのNamespace。 Namespaceの設定 現在のリクエストのNamespaceを設定するには、--namespaceフラグを使用します。 例: kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here> kubectl get pods --namespace=<insert-namespace-name-here> Namespace設定の永続化 ユーザーはあるコンテキストのその後のコマンドで使うために、コンテキスト内で永続的にNamespaceを保存できます。 kubectl config set-context --current --namespace=<insert-namespace-name-here> # Validate it kubectl config view --minify | grep namespace: NamespaceとDNS ユーザーがServiceを作成するとき、Serviceは対応するDNSエントリを作成します。 このエントリは<service-name>.

Node

コンテナを配置するためのPodを実行する1つのVMまたは物理マシンです。

unknown link

PersistentVolume

永続ボリュームそのものを定義します。

unknown link

PersistentVolumeClaim

実際に使うボリュームを要求します。

unknown link

Pod

コンテナの集合体で、コンテナを実行する方法を定義します。

unknown link

ReplicaSet

同じ仕様のPodを複数生成、管理します。

ReplicaSet

ReplicaSet

ReplicaSetの目的は、どのような時でも安定したレプリカPodのセットを維持することです。これは、理想的なレプリカ数のPodが利用可能であることを保証するものとして使用されます。 ReplicaSetがどのように動くか ReplicaSetは、ReplicaSetが対象とするPodをどう特定するかを示すためのセレクターや、稼働させたいPodのレプリカ数、Podテンプレート(理想のレプリカ数の条件を満たすために作成される新しいPodのデータを指定するために用意されるもの)といったフィールドとともに定義されます。ReplicaSetは、指定された理想のレプリカ数にするためにPodの作成と削除を行うことにより、その目的を達成します。ReplicaSetが新しいPodを作成するとき、ReplicaSetはそのPodテンプレートを使用します。 ReplicaSetがそのPod群と連携するためのリンクは、Podのmetadata.ownerReferencesというフィールド(現在のオブジェクトが所有されているリソースを指定する)を介して作成されます。ReplicaSetによって所持された全てのPodは、それらのownerReferencesフィールドにReplicaSetを特定する情報を保持します。このリンクを通じて、ReplicaSetは管理しているPodの状態を把握したり、その後の実行計画を立てます。 ReplicaSetは、そのセレクターを使用することにより、所有するための新しいPodを特定します。もしownerReferenceフィールドの値を持たないPodか、ownerReferenceフィールドの値が コントローラーでないPodで、そのPodがReplicaSetのセレクターとマッチした場合に、そのPodは即座にそのReplicaSetによって所有されます。 ReplicaSetを使うとき ReplicaSetはどんな時でも指定された数のPodのレプリカが稼働することを保証します。しかし、DeploymentはReplicaSetを管理する、より上位レベルの概念で、Deploymentはその他の多くの有益な機能と共に、宣言的なPodのアップデート機能を提供します。それゆえ、我々はユーザーが独自のアップデートオーケストレーションを必要としたり、アップデートを全く必要としないような場合を除いて、ReplicaSetを直接使うよりも代わりにDeploymentを使うことを推奨します。 これは、ユーザーがReplicaSetのオブジェクトを操作する必要が全く無いことを意味します。 代わりにDeploymentを使用して、specセクションにユーザーのアプリケーションを定義してください。 ReplicaSetの使用例 controllers/frontend.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: frontend labels: app: guestbook tier: frontend spec: # ケースに応じてレプリカを修正する replicas: 3 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: php-redis image: gcr.io/google_samples/gb-frontend:v3 上記のマニフェストをfrontend.yamlファイルに保存しKubernetesクラスターに適用すると、マニフェストに定義されたReplicaSetとそれが管理するPod群を作成します。 kubectl apply -f http://k8s.io/examples/controllers/frontend.yaml ユーザーはデプロイされた現在のReplicaSetの情報も取得できます。 kubectl get rs そして、ユーザーが作成したfrontendリソースについての情報も取得できます。 NAME DESIRED CURRENT READY AGE frontend 3 3 3 6s ユーザーはまたReplicaSetの状態も確認できます。 kubectl describe rs/frontend その結果は以下のようになります。

Secret

認証情報などの機密情報を定義し、Podから参照できるようにします。

unknown link

Service

アプリケーションとして実行されているPodの集合にアクセスする経路を定義します。

unknown link

StatefulSet

データストアのような状態を保持する(ステートフルな)Podを複数生成、管理します。

StatefulSet

StatefulSet

StatefulSetはステートフルなアプリケーションを管理するためのワークロードAPIです。 StatefulSetはPodのデプロイとスケーリングを管理し、それらのPodの順序と一意性を保証します。 Deploymentのように、StatefulSetは指定したコンテナのspecに基づいてPodを管理します。Deploymentとは異なり、StatefulSetは各Podにおいて管理が大変な同一性を維持します。これらのPodは同一のspecから作成されますが、それらは交換可能ではなく、リスケジュール処理をまたいで維持される永続的な識別子を持ちます。 ワークロードに永続性を持たせるためにストレージボリュームを使いたい場合は、解決策の1つとしてStatefulSetが利用できます。StatefulSet内の個々のPodは障害の影響を受けやすいですが、永続化したPodの識別子は既存のボリュームと障害によって置換された新しいPodの紐付けを簡単にします。 StatefulSetの使用 StatefulSetは下記の1つ以上の項目を要求するアプリケーションにおいて最適です。 安定した一意のネットワーク識別子 安定した永続ストレージ 規則的で安全なデプロイとスケーリング 規則的で自動化されたローリングアップデート 上記において安定とは、Podのスケジュール(または再スケジュール)をまたいでも永続的であることと同義です。 もしアプリケーションが安定したネットワーク識別子と規則的なデプロイや削除、スケーリングを全く要求しない場合、ユーザーはステートレスなレプリカのセットを提供するワークロードを使ってアプリケーションをデプロイするべきです。 DeploymentやReplicaSetのようなコントローラーはこのようなステートレスな要求に対して最適です。 制限事項 提供されたPodのストレージは、要求されたstorage classにもとづいてPersistentVolume Provisionerによってプロビジョンされるか、管理者によって事前にプロビジョンされなくてはなりません。 StatefulSetの削除もしくはスケールダウンをすることにより、StatefulSetに関連したボリュームは削除されません 。 これはデータ安全性のためで、関連するStatefulSetのリソース全てを自動的に削除するよりもたいてい有効です。 StatefulSetは現在、Podのネットワークアイデンティティーに責務をもつためにHeadless Serviceを要求します。ユーザーはこのServiceを作成する責任があります。 StatefulSetは、StatefulSetが削除されたときにPodの停止を行うことを保証していません。StatefulSetにおいて、規則的で安全なPodの停止を行う場合、削除のために事前にそのStatefulSetの数を0にスケールダウンさせることが可能です。 デフォルト設定のPod管理ポリシー (OrderedReady)によってローリングアップデートを行う場合、修復のための手動介入を要求するようなブロークンな状態に遷移させることが可能です。 コンポーネント 下記の例は、StatefulSetのコンポーネントのデモンストレーションとなります。 apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: selector: matchLabels: app: nginx # .spec.template.metadata.labelsの値と一致する必要があります serviceName: "nginx" replicas: 3 # by default is 1 template: metadata: labels: app: nginx # .

参考

Support

\ この記事が役に立ったと思ったら、サポートお願いします! /

buy me a coffee
Share

Profile

author

Masa

都内のIT企業で働くエンジニア
自分が学んだことをブログでわかりやすく発信していきながらスキルアップを目指していきます!

buy me a coffee