【四日目】最小限の構成でdocker-composeからKubernetesにデプロイする勉強会

概要

表題の勉強会を行った四日目の内容を記載します。全日の内容は以下のまとめページをご覧ください。

[【まとめ】最小限の構成でdocker-composeからKubernetesにデプロイする勉強会] (https://qiita.com/tamoco/items/5a5ffb448d59b3b03831/)

四日目のできたこと

• Kubernetes
  • deployment.ymlの作成
  • service.ymlの作成

四日目の内容

これまではdocker-composeでコンテナを作成し、それらをGitLab CI/CDでコンテナイメージを作成するところまでできました。四日目では作成したコンテナイメージを元にkubernetesで動作させます。

まずkubenernetesとは？

以下のページを参考に勉強します。

[Kubernetesとは？仕組みと構造をわかりやすく解説します] (https://www.kagoya.jp/howto/rentalserver/kubernetes/)

規模の大きいDockerの管理や自動化をするような仕組みでありコンテナの運用を充填としたモノであるのがイメージしやすいと思います。
逆にdocker-composeはソースから動作環境を準備したりすることに使われることが多く、負荷分散や冗長構成などの運用となった場合はAWSなどのサービスに頼ったりすることが多かったりするのではないでしょうか。
他のサービスによる運用でもよいのですが、せっかくベンダーに依存しないコンテナを使っているなら運用も依存したくないから、Kubernetesのような仕組みができたかもしれません。

動作環境

ローカルのkubernetesを使います。動作環境は以下のとおりです。

• Windows 10
• docker-for-windows
• docker desktop 2.3.0.3

今回はdocker desktopのkubernetesを使用し、初期のNodeを使用します。以下のようにcontextが設定されているか確認します。

$ kubectl config get-contexts
CURRENT   NAME                   CLUSTER          AUTHINFO                                  NAMESPACE
*         docker-desktop         docker-desktop   docker-desktop

deployment.ymlの作成

まずはdeploymentを作成します。すでに作成されたイメージを元にしています。
この時点ではコンテナのイメージはパブリックの状態にしてあります。
deploymentが定義の内容を元にpodを作成します。

■ deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: express-app
  labels:
    app: express-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: express-app
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: express-app
    spec:
      containers:
      - image: registry.gitlab.com/tamoco-mocomoco/k8s-test/express
        name: express-app
        ports:
        - containerPort: 3000
          name: express-app

delopyment.ymlをapplyすることで常にdeploymentが定義に書いている内容を維持するようになります。

 kubectl apply -f deployment.yaml

deploymentによって作成されたpodを確認します。replicas: 2となっているためpodは２つ作成されます。

$ kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
express-app-7dc6d9dbcd-jpbzm   1/1     Running   0          47s
express-app-7dc6d9dbcd-mb5jj   1/1     Running   0          47s

上記で維持すると記載されていました。これはもしpodが予期しない状態で削除された場合でもdeploymentが定義された状態を維持しようとするのでpodが作り直されます。試しにpodを削除してみます。

$ kubectl delete po express-app-7dc6d9dbcd-jpbzm
pod "express-app-7dc6d9dbcd-jpbzm" deleted

もう一度podを確認すると先ほど削除されたモノとは別のpodが作成されていることがわかります。

$ kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
express-app-7dc6d9dbcd-mb5jj   1/1     Running   0          3m
express-app-7dc6d9dbcd-wt6m6   1/1     Running   0          16s

service.ymlの作成

ポートの転送などはserviceで行います。今回はNodePortを使用しています。Ingressとかが良いとかは一旦は置いておきます。

■ service.yml

apiVersion: v1
kind: Service
metadata:
  name: express-app
spec:
  type: NodePort
  selector:
    app: express-app
  ports:
    - name: "http-port"
      protocol: "TCP"
      port: 80
      targetPort: 3000

service.ymlをapplyします。

$ kubectl apply -f service.yaml
service/express-app created

serviceを確認してみます。

$ kubectl get svc
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
express-app   NodePort    10.98.216.204   <none>        80:30948/TCP   38s

以下のURLにアクセスすることで動作していることが確認できます。転送されているポート番号はserviceを作り直すと変わるのでご注意ください。

http://localhost:30948/

作成したモノを削除する

以下のコマンドで削除します。deploymentを削除していないとダッシュボードなどでコンテナやpodを削除しても作り直されたりします。

$ kubectl delete deployment express-app
deployment.apps "express-app" deleted

$ kubectl delete svc express-app
service "express-app" deleted

四日目を振り返って

実際に動作させることを目標にkubernetesの触りの部分をやりました。podが作り直されるところを確認すると、運用することに重点されていることが何となく感じられたと思います。これをdocker-compose＋他の仕組みを自分たちで作ろうとするとタイヘンかと・・・。
今回の場合はアプリの元になったイメージが公開されていることを前提にしています。非公開にした場合の内容は五日目に続きます。