Kubernetesの基礎知識をおさらい

10月 11, 2023

どもども。ランニング用にキャップを購入したsaisaiです。やっと涼しくなってきそうですね!


今回はkubernetesの基礎要素を総復習してみようの記事です。


過去にkubernetesに関する一通りの要素を記事にしたのですが、その頃はまだDocker自体に馴染みがなかったり、docker-composeなども全然わからないまま記事にしていました。


ここ最近やっとDockerと仲良くなってきたので、この状態でもう一度kubernetesについて復習し、理解を深めていきたいと思います。

Pod

まずはPodについてみていきます。


過去に作成した記事は以下です。こちらにはPodを起動するためのサンプルマニフェストファイルもあります。
【Kubernetesリソースシリーズ第一弾】Podについて知る!


Podとは、kubernetesの同一環境におけるDockerコンテナの最小集合単位です。


では、同一環境とは一体なんでしょうか。Pod内のコンテナは主に二つのリソースを共有しています。

・ネットワーキング
IPアドレスはPod単位で与えられます。他にもポートなどのネットワークリソースを共有しています。
Pod内のコンテナ達はlocalhostで通信可能です。
・ストレージ
Pod内のコンテナは共有ストレージを利用することが可能です。この共有ストレージを利用することでデータを永続化させることができます。


このように複数のコンテナを同一環境に配置し稼働できるkubernetes上の最小単位がPodとなります。

Replicaset


次にReplicasetについてみてみましょう。


過去に作成した記事は以下です。
【Kubernetesリソースシリーズ第二弾】Replicasetについて知る!


Replicasetとは、コンテナの集合体であるPodをさらに集合体にしたものです。PodをスケールするなどPod単位の操作を行うことが可能です。


マニフェストファイルでいえばこの部分

spec:
  replicas: 3

のようにするとPodを3つ作成できます。


この値を変更して再度ファイルを実行することでPodをスケールイン、スケールアウトできます。


他にも、何らかの理由でPodが停止した際に再起動をすることができたりとPodを運用する上で欠かせない要素です。

Deployment

次はDeploymentについて確認してみます。

Deploymentの過去の記事については以下です。
【Kubernetesリソースシリーズ第三弾】Deploymentについて知る!


DeploymentはReplicasetの管理を行うものです。ローリングアップデートやロールバックといった世代管理やデプロイにおいて欠かせない要素となります。


例えばマニフェストファイルで以下のように指定することでReplicasetを2つ作成できます。

spec:
  replicas: 2

また以下の部分を指定するとReplicasetの状態を指定世代数まで保存できます。

revisionHistoryLimit: 14 

管理しているReplicaset配下にあるPodのデプロイ方法を指定することもできます。

 strategy: 
    type: RollingUpdate 
   rollingUpdate:
      maxSurge: 1 #レプリカ数を超えて良いPod数
      maxUnavailable: 1 #一度に消失しても良いPod数

Replicasetの管理に使用する要素であることがわかります。


マニフェストファイルを起動した後はkubectlコマンドで世代を確認したり、ロールバックすることが可能です。

Service

続いてはServiceについてです。


過去の記事は以下です。
【Kubernetesリソースシリーズ第四弾】Serviceについて知る!


先ほど説明した通り、Pod内のコンテナはlocalhostでそれぞれ接続できます。では異なるPod、もっと言えば異なるNodeに存在するPod同士はどのように接続するのでしょうか。


確かにPodはそれぞれ共有のIPアドレスを保有しています。これはNodeも同じです。しかし、K8sの特性上、NodeのIPアドレスは一定ではなかったり、大量のPodそれぞれのIPを生真面目にしていて接続するのはナンセンスです。


そこで登場するのがServiceです。要するにPodのさらに外側の通信を制御します。


例えばマニフェストファイルで以下のように設定したとします。

spec:
  type: NodePort 
  selector: 
    app: web
    env: study
  ports: 
  - port: 80 
    targetPort: 80
    nodePort: 30000 

selectorはどのPodのエンドポイント (通信口)を作成するかをlabelで識別しています。その後portsにて実際にどのNodePortをPodのどのPortに割り当てるかを指定します。


上記のように設定することでNodeへの30000ポート接続は指定ラベルPodの80ポートにバインドされます。例えばPod内のApacheやNginxコンテナであればServiceを通して接続することが可能です。


このようにPod外部の接続関係を定義するのがServiceのお仕事ということになります。

ConfigMap

次はConfigMapです。過去の記事は以下です。


【Kubernetesリソースシリーズ第五弾】ConfingMapについて知る!


ConfigMapは端的にいえばkubernetes上のあらゆる設定情報を定義するものです。例えば環境変数やVolumeを設定しておくことができます。


ConfigMapによって定義したVolumeをPodにマウントすると、ConfigMapで設定を変更した際動的にPodにも反映することができます。


ConfigMapの設定はkey,Value形式になっています。Mapといわれる所以はここかもしれませんね。

data: 
  test.cfg: |
    user: testuser
  type: "application"

Pod側から以下のように使用することができます。

      valueFrom:
        configMapKeyRef: #Key,Value形式でConfigMapの値を使用
          name: test-config
          key: type

こちらもKey,Value形式で指定する必要があります。

Secret

かなり長くなってきましたが頑張りましょう。お次はSecretです。


過去の記事は以下です。
【Kubernetesリソースシリーズ第六弾】Secretについて知る!


SecretはConfigMapと少し似ており、情報を定義するものです。しかし名前の通り秘密にしておきたい情報を暗号化して定義しておくことができます。例えば接続情報や認証情報が該当するかと思います。


作成方法としては、まず接続情報を記載したファイルを別で作成し

cat ファイル名 | base64

のようにすることで暗号化文字列を取得します。


Secretは下記のように利用できます。

metadata:
  name: Podで使用するSecret名
data:
  keyfile: 生成された暗号化文字列

Podでは以下のように利用できます。

      secretName: Secret名
      items:
      - key: コンテナ内に設置する情報ファイル名
        path: コンテナ内に設置する情報ファイルパス

これでPod内に複合化された情報を含むファイルが上記で指定したパスに指定した名前で入っているはずです。


このようにkubernetes上で秘密にしたい情報を取り扱うのがSecretです。

PersistentVolume・PersistentVolumeClaim

次に登場するのはVolume関係です。

過去の記事は以下です。
【Kubernetesリソースシリーズ第七弾】PersistentVolumeとPersistentVolumeClaimについて知る!


PersistentVolumeとはストレージへの接続情報などを含む、ストレージそのものを抽象化したリソースです。PersistentVolumeClaimは作成されたストレージ(PersistentVolume)の利用を要求することができます。


流れとしてはPod->PersistentVolumeClaim->PersistentVolumeと考えるとわかりやすいかと思います。

Ingress

いよいよ最後です。Ingressについてみていきましょう。

過去の記事は以下です。
【Kubernetesリソースシリーズ第八弾】Ingressについて知る!

Ingressとはコンテナを外部公開したり、L7ロードバランサーとしてURLによるサービス切り替えを実現することができるリソースです。これまではクラスタ内部での通信がほとんどでしたが、いよいよ外部に公開していきます。


Ingressを利用することで、ホスト名を利用したバーチャルホスティングなどHTTPに類する通信を柔軟にPodに振り分けられるようになります。


使用するにはIngress Controllerが必要になるという点にご注意ください。


外部からIngress Controllerを通して特定のServiceへ接続できるようにするには、マニフェストファイルで下記のように設定します。

  rules:
    - http:
        paths:
          - backend:
              service:
                name: Service名


まとめ

今回はたくさんの要素が出てきたので最後に完結にまとめておきます。

・通信の流れとしては Ingress->Service->Podです。
・管理階層としてはDeployment->Replicaset->Podです。
・情報定義としては、ConfigMapとSecretがあり特秘性が必要かどうかで使い分けてください。
・永続ボリュームを利用するにはPersistentVolume・PersistentVolumeClaimが必要です。

非常に盛り沢山の内容となりましたがkubernetesの総復習ができたのでよしとします!


最後まで読んでいただきありがとうございました!


↓オススメ教材

kubernetes

Posted by CY