Helmとは

HelmとはKubernetesクラスタのためのパッケージマネージャーです。

1つのアプリケーションとしての動作を行うために必要なKubernetesの様々な種類のリソースをひとまとめにして管理する仕組みと、そのためのツールセットを提供するものです。

Helm の基本的な概念として以下があります。

• Chart：アプリケーションのインスタンスを作成するために必要な設定ファイル群
• Config：Chartインストール時にアプリケーションのための各種パラメータを設定することができる
• Release：Chartがインストールされ、アプリケーションが実行可能な状態

HelmではChartという設定ファイル群でKubernetesの全てのマニフェストを管理します。

一般に公開されているChartを利用する際は、公開されているHelmリポジトリからChartを取得して、変数化されているパラメーターのみを書き換え、自身のKubernetesクラスタにデプロイします。

Skaffoldとは

SkaffoldはKubernetesへの継続的な開発を容易にするコマンドラインツールです。

開発環境では､アプリケーションのソースコードの変更を検知してDockerコンテナをBuildし、コンテナレジストリへのPushした後、KubernetesクラスタにDeployまでを自動で行ってくれます｡

また、開発環境におけるログやポートフォワードの機能もあります。他にも 本番やステージング環境におけるパイプライン内でCI/CDの役割を担ってくれます。

HelmとSkaffoldで開発環境を構築する

HelmとSkaffoldで開発環境を構築するにあたり、API・DB・WebそれぞれをSkaffold化しています。今回例としてOKRに関するAPIとWebを開発しています。

ディレクトリ構成

ディレクトリ構成は以下のようになっています。

APIをSkaffold化する

今回の例であるokr-apiをSkaffold化します。

まずはHelmのChartをSkaffoldに対応させるため、Chart.ymlとvalues.ymlを作成します。

Chart.yaml

Chart.yamlではChartの名前や説明などの情報をYAML形式で記述します。

・Chart.yaml

name: okr-api
version: 1.0.0

values.yaml

values.yamlでは、パラメータおよびそのデフォルト値の組み合わせを記述します。

ここで指定されたパラメータをtemplatesディレクトリ内に格納されているテンプレートに与えてKubernetesのマニフェストファイルを作成します。

・values.yml

revision: latest
replicas: 1
imagePullPolicy: IfNotPresent

templates

templatesはマニフェストファイルのTemplateが格納されているディレクトリです。

Chartを構成するKubernetesマニフェストはTemplateと呼ばれるファイルによって生成されます。

Templateはマニフェストファイルのテンプレートに変数を埋め込んだり、環境に応じて変更される部分を抽象化することができます。

今回は、DeploymentとServiceをこのtemplates配下において抽象化しています。

・templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: okr-api
spec:
  selector:
    matchLabels:
      app: okr-api
  replicas: {{ .Values.replicas }}
  template:
    metadata:
      labels:
        app: okr-api
    spec:
      containers:
      - name: okr-api
        image: {{ .Values.image }}
        imagePullPolicy: {{ .Values.imagePullPolicy }}
        resources:
        env:
          - name: SPRING_DATASOURCE_URL
            value: jdbc:mysql://okr-db-service:3306/okr?autoReconnect=true&useSSL=false
        ports:
        - containerPort: 8080

・templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: okr-api-service
spec:
  type: NodePort
  ports:
  - name: okr-api-service
    port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: okr-api

skaffold.yaml

skaffold.yamlを作成して記述していきます。

・skaffold.yaml

apiVersion: skaffold/v2beta17
kind: Config
metadata:
  name: okr-api
build:
  artifacts:
    - image: okr-api
      context: ../../../okr-api
      docker:
        dockerfile: ../environments/okr-api/api/docker/Dockerfile
  local:
    push: false
    useBuildkit: true
deploy:
  helm:
    releases:
      - name: okr-api
        chartPath: ./helm/deployment
        artifactOverrides:
          image: okr-api

中身の詳細は以下の通りです。

apiVersion

使用するskaffoldのバージョンを指定

kind

Configを指定

metadata

Configに関する追加情報。プロジェクトの識別子

build

ビルドしたいDocker Imageを指定

pushはビルドを行い、Docker Hubのリポジトリにプッシュするかを指定します。

useBuildKitはBuildKitを使用してDockerイメージをビルドするかどうか(無指定の場合はDockerのデフォルトを使用)

BuildKitは高速でのビルドが可能になるdockerのイメージビルダーです。ビルド短縮のためにもtrueにします。

deploy

デプロイしたい yaml が保存されている場所を指定

ローカルでAPI開発する時

APIを開発する際はDBのみKubernetes上で起動し、APIはローカルのサーバで起動しています。

以下のYAMLファイルを作成しskaffold devすることで、DBの起動とローカルへのポートフォワーディングをしています。

・environments/okr-api/deps.yaml

apiVersion: skaffold/v2beta24
kind: Config
requires:
  - path: ./db/skaffold.yaml

ローカルでWeb開発するとき

Webを開発する際は、APIとDBをKubernetes上で起動し、Webをローカルで起動しています。

以下のYAMLファイルを作成し、APIとDBのskaffold.yamlを起動しています。

・environments/okr-web/deps.yaml

apiVersion: skaffold/v2beta24
kind: Config
requires:
  - path: ../okr-api/db/skaffold.yaml
  - path: ../okr-api/api/skaffold.yaml

全体E2Eを流すとき

全体E2Eを流す用にAPI・DB・WEBをローカルで起動するようなYAMLファイルを作成しています。

・environments/okr-web/all.yaml

apiVersion: skaffold/v2beta24
kind: Config
requires:
  - path: ./deps.yaml
  - path: ./app/skaffold.yaml

参考情報

skaffold.yaml | Skaffold

Tip The Cloud Code IDE extensions (see…

skaffold.dev

クラスタ(Cluster)

クラスタは、コンテナ化されたアプリケーションを実行するためのノードマシンの集合です。クラスタには少なくとも、1 つのコントロールプレーン(マスターノードとも呼ばれている？)と、1 つ以上のノードと呼ばれるコンピューティングマシンが含まれます。

• コントロールプレーン：どのアプリケーションが実行されているかといった、クラスタの望ましい状態を維持
• ノード：実際にアプリケーションとワークロードを実行

以下のコマンドで、configの設定で指定されている接続先クラスター情報を確認できます。

$ kubectl config get-clusters

NAME
docker-desktop

コンテキスト(Context)

コンテキストはクラスタとユーザの組み合わせです。同一クラスタでも接続ユーザが異なれば、別のコンテキストとして扱われます。

以下のコマンドでコンテキストを取得できます。同じクラスタでもコンテキストが違っています。

$ kubectl config get-contexts

CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* docker-desktop docker-desktop docker-desktop
docker-desktop-2 docker-desktop docker-desktop

名前空間(Namespace)

名前空間とは、クラスタの分離機能のことで、複数のチームやユーザーでクラスターリソースを分割することができます。

名前空間を使うことで、Kubernetes内の環境に名前を付けて利用することができます。他の環境と分離させることができ、ユーザーによって権限を変えることも可能です。

$ kubectl get namespace

NAME STATUS AGE
default Active xxd
kube-node-lease Active xxd
kube-public Active xxd
kube-system Active xxd
sample Active xxd

Pod

Podは、1つまたは複数のコンテナのグループです。ストレージやネットワークの共有リソースを持ち、コンテナの実行方法に関する仕様を持っています。

Podとは、Kubernetesで実行できるアプリケーションの最小単位です。

$ kubectl get pod

NAME READY STATUS RESTARTS AGE
sample-78d9c99bd4-kdbwx 1/1 Running 0 xxd
sample-78d9c99bd4-m7mk2 1/1 Running 0 xxd

Service

Serviceとは、Podとの通信を容易に行うためにエンドポイントの提供を行ってくれる機能です。

通常、NodeのIPアドレスは一定ではないため、通信するにはその都度IPアドレスを指定する必要があります。

Serviceという機能があることで、通信するためのDNSラベルが発行され、アプリケーションが他のPodとの通信が簡単にできるようになります。

$ kubectl get service

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sample-service NodePort 10.102.100.87 <none> 80:31512/TCP xxd

Deployment

DeploymentはPodやReplicaSetの宣言的なアップデート機能を提供します。

Kubernetesでは、Podを単独で起動することはほとんどなく、大抵の場合は、ReplicaSetやJobなどの管理用オブジェクトを通してPodを利用します。

ReplicaSetは、複数のPodのレプリカをセットで作成する機能で、DeploymentはさらにそのReplicaSetを管理します。

ローリングアップデート

Deploymentは、作成したPodの仕様が変更されると、自動的にReplicaSetを再作成します。

Deploymentのアップデート方法は、デフォルトでローリングアップデートとなっており、新しいReplicaSetを生成し、順に古いPodを新しいPodに入れ替えていきます。

そのため、ダウンタイムが発生しないというメリットがある代わりに、切り替えに多少時間がかかるというデメリットがあります。

上の図の例だと、下の新しいReplica Setが作成され、上の古いReplica Setで作成されたPodが、新しいReplica Setで作成されたPodに徐々に切り替わっていく感じです。

$ kubectl get deployment

NAME READY UP-TO-DATE AVAILABLE AGE
sample 2/2 2 2 xxd

参考記事

https://kubernetes.io/ja/docs/concepts/overview/components/

https://udemy.benesse.co.jp/development/system/kubernetes.html

https://kubernetes.io/ja/docs/concepts/workloads/pods/

Kubernetesとは

Kubernetesとは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。

参考：https://kubernetes.io/ja/docs/concepts/overview/what-is-kubernetes/

Composeのように単一のDockerホスト上でコンテナ群を動かすのではなく、冗長性を得るため複数のホストを束ねてクラスタを構築し、その上で冗長化されたコンテナを動かします。

このようにKubernetesの登場により、複数のDockerなどのコンテナの管理や自動化が進み、この仕組みは「コンテナオーケストレーション」と呼ばれています。

サッカーの例えがわかりやすい

といってもなかなかイメージがつかないところ、Docker/Kubernetes超入門という本でKubernetsをサッカーで例えており、わかりやすくイメージしやすくなりました。

サッカーで例えるとコンテナが選手だとすると、Kubernetesは監督にあたります。グラウンドの正しい位置に選手(コンテナ)を配置し、チーム(アプリ)として連携を取れる形を作ります。

それだけでなく、怪我した選手(調子の悪いコンテナ)の交代や選手(コンテナ)をを減らしたり増やしたり(これはサッカーのルールから外れるが。。)などの仕事をします。

エンジニアはチームオーナーとして監督(Kubernetes)に「こういう方針でいきます」と頼んでおけばあとは任せておけるといった感じです。

Kubernetesの構成

参考：Docker/Kubernetes超入門

Kubernetesの構成は主に図の左側のコントロールプレーンと右側のデータプレーンにわかれます。大まかな担当は左側のマスターノードが頭脳として使われ、右側のワーカーノードは処理する肉体として使われます。

また、Kubernetesでシステムを構築する場合は、Kubernetes上だけで構築するのではなく右の図にある仮想マシンやクラウドが提供するマネージドサービスなども併用して開発するのが一般的です。

サービスやポッドのところは実際に動かしながら理解を深めていきます。

実際に触ってみる

というわけで実際にKubernetesを触っていきます。Docker Desktopが既にインストールされていれば環境設定から「Enable Kubernetes」にチェックを入れて有効化するだけで使えます。

マニフェストファイルを使ってNginxを動かす

Kubernetesのアプリ展開はマニフェストファイルと呼ばれる構成ファイルで行われるのが一般的です。今回はDocker/Kubernetes超入門の本を参考にポッドのマニフェストとそれを外部に公開するサービスのマニフェストを使ってNginxを展開します。

マニフェストファイルはYAML形式で記述します。それぞれの意味は以下のようになっています。

• apiVersion: マニフェストのバージョン
• kind: リソースの種類
• metadata: リソース名などのメタデータ
• spec: リソースの詳細

・pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels: 
    svc2pod: web
spec:
  containers:
  - name: nginx
    image: nginx:1.17.6-alpine
    ports:
    - name: http
      containerPort: 80

サービスのマニフェストも上の部分はポッドと同じですが、重要なのはspecの下にある「selector」で、これを使ってサービスが接続するポッドを指定します。

先程ポッドのマニフェストで定義した「svc2pod: web」を指定し、このサービスの接続先を定義します。

selectorの下の「ports」は外部に公開するポートと接続先のポートを指定しています。portがKubernetes内部から接続で利用するポートでnodePortがホスト外から接続で利用するポートです。

・service.yml

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    svc2pod: web
  ports:
  - port: 80
    targetPort: http
    nodePort: 30000
  type: NodePort

リソースを展開する

作成したマニフェストファイルを元にリソースを展開していきます。展開コマンドでは「kubectl apply -f」コマンドを使うのが一般的です

$ kubectl apply -f pod.yml
pod/web-pod created

$ kubectl apply -f service.yml
service/web-service created

サービスリソースを確認するとweb-serviceが立ち上がっていることが確認できます。

$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-service NodePort 10.99.80.170 <none> 80:30000/TCP 67s

nodePortで指定したポートを指定し、http://127.0.0.1:30000/にアクセスするとNginxのページを見ることができます。

デプロイメントを試してみる

実際の運用ではポッドを機能拡張したデプロイメントというリソースを使うことが一般的なようなため、実際に動かして試してみます。

デプロイメントは内部に下位リソースとしてレプリカセットというリソースを持ち、それが水平スケールや自動復旧機能を担当します。デプロイメントの主要機能としては、ポッドのアップグレードで、バージョンアップなど発生した際に古いポッドを入れ替えてくれます。

Docker/Kubernetes超入門の本を参考に動かしてみます。

spec.replicasフィールドで指定された通り、5つのレプリカPodを作成します。

spec.strategy.rollingUpdateフィールドでPodの数を指定した個数ずつ増減させてアップデートしていきます。

spec.strategy.typeにRollingUpdateと指定し、spec.strategy.rollingUpdateにmaxSurgeとmaxUnavailableを指定します。

• maxSurge: replicasで指定した数よりも増やしていい最大Pod数(デフォルト値25%・絶対値 or %を設定)
• maxUnavailable: replicasで指定した数よりも減らしていい最大Pod数(デフォルト値25%・絶対値 or %を設定)

・db.yml

apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  selector:
    pod: db
  ports:
  - port: 6379
    targetPort: redis
  type: ClusterIP

---
apiVersion: v1
kind: Pod
metadata:
  name: db
  labels: 
    pod: db
spec:
  containers:
  - name: db
    image: redis:5.0.6-alpine3.10
    ports:
    - name: redis
      containerPort: 6379

・app.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 5
  strategy:
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 0%
  selector:
    matchLabels:
      pod: app
  template:
    metadata:
      name: app
      labels: 
        pod: app
    spec:
      containers:
      - name: app
        image: sample/app
        ports:
        - name: http
          containerPort: 80
        env:
        - name: REDIS_HOST
          value: db

---
apiVersion: v1
kind: Service
metadata:
  name: app
spec:
  selector:
    pod: app
  ports:
  - port: 8080
    targetPort: http
    nodePort: 30000
  type: NodePort

kubectl applyで展開し、ポッドを確認すると5つ起動していることが確認できます。

$ kubectl apply -f app.yml -f db.yml 
deployment.apps/app created
service/app created
service/db created
pod/db created
$ kubectl get po
NAME READY STATUS RESTARTS AGE
app-975c58898-7rzxk 1/1 Running 0 6m18s
app-975c58898-clwxx 1/1 Running 0 6m18s
app-975c58898-lqfdl 1/1 Running 0 6m18s
app-975c58898-r64gw 1/1 Running 0 6m18s
app-975c58898-s6jl4 1/1 Running 0 6m18s
db 1/1 Running 0 12m

$ kubectl get replicaset
NAME DESIRED CURRENT READY AGE
app-975c58898 5 5 5 6m

デプロイメントの詳細情報は以下のコマンドで取得できます。

$ kubectl describe deployment app
Name:                   app
Namespace:              default
CreationTimestamp:      Sun, 14 Nov 2021 07:15:16 +0900
Labels:                 <none>
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               pod=app
Replicas:               5 desired | 5 updated | 5 total | 5 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  0% max unavailable, 50% max surge
Pod Template:
  Labels:  pod=app
  Containers:
   app:
    Image:      sample/app
    Port:       80/TCP
    Host Port:  0/TCP
    Environment:
      REDIS_HOST:  db
    Mounts:        <none>
  Volumes:         <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   app-975c58898 (5/5 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  17m   deployment-controller  Scaled up replica set app-975c58898 to 5