Isito、k8sでカナリアデプロイをする

はじめに

先月の5月18日にIstioが1.10のリリースがされたみたいです。
その中でStable Revision Labelsと言う機能を使ってカナリアップデートを行なう例が乗っていて、最初言葉尻を完全に読み間違えていてアプリのカナリアデプロイが容易になると思ったのですがそうでは無く、リビジョン付きの複数のコントロールプレーンをデプロイするサポートが入ったって感じっぽいですね。
まぁ、1.10は置いておいても、k8sやIstioを使ったカナリアリデプロイってやったことなかったので、ちょっと試してみようかと思います。
基本的にはここに乗っているのに基づいてやろうと思います。
かなり古いブログですが、これ以上に新しいものをみつけることができなかったので、もしもっと良いやり方がありそうであればコメントなどで教えてくれると嬉しいです。

やっていく

環境

今回の動作環境は以下のようになってます。

$ uname -srvmpio
Linux 5.4.0-74-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linu

$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal


$ minikube version
minikube version: v1.21.0
commit: 76d74191d82c47883dc7e1319ef7cebd3e00ee11


$ kubectl version  -o yaml
clientVersion:
  buildDate: "2021-03-18T01:10:43Z"
  compiler: gc
  gitCommit: 6b1d87acf3c8253c123756b9e61dac642678305f
  gitTreeState: clean
  gitVersion: v1.20.5
  goVersion: go1.15.8
  major: "1"
  minor: "20"
  platform: linux/amd64
serverVersion:
  buildDate: "2021-01-13T13:20:00Z"
  compiler: gc
  gitCommit: faecb196815e248d3ecfb03c680a4507229c2a56
  gitTreeState: clean
  gitVersion: v1.20.2
  goVersion: go1.15.5
  major: "1"
  minor: "20"
  platform: linux/amd64

$ istioctl version
client version: 1.10.1
control plane version: 1.10.1
data plane version: 1.10.1 (1 proxies)

また、このブログでは特に明記しない場合k8sのコンテキストはminikubeを使っています。

下準備

下準備として特定の文字列を返すnginxのコンテナを作成しておきます。
まずは、以下のコマンドを実行して、Dockerのコンテキストをminikubeのものに変えておきます。

$ eval $(minikube docker-env)

これでDockerクライアントはMinikubeのコンテキストで動くようになりました。  

次に以下の簡単なDokcerfileを用意します。

Dockerfile-v1

FROM nginx:1.19.6

RUN echo "Hello, Canary v1" > /usr/share/nginx/html/index.html

Dockerfile-v2

FROM nginx:1.19.6

RUN echo "Hello, Canary v2" > /usr/share/nginx/html/index.html

それぞれをビルドしておきます。

$ docker build ./ -t hello-nginx-v2 -f Dockerfile-v2
$ docker build ./ -t hello-nginx-v1 -f Dockerfile-v1

$ docker images | grep hello-nginx
hello-nginx-v2                            latest     9defac4edce6   2 minutes ago   133MB
hello-nginx-v1                            latest     abd78992aeba   8 minutes ago   133MB

最後にあとで使うのでMinikubeのIPを調べておきます。

$ minikube ip
192.168.49.2

これで下準備は完了です。

どんなことを行なうか

今回は、以下のパターンをやってみようかと思います。

Kubernetesのみでのカナリアデプロイをやってみる
・Istioを使ったカナリアリデプロイをやってみる

k8sを使ったカナリアデプロイ

k8s単体でもカナリアデプロイを行なうこと自体は可能です。 それを行なうには以下の2つの方法取るようです。

selectorを用いたカナリアデプロイ

selectorを用いてカナリアデプロイをやってみようと思います。
こいつの考え方としては、古いバージョンと新しいバージョンのPod数を変更することで、新しいVersionのPodへルーティングされる割合を調整します。
実際にやってみます。 まずは、2つのDeploymentを用意します。

$ kubectl create deployment hello-nginx --image=hello-nginx-v1 --dry-run=client -o yaml > deployment.yaml
$ echo --- >> deployment.yaml 
$ kubectl create deployment hello-nginx --image=hello-nginx-v2 --dry-run=client -o yaml >> deployment.yam

できたデプロイメントが以下のようになります。

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx
  name: hello-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
    spec:
      containers:
      - image: hello-nginx-v1
        name: hello-nginx-v1
        resources: {}
status: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx
  name: hello-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
    spec:
      containers:
      - image: hello-nginx-v2
        name: hello-nginx-v2
        resources: {}
status: {}

それぞれを見分けるためnamenginx-hello-v1nginx-hello-v2のに変え環境を示すラベル(track)追加します。
また、nginx-hello-v1の方はレプリカ数も変えておきます。

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx      
    track: stable               # 環境を示すラベルを追加
  name: hello-nginx-v1          # nameにVersionを追加
spec:
  replicas: 3                   # レプリカ数を3に
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
    spec:
      containers:
      - image: hello-nginx-v1
        name: hello-nginx-v1
        resources: {}
status: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx
    track: canary               # 環境を示すラベルを追加
  name: hello-nginx-v2          # nameにVersionを追加
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
    spec:
      containers:
      - image: hello-nginx-v2
        name: hello-nginx-v2
        resources: {}
status: {}

deploymentをapplyします。

$ kubectl apply -f deployment.yaml 
deployment.apps/hello-nginx-v1 created
deployment.apps/hello-nginx-v2 created

$ kubectl get po
NAME                              READY   STATUS    RESTARTS   AGE
hello-nginx-v1-7b8665d769-grsz5   1/1     Running   0          7s
hello-nginx-v1-7b8665d769-rdwg5   1/1     Running   0          7s
hello-nginx-v1-7b8665d769-zvlsg   1/1     Running   0          7s
hello-nginx-v2-86467b54f9-ghdnm   1/1     Running   0          7s

そして、これらのデプロイメントに対してapp: hello-nginxのラベルに対してルーティングを行なうServiceを記述してやります。   

$ kubectl create service nodeport hello-nginx --tcp=8081:80 --dry-run=client -o yaml > service.yaml

できたServiceが以下の通りになります。

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx
  name: hello-nginx
spec:
  ports:
  - name: 8081-80
    port: 8081
    protocol: TCP
    targetPort: 80
  selector:
    app: hello-nginx
  type: NodePort
status:
  loadBalancer: {}

applyしてNodePortのポートをチェックしておきます。

$ kubectl  apply -f service.yaml

$ kubectl get svc/hello-nginx
NAME          TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
hello-nginx   NodePort   10.100.167.221   <none>        8081:32697/TCP   68m

これでおおよそ1/4程度のリクエストがv2にルーティングされるようになっているはずです。
ロードテストツールであるk6で以下のスクリプトを書いてチェックしてみます。

$ cat 100requests.js 
import http from 'k6/http';
import { sleep, check } from 'k6';

export let options = {
  vus: 10,
  duration: '10s',
};

export default function () {
  
  let res = http.get('http://192.168.49.2:32697');
  sleep(1);

  check(res, {
    'v1 responded': (r) => r.body == 'Hello, Canary v1\n',
    'v2 responded': (r) => r.body == 'Hello, Canary v2\n',
  });
}

ここでk6の使い方を詳細には説明しませんが、10並列で10秒ごとに計100回のリクエストを送り、そのレスポンスボディをチェックするスクリプトになっています。
k6に関しては過去にブログを書いているので、よろしければそちらもみてみてください)

$ docker run --network=host -i loadimpact/k6 run  - < 100requests.js

          /\      |‾‾| /‾‾/   /‾‾/   
     /\  /  \     |  |/  /   /  /    
    /  \/    \    |     (   /   ‾‾\  
   /          \   |  |\  \ |  (‾)  | 
  / __________ \  |__| \__\ \_____/ .io

  execution: local
     script: -
     output: -

  scenarios: (100.00%) 1 scenario, 10 max VUs, 40s max duration (incl. graceful stop):
           * default: 10 looping VUs for 10s (gracefulStop: 30s)


(省略)


     ✗ v1 responded
      ↳  80% — ✓ 80 / ✗ 20
     ✗ v2 responded
      ↳  20% — ✓ 20 / ✗ 80

(省略)

ここでは大体20%ぐらいのリクエストがV2に振られたみたいですね。
もう一度テストを実行すると70%、30%の割合になったので、おおよそ25%の割合で新しいVersionのPodにリクエストが割り振られているのがわかります。
Podが少ない状態である程度新しいバージョンの動作に確証が取れてきたらscaleコマンドでPodの数を調整します。

$ kubectl scale --replicas=2  deployment/hello-nginx-v2
deployment.apps/hello-nginx-v2 scaled
$ kubectl scale --replicas=2  deployment/hello-nginx-v1
deployment.apps/hello-nginx-v1 scaled

$ kubectl get po
NAME                              READY   STATUS    RESTARTS   AGE
hello-nginx-v1-7b8665d769-khzfp   1/1     Running   0          67m
hello-nginx-v1-7b8665d769-wjfxj   1/1     Running   0          67m
hello-nginx-v2-86467b54f9-ghdnm   1/1     Running   0          84m
hello-nginx-v2-86467b54f9-nsr99   1/1     Running   0          37s


$ docker run --network=host -i loadimpact/k6 run  - < 100requests.js

(省略)

     ✗ v1 responded
      ↳  50% — ✓ 50 / ✗ 50
     ✗ v2 responded
      ↳  50% — ✓ 50 / ✗ 50

(省略)

最終的にv1のスケールを0にしてv2を必要な数までスケールさせるとデプロイ完了です。
ロールバックしたい場合は、v2のスケールを0にして、v1のスケールを元の数まで戻せば良いです。

rolloutを用いたカナリアデプロイ

今度はk8sのrollout/pauseコマンドを用いてカナリアデプロイを行ってみようと思います。
考え方としては、selectorと似ており、Podの数を調整することで新しいVersionにルーティングされる割合を少しずつ増やしていき、カナリアデプロイを実現します。
具体的には、imageのアップデートが行われた際に実行されるrolloutを途中でpauseすることでより、比較的少ない新しいVersionのPodを起動して、少しずつデプロイして行きます。
selectorの例で用いていたDeploymentとServiceを削除して次のDeploymentを使用します。

deployment-rp.yaml

$ cat deployment-rp.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx      
  name: hello-nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
    spec:
      containers:
      - image: hello-nginx-v1
        name: hello-nginx-v1
        resources: {}
        imagePullPolicy: IfNotPresent
status: {}

applyしてPodが起動するのを確認します。

$ kubectl apply -f deployment-rp.yaml 
deployment.apps/hello-nginx create

$ kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
hello-nginx-59849bb7d7-cgkhw   1/1     Running   0          40s
hello-nginx-59849bb7d7-lz8bf   1/1     Running   0          40s
hello-nginx-59849bb7d7-mgrrb   1/1     Running   0          40s
hello-nginx-59849bb7d7-vl7lg   1/1     Running   0          40s

次にイメージをアップデートして、すぐにpauseコマンドを実行します。

$ kubectl rollout pause deployment/hello-nginx

$ kubectl set image deployment/hello-nginx hello-nginx=hello-nginx-v2
deployment.apps/hello-nginx image updated
$ kubectl rollout pause deployment/hello-nginx
deployment.apps/hello-nginx paused

$ kubectl get po
NAME                           READY   STATUS    RESTARTS   AGE
hello-nginx-59849bb7d7-cgkhw   1/1     Running   0          2m46s
hello-nginx-59849bb7d7-lz8bf   1/1     Running   0          2m46s
hello-nginx-59849bb7d7-mgrrb   1/1     Running   0          2m46s
hello-nginx-5d8dc5f978-4nx4g   1/1     Running   0          11s
hello-nginx-5d8dc5f978-d5p8s   1/1     Running   0          11s

今回の場合新しいPodが2つ起動されていますね。
この新しいPodはイメージが新しいものが使われているのがわかります。

$ kubectl describe po hello-nginx-5d8dc5f978-4nx4g 
Name:         hello-nginx-5d8dc5f978-4nx4g
Namespace:    default
Priority:     0
Node:         minikube/192.168.49.2
Start Time:   Sun, 20 Jun 2021 15:11:33 +0900
Labels:       app=hello-nginx
              pod-template-hash=5d8dc5f978
Annotations:  <none>
Status:       Running
IP:           172.17.0.8
IPs:
  IP:           172.17.0.8
Controlled By:  ReplicaSet/hello-nginx-5d8dc5f978
Containers:
  hello-nginx:
    Container ID:   docker://0988812d8fa7b3ccd1eb91c5fe48bbfed265ec0964407b9064e9f3dbb7801bc3
    Image:          hello-nginx-v2
    Image ID:       docker://sha256:9defac4edce66768e5023868544942142630a22e35b0770a222b973083fde7da
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Sun, 20 Jun 2021 15:11:34 +0900
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-2zfxv (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-2zfxv:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-2zfxv
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  100s  default-scheduler  Successfully assigned default/hello-nginx-5d8dc5f978-4nx4g to minikube
  Normal  Pulled     100s  kubelet            Container image "hello-nginx-v2" already present on machine
  Normal  Created    100s  kubelet            Created container hello-nginx
  Normal  Started    100s  kubelet            Started container hello-nginx

もし、リリース中に問題があった場合は、rollbackコマンドを実行し、リビジョンを1つ前のものに戻します。

$ kubectl rollout resume deployment/hello-nginx
deployment.apps/hello-nginx resumed

$ kubectl rollout undo deployment/hello-nginx
deployment.apps/hello-nginx rolled back

Istioを使ったカナリアデプロイ

k8sを使ったカナリアデプロイでは限定的で以下のようなカナリアリデプロイを行なう際には課題があります。

  • 全体の1%のリクエストだけ新しいVersionのPodにルーティングしたい場合(Podを100個起動する必要がある)
  • 特定のクライテリアを満たすリクエストを新しいVersionにルーティングしたい

Istioを用いることで、上記のような、より複雑な条件でのデプロイを簡単に行なうことができるようになります。
一度、rolloutで使ったdeploymentを削除して、

deployment-istio.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx      
  name: hello-nginx-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
        version: v1
    spec:
      containers:
      - image: hello-nginx-v1
        name: hello-nginx-v1
        resources: {}
        imagePullPolicy: IfNotPresent
status: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: hello-nginx
  name: hello-nginx-v2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: hello-nginx
        version: v2
    spec:
      containers:
      - image: hello-nginx-v2
        name: hello-nginx-v2
        resources: {}
        imagePullPolicy: IfNotPresent
status: {}

selectorのところで用いたdeploymentと少し似ていますが、Podに対して、versionラベルを追加しているのとPodの数を3つずつ、2つのDeploymentで計6個のPodを起動しています。

$ kubectl apply -f deployment-istio.yaml

$ kubectl get po
NAME                              READY   STATUS    RESTARTS   AGE
hello-nginx-v1-7b8665d769-bzgzg   1/1     Running   0          99s
hello-nginx-v1-7b8665d769-j569c   1/1     Running   0          99s
hello-nginx-v1-7b8665d769-wbthk   1/1     Running   0          99s
hello-nginx-v2-86467b54f9-d9txr   1/1     Running   0          8s
hello-nginx-v2-86467b54f9-hdsx9   1/1     Running   0          99s
hello-nginx-v2-86467b54f9-m8gmk   1/1     Running   0          8s

次に外部からアクセスを可能にするため、Gatewayリソースを作成します。

gateway.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: hello-nginx
spec:
  selector:
    istio: ingressgateway 
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

そして、きもとなるVertualServiceとDestinationRouleを作成します。

destination-rule.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: hello-nginx
spec:
  host: hello-nginx
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

DestinationRouleでPodに付与したversionのラベルを指定することで、ルーティング先をsubsetとして定義しています。

virtual-service.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-nginx
spec:
  hosts:
  - "*"
  gateways:
  - hello-nginx
  http:
  - route:
    - destination:
        host: hello-nginx
        subset: v1
      weight: 90
    - destination:
        host: hello-nginx
        subset: v2
      weight: 10

ここでは、Gatewayに対するどんなHostのリクエストに対してもsubsetのv1v2に対してルーティングを行なうように設定しています。
また、weightを設定し、リクエストの10%がv2へルーティングされるようにしています。

これで準備は完了です、k6からGateway経由でリクエストを送るようにするためにGatewayのport番号を取得してk6スクリプトを修正します。

$ kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}'
31424

取得したPortでリクエストを送るようにk6スクリプトを修正したら、テストを実行します。

$ docker run --network=host -i loadimpact/k6 run  - < 100requests.js

(省略)

     ✗ v1 responded
      ↳  90% — ✓ 90 / ✗ 10
     ✗ v2 responded
      ↳  10% — ✓ 10 / ✗ 90

(省略)

先ほどと違い、Podの数とは関係なくルーティングが行われていることが確認できました。
より小さなリクエストの数で、新しいVersionの動作確認が取れたらweightを修正して新しいVersionにのみリクエストが送られていくように変更していきます。
今回は、Podの数は固定で行いましたが、Podの数で割合を調整する必要がなくなったので、Deploymentのオートスケールの機能と合わせて利用することも可能です。

http4sのHTTP Serverを使ってみる

はじめに

FS2に依存するライブラリはいくつかありますが、http4sというHTTPサーバとクライアントを用意してくれているライブラリがあり、ちょっと興味が湧いたので触ってみようかと思います。
http4sはFS2(と、もちろんCats Effects)をベースにしているので、FunctinnalでStreamingでFunctionalというのが特徴みたいです。

やってみる

環境

$ scala --version
Scala code runner version 2.13.6 -- Copyright 2002-2021, LAMP/EPFL and Lightbend, Inc.

$ sbt --version
[info] 1.2.7
sbt script version: 1.5.2

プロジェクトの作成

まずはベースとなるプロジェクトを作成します。
 

$ sbt new sbt/scala-seed.g8
[info] welcome to sbt 1.5.2 (Oracle Corporation Java 1.8.0_292)
[info] loading global plugins from /home/yuya-hirooka/.sbt/1.0/plugins
[info] set current project to new (in build file:/tmp/sbt_adb8af4/new/)

A minimal Scala project. 

name [Scala Seed Project]: http4s-example

作成されたプロジェクトのbuild.sbtに以下の依存を追加します。

libraryDependencies += "org.http4s" %% "http4s-dsl" % "0.21.23",
libraryDependencies += "org.http4s" %% "http4s-blaze-server" % "0.21.23",
libraryDependencies += "org.http4s" %% "http4s-blaze-client" % "0.21.23",

今回はhttp4sの現在のstableバージョンである0.21.x系を利用しようと思います。

名前を受け取って挨拶を返すサーバを作成する

最初にhttp4s-blaze-serverを使って、サーバーの方を作成します。
最終的には名前をJsonで受け取って挨拶を返すサーバを作成しようと思います。

helloの文字列を返す

まずは、単純なGETリクエストに対して"hello"という文字列を返すだけのサーバを作ります。
そのためにはRouterBlazeServerBuilderを使います。
Routerを使ってルートの定義を作成します。

import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.implicits.http4sKleisliResponseSyntaxOptionT
import org.http4s.server.Router

object SampleRouters {

  def helloHandler() = IO("hello")

  val helloRouter = HttpRoutes.of[IO] {
    case GET -> Root / "hello" => helloHandler().flatMap(Ok(_))
  }

  def createApp = Router("/" -> helloRouter).orNotFound

}

HttpRoutes http4s-dsl,を使ってルータを定義します。
みてすぐわかるかも知れませんが、パターンマッチングでGETと/helloのパスにマッチした場合helloHandr()を呼び出し、その戻り値であるIO("")をflatMapして取り出しOk()レスポンスで返すRouterを定義しています。
1番最後の行ではRouter objectを作成策定していますが、ここでは定義したルータのルートに当たるパスを指定することができます。

Routeの作成はできたので、次にアプリケーションのエントリーポイントとなるobjectを作ります。

import cats.effect.{ExitCode, IO, IOApp}
import org.http4s.server.blaze.BlazeServerBuilder

import scala.concurrent.ExecutionContext.Implicits.global


object AppStarter extends IOApp {

  override def run(args: List[String]): IO[ExitCode] =
    BlazeServerBuilder[IO](global)
      .bindHttp(8081, "localhost")
      .withHttpApp(SampleRouters.createApp)
      .serve
      .compile
      .drain
      .as(ExitCode.Success)

}

http4sは様々なバックエンドをサポートしているようですが(サポートはここを確認してください。
BlazeServerBuilderを使って、 もし、IOApp以外の場所でBuilderを使いたい場合は以下のimplicitを定義する必要があります。

implicit val cs: ContextShift[IO] = IO.contextShift(global)
implicit val timer: Timer[IO] = IO.timer(global)

アプリケーションを実行するし、cURLでアプリケーションにリクエストを送ってみます。

$ curl localhost:8081/greeting -v
*   Trying 127.0.0.1:8081...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8081 (#0)
> GET /greeting HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=UTF-8
< Date: Fri, 11 Jun 2021 14:20:49 GMT
< Content-Length: 5
< 
* Connection #0 to host localhost left intact
hello

うまく起動できてるみたいですね。

パスパラーメータで値を受け取る

それでは次に、パスパラメータ名前を受け取ってその名前に対して挨拶を返す用にしてみます。
新しく、Routerを作成します。

object SampleRouters {

  def helloHandler() = IO("hello")

  val helloRouter = HttpRoutes.of[IO] {
    case GET -> Root / "hello" => helloHandler().flatMap(Ok(_))
  }

  def greetingSomeone(name: String) = IO(s"Hello, $name")

  val greetingRouter = HttpRoutes.of[IO] {
    case GET -> Root / "greeting" / name => helloHandler().flatMap(Ok(_))
  }

  def createApp = Router("/" -> helloRouter, "/v1" -> greetingRouter).orNotFound

}

ここではgreetingRouterを新たに定義してます。
DSLのなかでパスの位置い変数を置くことで、パスパラメータを束縛することができます。
また、上記のようにRouter object作成時には複数のRouterを登録することができます。

cURLでリクエストを送ってみます。

$ curl localhost:8081/v1/greeting/Moheji -v
*   Trying 127.0.0.1:8081...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8081 (#0)
> GET /v1/greeting/Moheji HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=UTF-8
< Date: Fri, 11 Jun 2021 14:46:01 GMT
< Content-Length: 13
< 
* Connection #0 to host localhost left intact
Hello, Moheji

Jsonで値を受け取る。Jsonの値を返す

それでは最後にJsonの値を扱うようなPathを追加してみようと思います。
まずですが、http4sでJsonを扱うためには以下の依存を追加する必要があります。

libraryDependencies += "org.http4s" %% "http4s-circe" % "0.21.23"
libraryDependencies += "io.circe" %% "circe-generic" % "0.13.0"

circe-genericの依存はオプショナルっぽいですが、JsonScalaのクラスとの変換を知れてくれるみたいなので追加しておきます。

それでは追加したhttp4s-circecirce-genericを使ってgreetingRouterに新たなRouteを書き加えてみます。

import io.circe.generic.auto._
import io.circe.syntax.EncoderOps
import org.http4s._
import org.http4s.circe.CirceEntityCodec._
//他のImportは省略


object SampleRouters {
  // 他の実証は諸略  

  case class Name(name: String)

  case class Greeting(hello: String)

  val greetingRouter = HttpRoutes.of[IO] {
    case req@POST -> Root / "greeting" => for {
      n <- req.as[Name]
      resp <- Created(Greeting(n.name).asJson)
    } yield resp
    case GET -> Root / "greeting" / name => greetingSomeone(name).flatMap(Ok(_))
  }

  def createApp = Router("/" -> helloRouter, "/v1" -> greetingRouter).orNotFound

}

POSTリクエストで名前を受け取るためにDSLを使います。
req@のように記述刷ることでreqにリクエストの情報をバインドできるみたいです。
リクエストを受け取るためのcase

// リクエスト用のcase class
case class Name(name: String)

// レスポンス用のcase class
case class Greeting(hello: String)

本来はこれらに対してエンコーダーデコーダーを作ってimplicitとして定義刷る必要があるようですが。 以下の2つをインポートしていればそれぞれが自動でimplicitされるみたいです。

import io.circe.generic.auto._
import org.http4s.circe.CirceEntityCodec._

それではリクエストを送ってみましょう。

$ curl localhost:8081/v1/greeting -d '{"name":"Moheji"}' -v
*   Trying 127.0.0.1:8081...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8081 (#0)
> POST /v1/greeting HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 17
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 17 out of 17 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Content-Type: application/json
< Date: Fri, 11 Jun 2021 15:51:56 GMT
< Content-Length: 18
< 
* Connection #0 to host localhost left intact
{"hello":"Moheji"}

これでちょっと触った程度ですが一応、サーバができましたね。

fs2を試す。

はじめに

ScalaでReactorみたいなリアクティブなプログラミングをするにはどうすれば良い?みたいなのをScalaに詳しい同僚に聞いてみたところ。
FS2というライブラリを教えて頂いたので試してみようかと思います。
ただ、この時期ではリアクティブのところまでは行かずにまずは基本的な使い方を確認します。

FS2とは

純粋な関数型の多形性を持つストリームプロセスをサポートするライブラリです。
I/O(netwrking, flies)のストリーム処理をリソースセーフに実行することを可能とします。
Scala 2.12、 2.13、3で利用できるみたいです。 また、FS2はCatsCats Effectを利用しているライブラリで、逆にhttp4sskunkdoobieに用いられるようです。
ちなみに、名前はFunctional Streams for ScalaでFS2もしくはFSSらしいです。

動かしてみる

環境

ソースコードの実行環境は以下の通り。

$ uname -srvmpio
Linux 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal

$ sbt --version
[info] 1.2.7
sbt script version: 1.5.2


$ scala --version
Scala code runner version 3.0.0 -- Copyright 2002-2021, LAMP/EPFL

プロジェクトの作成

sbtを使ってプロジェクトを作成します。
以下のコマンドを実行します。

$ sbt new sbt/scala-seed.g8
[info] welcome to sbt 1.5.2 (Oracle Corporation Java 1.8.0_292)
[info] set current project to new (in build file:/tmp/sbt_c0223d2e/new/)

A minimal Scala project. 

name [Scala Seed Project]: fs2-example

出来上がったbuild.sbtに依存をつかします。

lazy val root = (project in file("."))
  .settings(
    name := "fs2",
    libraryDependencies += scalaTest % Test,
    // 以下を追加
    libraryDependencies += "co.fs2" %% "fs2-core" % "3.0.0",
    libraryDependencies += "co.fs2" %% "fs2-io" % "3.0.0",
    libraryDependencies += "co.fs2" %% "fs2-reactive-streams" % "3.0.0"
  )

Streamの作成と副作用を持つStreamの実行

FS2ではStream[F, 0]というクラスが基本のデータクラスっぽいです。
ここでF エフェクト型と呼ばで、Oはアウトプット型と呼ばれるようです。
Streamは以下のようにして作成します。

import cats.effect.{IO, IOApp}
import fs2.{INothing, Pure, Stream}

object Fs2Example {
  
  val streamEmpty: Stream[Pure, INothing] = Stream.empty
  val streamOne: Stream[Pure, Int] = Stream.emit(1)
  val streamThree: Stream[Pure, Int] = Stream(1, 2, 3)
  val streamList: Stream[Pure, List[Int]] = Stream(List(1, 2, 3))
}

例えば、上記のstreamOneStream[Pure, Int]を持っており、アウトプット型がIntでエフェクト型がPureとなります。
Pureは実行時に副作用が存在しないことを示すようです。

StreamはtoListtoVectorをそれぞれ呼び出すことで、ListVectorに変換できるようです。
またStreamはlist-likeな以下のようなメソッドを持っているようです。

val filteredStream: Stream[Pure, Int] = Stream(1, 2, 3, 4, 5, 6).filter(_ > 0)
val foldSum: List[Int] = Stream(1, 2, 3).fold(0)(_ + _).toList
val repeat: Stream[Pure, Int] = Stream(1, 2, 3).repeat.take(9)
val collect: Stream[Pure, Int] = Stream(None, Some(0), Some(1)).collect { case Some(i)=> 1}

副作用を含んたStreamの作成も行なうことができます。

val eff: Stream[IO, Int] = Stream.eval(IO {
  println("Hello! FS2"); 1 + 1
})

IOはエフェクト型で、この型を作ること自体は副作用を起こしません。
また、Stream.evalも作成されたタイミングでは何もしません。
この副採用を含んだストリームを実行するためにはまずcompileメソッドを呼び出してIOを取り出します。
compileは更に以下のようなメソッドを持ちます。

val vector: IO[Vector[Int]] = eff.compile.toVector
private val drain: IO[Unit] = eff.compile.drain
private val value: IO[Int] = eff.compile.fold(0)(_ + _)

toVectorはすべてのアウトプットを1つのベクターに入れ込み、drainはすべての実行結果を捨て、 foldは結果を畳み込みます。
compileを実行するだけではまだ、実行はおこなわれません。
これを実行するには以下のように

import cats.effect.unsafe.implicits.global

object Main extends App {

  val foldResult: IO[Int] = eff.compile.fold(0)(_ + _)
  vector.unsafeRunSync
}

import cats.effect.unsafe.implicits.globalに関してはまだ理解が甘いですが、今回利用するIORumtimeクラスの指定しているようです。
実行結果は以下の通り。

Hello! FS2

Streamの基本操作

Streamには便利なオペレーターが用意されています。
代表的なものには++mapflatMapbracketのようなものがあります。

object MainOperator extends App {

  val result = (Stream(Some(1), Some(2)) ++ Stream(Some(3), Some(4), None))
    .flatMap(i => Stream(i, i))
    .map {
      case Some(i) => i
      case _ => -1
    }.map(_ + 1)

  result.toList.foreach(println)
}

これの実行結果は以下のようになります。

2
2
3
3
4
4
5
5
0
0

エラーハンドリング

Streamでエラーを投げたい場合はStream.raseErrorを使います。
以下のような使い方ができるようです。

//
val err = Stream.raiseError[IO](new Exception("Oops! 1"))

val err2 = Stream(1, 2, 3) ++ (throw new Exception("Oops! 2"))

val err3 = Stream.eval(IO(throw new Exception("Oops! 3")))

このハンドリングは以下のように行えます。

  try err.compile.toList.unsafeRunSync() catch {
    case e: Exception => println(e)
  }

  try err2.toList catch {
    case e: Exception => println(e)
  }

  try err3.compile.drain.unsafeRunSync() catch {
    case e: Exception => println(e)
  }
}

実行結果は以下の通り

java.lang.Exception: Oops! 1
java.lang.Exception: Oops! 2
java.lang.Exception: Oops! 3

ScalaTestとScalaMockでテストを行なう

はじめに

今後Scalaを触ることになりそうになのでちょっと勉強しておこうかと思いまして、まずはテストのやり方を確認しようかと思いScalaTestScalaMockを使ってユニットテストを書いてみようと思います。

書いてみる

環境

今回の環境は以下の通り

$ scala --version
Scala code runner version 3.0.0 -- Copyright 2002-2021, LAMP/EPFL

$ sbt --version
sbt version in this project: 1.5.2
sbt script version: 1.5.2

セットアップ

まず、sbtのプロジェクトはIntelliJプラグインで作成しました。
ScalaTestのセットアップはこちらを参考に行います。

まずは、build.sbtに以下の依存を追加します。

libraryDependencies += "org.scalactic" %% "scalactic" % "3.2.9"
libraryDependencies += "org.scalamock" %% "scalamock" % "5.1.0" % Test
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.9" % "test"

sbtで依存を定義するための手っ取り早い方法はlibraryDependenciesに次のような構文で記述するようです。
libraryDependencies += groupID % artifactID % revision % configuration

ここでは3つ依存を定義しています。scalatestscalamockに関しては良いとしてscalaitcですが、ScalaTestの姉妹ライブラリーで==オペレーターなどのテストやプロダクションコードで使えるような諸々を提供してくれるみたいです。今回使うかはわかりませんが、ドキュメントで依存に追加することが推奨されていたので追加しておこうと思います。

ScalaTestでユニットテストを記述する

ScalaTestのスタイルについて

ScalaTestでは以下のようなテストスタイルをサポートしているようです。

  • FunSuiteスタイル
  • FlatSpecスタイル
  • FunSpecスタイル
  • FreeSpecスタイル

それぞれのテストの書き方はこちらを参考にしてください。 最初のステップとしてはFlatSpecスタイルがおすすめされているようなので、このブログではFlatSpecを用いてテストを記述しようと思います。

単純なテストを書いてみる

まずは以下のような足し算をするだけの簡単なクラスを用意します。

class Calc {
  def plus(a: Int, b: Int): Int = a + b
}

このクラスのメソッドplusをテストするコードは以下のようになります。

import org.scalatest.flatspec.AnyFlatSpec
import org.scalatest.matchers.should

class CalcTest extends AnyFlatSpec with should.Matchers {

  it should "足し算の結果を返す" in {
    val c = new Calc
    c.plus(1, 2) should be (3)
  }
}

AnyFlatSpecX should YA must Bのような形式でテストを記述するための構文を提供してくれます。   shouldmustcanと行ったような助動詞の記述が可能なようです。
また、should.Matchersをミクスインしていますが、これは result should be (expected)のようにアサーションを記述するための構文を提供してくれます。
should.Matchersは以下のような構文を提供します。

  • result should equal (expected)
    • 比較がカスタマイズ可能
  • result should === (expected)
    • 比較がカスタマイズ可能
    • 型の制約を強制する
  • result should be (expected)
    • 比較がカスタマイズができない代わりにコンパイルが早い
  • result shouldEqual expected
    • ()を必要としない
    • カスタマイズ可能な比較
  • result shouldBe 3
    • ()を必要としない
    • 比較がカスタマイズができない代わりにコンパイルが早い

should.Matchersの他にもAnyFlatSpecの上位のクラスでミクスインされているAssertionsトレイトではアサーションを行なうためのいくつかのマクロを定義されています。
このマクロには例えば以下のようなものがあります。

  • fail
    • テストを失敗させる
  • succeed
    • テストを成功させる

他にもさまざまなマクロがあります。詳細はこちらを確認ください。

それでは、記述したテストを実行してみます。
様々な実行方法がありますが、今回はsbtを使って実行したいと思います。
単純にすべてのテストを実行するためにはプロジェクトルートで以下のコマンドを実行します。

$ sbt

> test
[info] CalcSpec:
[info] - should 足し算の結果を返す
[info] CalcFunSuiteTest:
[info] - 足し算の結果を返す
[info] Run completed in 120 milliseconds.
[info] Total number of tests run: 2
[info] Suites: completed 2, aborted 0
[info] Tests: succeeded 2, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 0 s, completed 2021/05/29 23:15:25

CalcFunSuiteTestはブログには記載してませんが、同じテストを別のスタイルで書いているだけです。ここではそんなに気にしなくても大丈夫です。
すべてのテストでは無く一部のテストを実行したい場合は以下のように実行します。

> testOnly CalcSpec
[info] CalcSpec:
[info] - should 足し算の結果を返す
[info] Run completed in 324 milliseconds.
[info] Total number of tests run: 1
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 1, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 1 s, completed 2021/05/29 23:14:45

先程と違いCalcSpecだけが実行されたのがわかります。

例外をテストする

例外のテストを行なう場合もshould.Matchersで定義されているshould be thrownByを用います。
例えば先程のplusメソッドは正の数だけを受け取ることを想定しているメソッドで負の数を受け取った場合はIllegalArgumentExceptionを投げることを想定しているとします。
CalcSpecに以下のテストを追加します。

  it should "負の数が引数に渡された場合にIllegalArgumentException" in {
    val c = new Calc
    a[IllegalArgumentException] should be thrownBy {
      c.plus(1, -2)
    }
  }

このテストを実行すると以下の結果になります。

> testOnly CalcSpec
[info] CalcSpec:
[info] - should 足し算の結果を返す
[info] - should 負の数が引数に渡された場合 *** FAILED ***
[info]   Expected exception java.lang.IllegalArgumentException to be thrown, but no exception was thrown (CalcSpec.scala:13)
[info] Run completed in 118 milliseconds.
[info] Total number of tests run: 2
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 1, failed 1, canceled 0, ignored 0, pending 0
[info] *** 1 TEST FAILED ***
[error] Failed tests:
[error]         CalcSpec
[error] (Test / testOnly) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 0 s, completed 2021/05/29 23:22:03

まだ実装をしてないので失敗しますね。
それでは実装を行ってもう一度テストを実行します。
実装を以下のように修正します。

class Calc {
  def plus(a: Int, b: Int): Int = {
    require(a > 0 && b > 0)
    a + b
  }
}

Scalaの引数チェックはrequireメソッドを用いて行なうことができるようです。
こいつは条件に合致しない場合、IllegalArgumentExceptionを投げます。 テストを実行します。  

> testOnly CalcSpec
[info] CalcSpec:
[info] - should 足し算の結果を返す
[info] - should 負の数が引数に渡された場合にIllegalArgumentException
[info] Run completed in 123 milliseconds.
[info] Total number of tests run: 2
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 2, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 0 s, completed 2021/05/29 23:29:27

実行が成功しましたね。

ScalaMockでモックする

次はScalaMockを使ってモックを行ってみようと思います。
例えば以下のようなトレイトとクラスがあったとします。

trait Language {
  def greeting(): String = "Hello!!"
}

class Person(val lang: Language) {
  def saySomeThing(): String = lang.greeting()
}

class Japanese extends Language {
  override def greeting(): String = "こんにちは"
}

このPersonクラスのsaySomeThingメソッドをテストし、Languageトレイトをモックするとします。
テストは以下のように記述します。

class PersonSpec extends AnyFlatSpec with should.Matchers with MockFactory {

  it should "Languageをモックする" in {
    val mockLang = mock[Language]
    (mockLang.greeting _).expects().returning("Hello, ScalaMock!!").once()

    val target = new Person(mockLang)
    target.saySomeThing() should be ("Hello, ScalaMock!!")
  }
}

MockFactoryをミクスインすることで、ScalaMockの構文を利用することができます。
まずは、val mockLang = mock[Language]のところでMockオブジェクトを作成します。
次に、(mockLang.greeting _).expects().returning("Hello, ScalaMock!!").once()のところで、モックの設定をしてます。
書いてあるとおりですがreturningでモックのが返す値を モックが引数を期待する場合はexpects()の引数に渡すようです。
例えばなんでも良いがモックが1つの引数を期待する場合はexpects(*)とかけば良いようです。
そして最後に、once()ですがこのモックが1回実行されることを確認しています。

このテストを実行すると以下のような結果になります。

> testOnly PersonSpec
[info] PersonSpec:
[info] - should Languageをモックする
[info] Run completed in 132 milliseconds.
[info] Total number of tests run: 1
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 1, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 0 s, completed 2021/05/30 1:08:24

非同期でテストする

ScalaTestとScalaMockを非同期にするのは簡単でAsyncFlatSpecAsyncMockFactoryを利用するだけです。
先程のPersonTestのテストを非同期で行なう用に書き換えます。

import org.scalamock.scalatest.AsyncMockFactory
import org.scalatest.flatspec.AsyncFlatSpec
import org.scalatest.matchers.should

class PersonSpec extends AsyncFlatSpec with should.Matchers with AsyncMockFactory {

  it should "Languageをモックする1" in {
    val mockLang = mock[Language]
    (mockLang.greeting _).expects().returning("Hello, ScalaMock!").once()

    val target = new Person(mockLang)
    target.saySomeThing() should be("Hello, ScalaMock!")
  }


  it should "Languageをモックする2" in {
    val mockLang = mock[Language]
    (mockLang.greeting _).expects().returning("Hello, ScalaMock!!").once()

    val target = new Person(mockLang)
    target.saySomeThing() should be("Hello, ScalaMock!!")
  }
}

AnyFlatSpecMockFactoryを単純に置き換えただけです。
AnyFlatSpecに対するAsyncFlatSpecの用にスタイルごとに非同期用のものが用意されているようです。

実行すると以下のような結果になります。

> testOnly PersonSpec
[info] PersonSpec:
[info] - should Languageをモックする1
[info] - should Languageをモックする2
[info] Run completed in 151 milliseconds.
[info] Total number of tests run: 2
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 2, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.
[success] Total time: 0 s, completed 2021/05/30 1:10:53

Spring Boot 2.5についてメモ

はじめに

今週(2020/5/20)にSpring Boot 2.5が出ましたが、どんなのが出たのかまとめて、なんとなく違いを把握おこうと思います。 基本的にはRelease Notesの内容を個人的に気になったところを少し深ぼって、自分の理解をまとめようと思うので、正確な情報は本家のブログやそれに付随する記事等をご参照ください(なるべく、情報ソースのリンクはつけます)。 ちなみに、ドキュメントに書かれた変更点を自分の理解でまとめたものなので、基本的に機能に対しては動作検証などは行っておりません。

2.4からの変更点

このブログでは以下のような変更点についてまとめます。

  • DataSourceの初期化スクリプトに対するサポートの変更
  • Actuator /infoエンドポイントがよりセキュアに
  • 環境変数のプリフィクス
  • HTTP/2 over TCP (h2c)
  • R2DBCを用いたデータ初期化
  • Docker Imageバインディングサポート
  • ActuatorのPrometheusエンドポイントでOpenMetrics形式でのリソース公開

DataSourceの初期化スクリプトに対するサポートの変更

全体を眺めていると1番メインの変更っぽいです。
schema.sqldata.sqlに関するサポートがリデザインされています。
まず1つ目としてspring.datasource.*は非推奨になりspring.sql.init.*プロパティが新しく用意されました。
SqlInitializationProperties.javaでいろいろと定義されているみたいですね。
主なものをいかにまとめようと思います。spring.sql.init.のプリフィクスの部分は省略します。

プロパティ名 説明
schemaLocations スキーマDDLスクリプトのロケーション
dataLocations データ(DMLスクリプトのロケーション
username 初期化スクリプトを事項するユーザ名。もし別途設定が必要な場合
password 初期化スクリプトを事項するパスワード。もし別途設定が必要な場合
continueOnError エラーが発生してもスクリプト継続するか否か(デフォルトfalse)

spring.datasource.*から初期化スクリプトに関わるプロパティが切り出された感じっぽいですね。
また、usernamepasswordに関しては専用のものが用意されたみたいです。

Actuator /infoエンドポイントがよりセキュアに

デフォルトではActuatorの/infoエンドポイントがデフォルトでは公開されないようになりました。
しかし、Spring Securityがクラスパスにある場合は認証が求められるようになります。

2.5からの新しい機能

環境変数のプリフィクス

この機能で、同じ環境で複数のSpring Bootアプリケーションを実行、設定を行なうことができます。
SpringApplication.setEnvironmentPrefix(…​)を利用することで、この機能を利用できます。
例えばmyappというプリフィクスを付けてアプリケーションを起動する場合は以下のようにすれば可能になります。

SpringApplication application = new SpringApplication(MyApp.class);
application.setEnvironmentPrefix("myapp");
application.run(args);

この設定を行なうことで、すべてのプロパティを環境変数で変更するためにプリフィクスをつける必要があります。
例えば、ポートを変更したい場合はMYAPP_SERVER_PORTを設定する必要があります。
ちょっと動かしてみましたが、上記の設定が行われている場合SERVER_PORTではポートの変更を行なうことはできませんでした。

HTTP/2 over TCP (h2c)

マニュアル設定は無しで、HTTP/2 over TCP (h2c)、TSLではないHTTPでのHTTP/2の利用が可能となりました。
この機能を利用するためにはserver.http2.enabled=trueを設定して、かつserver.ssl.enabled=falseに設定する必要があります。
実際の実行結果は以下のようになります。

$ curl http://localhost:8080/hello -v --http2
*   Trying 127.0.0.1:8080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /hello HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.68.0
> Accept: */*
> Connection: Upgrade, HTTP2-Settings
> Upgrade: h2c
> HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 101 
< Connection: Upgrade
< Upgrade: h2c
< Date: Sun, 23 May 2021 08:59:28 GMT
* Received 101
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200 
< content-type: text/plain;charset=UTF-8
< content-length: 10
< date: Sun, 23 May 2021 08:59:28 GMT
< 
* Connection #0 to host localhost left intact
Hello, 2.5

R2DBCを用いたデータ初期化

R2DBCを通して、スクリプトベースの初期化が可能になりました。
クラスパスにschema.sqldata.sqlというスクリプトファイルがある場合は自動的に実行されるようになります。
また、JDBC同様にspring.sql.init.*プロパティを通して設定が可能です。

Docker Imageバインディングサポート

Custom Buildpacksのサポート

Custom BuildpacksがMavenでもGradleでもサポートされるようになりました。
buildpacksプロパティにディレクトリ、tar.gz、ビルダー、Dockerイメージを指定することができます。

バインディング

Mavanでも、GradleでもVolumeバインディングがサポートされました。
この機能のおかげでBuildpacksnがローカルのパスやDocker Volumeをバインドすることができます。

ActuatorのPrometheusエンドポイントでOpenMetrics形式でのリソース公開

Actuatorの/actuator/prometheusエンドポイントで通常のPrometheusの形式とOpenMetricsの形式でレスポンスを返すことが可能になってます。
application/openmetrics-text;version=1.0.0のようなヘッダーをつけることで、OpenMetricsのレスポンスを受け取ることが可能です。

Dependency Upgrades

ここに書かれるように複数の依存がアップグレードされています。

Ktorのログ出力をJsonに変える

はじめに

まえにQuarkusで同じようなことをやったのですが、Ktorだとどうなるんだろうとふと思ってやってみようと思います。
先にお伝えしておくと、タイトル詐欺ではないですが、ほぼLogbackの設定の話になりKtor特有のものはなさそうでした。
主題とは関係ないですが、KtorにはCallLoggingと呼ばれるようなリクエストのロギングを行ってれるモジュール?は用意されているみたいなのでそちらもおまけとして使ってみようと思います。

やってみる

実行環境

アプリの実行環境は以下のようになっています。

$ uname -srvmpio
Linux 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal

$ java -version
openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

$ mvn --version
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.8.0_292, vendor: Oracle Corporation, runtime: /home/yuya-hirooka/.sdkman/candidates/java/8.0.292-open/jre
Default locale: ja_JP, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-73-generic", arch: "amd64", family: "unix"

プロジェクトを作成する

Ktor Project Generatorを使ってプロジェクトを作成します。
設定は以下のとおりにします。

f:id:yuya_hirooka:20210521115755p:plain

プロジェクトは個人の趣味でMavenで作成してます。
プロジェクトをダウンロードして解答し、適当なIDEなり何なりで開きます。

起動してみる

デフォルトでは以下のようなApplication.ktというクラスがされています。

fun main(args: Array<String>): Unit = io.ktor.server.netty.EngineMain.main(args)

@Suppress("unused") // Referenced in application.conf
@kotlin.jvm.JvmOverloads
fun Application.module(testing: Boolean = false) {
    routing {
        get("/") {
            call.respondText("HELLO WORLD!", contentType = ContentType.Text.Plain)
        }
    }
}

localhost:8080/HELLO WORLD!の文字列を返すハンドラーが用意されているみたいです。
起動してみます。

$ mvn compile exec:java -Dexec.mainClass=dev.hirooka.ApplicationKt

現段階では起動時に以下のようなログが出力されます。

2021-05-21 20:22:32.657 [dev.hirooka.ApplicationKt.main()] TRACE Application - {
    # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 6
    "application" : {
        # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 7
        "modules" : [
            # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 7
            "dev.hirooka.ApplicationKt.module"
        ]
    },
    # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 2
    "deployment" : {
        # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 3
        "port" : 8080
    },
    # Content hidden
    "security" : "***"
}

2021-05-21 20:22:32.690 [dev.hirooka.ApplicationKt.main()] INFO  Application - Autoreload is disabled because the development mode is off.
2021-05-21 20:22:32.901 [dev.hirooka.ApplicationKt.main()] INFO  Application - Responding at http://0.0.0.0:8080

curlでエンドポイントにアクセスしてみます。

$ curl localhost:8080
HELLO WORLD!

アクセスログを出すようにしてみる

前述の通り、Ktorでは流入するリクエストの情報を出力してくれるCallLogging言うのものを用意してくれています。
使い方は簡単でただinstallするだけでOkです。 Application.ktを以下のように書き換えます。

@Suppress("unused") // Referenced in application.conf
@kotlin.jvm.JvmOverloads
fun Application.module(testing: Boolean = false) {
    routing {
        get("/") {
            call.respondText("HELLO WORLD!", contentType = ContentType.Text.Plain)
        }
    }
    // 追加した部分
    install(CallLogging)
}

アプリケーションを再起動して先ほどと同様のリクエストを送ると以下のようなログ出力が行われるようになります。

2021-05-21 20:46:37.840 [eventLoopGroupProxy-4-1] TRACE Application - 200 OK: GET - /

ログをJsonで出力するように変更

KtorはSLF4Jを利用したロギングが行えるようで、Project Generatorでアプリを作成した場合その実装はlogback-classicになるようです。
なので、Ktorのログ出力を変えたい場合をLogbackの出力をJsonに変える方法と同様な方法で行えます。
今回は、Logstashを使ってみたいと思います。
まずはpomの依存に以下を追加します。

<dependency>
    <groupId>net.logstash.logback</groupId>
    <artifactId>logstash-logback-encoder</artifactId>
    <version>6.6</version>
</dependency>

バージョンは最新を確認して入れるようにしてください。
次にLogbackの設定を変更してエンコーダーをLogstashのものを使うようにします。
resourceディレクトリ配下にあるlogback.xmlを以下のように修正します。

<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!--        <encoder>-->
<!--            <pattern>%d{YYYY-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>-->
<!--        </encoder>-->
        <encoder class="net.logstash.logback.encoder.LogstashEncoder" />
    </appender>
    <root level="trace">
        <appender-ref ref="STDOUT"/>
    </root>
    <logger name="org.eclipse.jetty" level="INFO"/>
    <logger name="io.netty" level="INFO"/>
</configuration>

もともとあったencoderタグの部分をコメントアウトして、net.logstash.logback.encoder.LogstashEncoderエンコーダーとして使用するようにしてます。
これで設定は完了です。 プロジェクトを再起動してみると今度はLogがJson形式で出力されるようになったのがわかります。

{"@timestamp":"2021-05-21T20:40:48.994+09:00","@version":"1","message":"{\n    # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 6\n    \"application\" : {\n        # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 7\n        \"modules\" : [\n            # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 7\n            \"dev.hirooka.ApplicationKt.module\"\n        ]\n    },\n    # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 2\n    \"deployment\" : {\n        # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 3\n        \"port\" : 8080\n    },\n    # Content hidden\n    \"security\" : \"***\"\n}\n","logger_name":"Application","thread_name":"dev.hirooka.ApplicationKt.main()","level":"TRACE","level_value":5000}
{"@timestamp":"2021-05-21T20:40:49.038+09:00","@version":"1","message":"Autoreload is disabled because the development mode is off.","logger_name":"Application","thread_name":"dev.hirooka.ApplicationKt.main()","level":"INFO","level_value":20000}
{"@timestamp":"2021-05-21T20:40:49.339+09:00","@version":"1","message":"Responding at http://0.0.0.0:8080","logger_name":"Application","thread_name":"dev.hirooka.ApplicationKt.main()","level":"INFO","level_value":20000}

スタックトレースを出力する

上記の設定ではスタックトレースの出力がされず別途設定が必要のようです。
logback.xmlを以下のように書き換えます。

<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!--    <appender name="STDOUT" class="net.logstash.logback.appender.AccessEventAsyncDisruptorAppender">-->
        <!--        <encoder>-->
        <!--            <pattern>%d{YYYY-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>-->
        <!--        </encoder>-->
        <encoder class="net.logstash.logback.encoder.LogstashEncoder">
            <throwableConverter class="net.logstash.logback.stacktrace.ShortenedThrowableConverter">
                <maxDepthPerThrowable>30</maxDepthPerThrowable>
                <maxLength>2048</maxLength>
                <shortenedClassNameLength>20</shortenedClassNameLength>
                <exclude>sun\.reflect\..*\.invoke.*</exclude>
                <exclude>net\.sf\.cglib\.proxy\.MethodProxy\.invoke</exclude>
                <rootCauseFirst>true</rootCauseFirst>
                <inlineHash>true</inlineHash>
            </throwableConverter>
        </encoder>
    </appender>
    <root level="trace">
        <appender-ref ref="STDOUT"/>
    </root>
    <logger name="org.eclipse.jetty" level="INFO"/>
    <logger name="io.netty" level="INFO"/>
</configuration>

これでスタックトレースの情報もログ出力されるようになります。
Application.ktを以下のように書き換えます。

@Suppress("unused") // Referenced in application.conf
@kotlin.jvm.JvmOverloads
fun Application.module(testing: Boolean = false) {
    routing {
        get("/") {
            throw RuntimeException("opps!!")
            //call.respondText("HELLO WORLD!", contentType = ContentType.Text.Plain)
        }
    }
    install(CallLogging)
}

curlでリクエストを送ると以下のようなログが出力されます。

{"@timestamp":"2021-05-21T21:38:19.628+09:00","@version":"1","message":"{\n    # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 6\n    \"application\" : {\n        # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 7\n        \"modules\" : [\n            # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 7\n            \"dev.hirooka.ApplicationKt.module\"\n        ]\n    },\n    # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 2\n    \"deployment\" : {\n        # application.conf @ file:/home/yuya-hirooka/source/kotlin/ktor-sandbox/logging/target/classes/application.conf: 3\n        \"port\" : 8080\n    },\n    # Content hidden\n    \"security\" : \"***\"\n}\n","logger_name":"Application","thread_name":"main","level":"TRACE","level_value":5000}
{"@timestamp":"2021-05-21T21:38:19.670+09:00","@version":"1","message":"Autoreload is disabled because the development mode is off.","logger_name":"Application","thread_name":"main","level":"INFO","level_value":20000}
{"@timestamp":"2021-05-21T21:38:19.957+09:00","@version":"1","message":"Responding at http://0.0.0.0:8080","logger_name":"Application","thread_name":"main","level":"INFO","level_value":20000}
{"@timestamp":"2021-05-21T21:38:19.957+09:00","@version":"1","message":"Application started: io.ktor.application.Application@39d9314d","logger_name":"Application","thread_name":"main","level":"TRACE","level_value":5000}
{"@timestamp":"2021-05-21T21:38:21.593+09:00","@version":"1","message":"hello","logger_name":"Application","thread_name":"eventLoopGroupProxy-4-1","level":"INFO","level_value":20000}
{"@timestamp":"2021-05-21T21:38:21.597+09:00","@version":"1","message":"Unhandled: GET - /","logger_name":"Application","thread_name":"eventLoopGroupProxy-4-1","level":"ERROR","level_value":40000,"stack_trace":"<#f0019090> j.l.RuntimeException: hello\n\tat d.h.ApplicationKt$module$1$1.invokeSuspend(Application.kt:17)\n\tat d.h.ApplicationKt$module$1$1.invoke(Application.kt)\n\tat i.k.u.p.SuspendFunctionGun.loop(SuspendFunctionGun.kt:246)\n\tat i.k.u.p.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:116)\n\tat i.k.u.p.SuspendFunctionGun.execute(SuspendFunctionGun.kt:136)\n\tat i.k.u.p.Pipeline.execute(Pipeline.kt:79)\n\tat i.k.routing.Routing.executeResult(Routing.kt:155)\n\tat i.k.routing.Routing.interceptor(Routing.kt:39)\n\tat i.k.r.Routing$Feature$install$1.invokeSuspend(Routing.kt:107)\n\tat i.k.r.Routing$Feature$install$1.invoke(Routing.kt)\n\tat i.k.u.p.SuspendFunctionGun.loop(SuspendFunctionGun.kt:246)\n\tat i.k.u.p.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:116)\n\tat i.k.f.CallLogging$Feature$install$2.invokeSuspend(CallLogging.kt:139)\n\tat i.k.f.CallLogging$Feature$install$2.invoke(CallLogging.kt)\n\tat i.k.u.p.SuspendFunctionGun.loop(SuspendFunctionGun.kt:246)\n\tat i.k.u.p.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:116)\n\tat i.k.u.p.SuspendFunctionGun.execute(SuspendFunctionGun.kt:136)\n\tat i.k.u.p.Pipeline.execute(Pipeline.kt:79)\n\tat i.k.s.e.DefaultEnginePipelineKt$defaultEnginePipeline$2.invokeSuspend(DefaultEnginePipeline.kt:124)\n\tat i.k.s.e.DefaultEnginePipelineKt$defaultEnginePipeline$2.invoke(DefaultEnginePipeline.kt)\n\tat i.k.u.p.SuspendFunctionGun.loop(SuspendFunctionGun.kt:246)\n\tat i.k.u.p.SuspendFunctionGun.proceed(SuspendFunctionGun.kt:116)\n\tat i.k.u.p.SuspendFunctionGun.execute(SuspendFunctionGun.kt:136)\n\tat i.k.u.p.Pipeline.execute(Pipeline.kt:79)\n\tat i.k.s.n.NettyApplicationCallHandler$handleRequest$1.invokeSuspend(NettyApplicationCallHandler.kt:123)\n\tat i.k.s.n.NettyApplicationCallHandler$handleRequest$1.invoke(NettyApplicationCallHandler.kt)\n\tat k.c.i.UndispatchedKt.startCoroutineUndispatched(Undispatched.kt:55)\n\tat k.c.BuildersKt__Builders_commonKt.startCoroutineImpl(Builders.common.kt:194)\n\tat k.c.BuildersKt.startCoroutineImpl(Unknown Source:1)\n\tat k.c.AbstractCoroutine.start(AbstractCoroutine.kt:145)\n\t... 1..."}

Raspberry PiでKubernetes The Hard Way(v1.21.0)をやる(失敗)

はじめに

最近、Raspberry Piを買ってKubeadmを使ってKubernetesクラスタを構築してみたので今度は、「Kubernetes The Hard Way」をやってみようと思います。

Kubernetes The Hard Way自体は、VirutalBoxを使ってやったみたことはあったのですが、その当時はほぼ手順をなぞっただけで終わってしまったので今回はきちんと理解を整理しながらやってみようかと思います。

....と思ったのですが、最終的には失敗してしまいました。 クラスターのネットワークの設定にflannelを使ったのですが、Podのネットワークにサブネットが割当されず。
クラスター側のサブネットとかぶってないかとか諸々確認したのですが、うまく行かず。一旦は断念しました。 とはいえせっかくまとめたメモとかを、そのまま消してしまうのももったいないので、最後に雑にまとめて投稿だけしようと思います。
ちょっと別の理由で環境を壊してしまった都合上、問題の分析なども行えていない(本当に、どういうログが出てて困ったのかすらも載せてない)中途半端なブログになっているので、もし何かを期待してみられる方がいるのであればおそらくこのブログは期待に添えるものではありません。

やってみる

環境構築

クライアントマシン

Kubernetesクラスタはラズパイ上に構築しますが、それぞれのラズパイにsshしたり必要なリソースを作成したりするためにThinkPadのPCを用います。
環境は以下のとおりです。

$ uname -srvmpio
Linux 5.4.0-72-generic #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.2 LTS
Release:    20.04
Codename:   focal

Raspberry Piともろもろ

ラズベリーパイ含め今回は以下のものを使って物理的な環境を構築します。
もともと家にあったのもありますが、PC以外で全部で3万円強ぐらい だったと思います。
Aamazonのリンクを貼っているものは実際に自分が購入したものです。

名前 説明 個数
Raspberry Pi 3 Model B+ 1GのRAMを持つラズパイです。秋葉原でリフレッシュ品を2つ適当に購入しました。こちらはサブNodeとして使おうと思います。 2
Raspberry Pi 4 ModelB 4GB 4GのRAMを持つラズパイです。Amazonで購入しました。こちらはMasterのNodeとして使おうと思います。 1
Micro SD 32G ラズパイのディスクとして使用します。Aamazonで購入しました。 3
ルータ親機 ラズパイをWiFiに接続したかったので、Aamazonで購入しました。 1
ロジテック スイッチングハブ 5ポート ラズパイでネットワークを構築するためにAamazonで買いました。 1
AUKEY USB充電器 50W/10A ACアダプター 5ポート ラズパイと諸々の電源として使います。 1
Raspberry Pi 4 ケース 4とありますが、3でも使えます。4段構成で、1つの段は電源を置くために使います。
Micro-USBケーブル Raspberry Pi 3、スイッチングパブ、ルータ親機の電源コードとして使います。配線が邪魔にならないように短めのものを使います。 4
USB type C Raspberry Pi 4の電源コードとして使います。配線が邪魔にならないように短めのものを使います 1
LANケーブル ラズパイとハブ、ハブとルータ親機をそれぞれつなぎます。 4
HDMIケーブル ディスプレイとラズパイをつなぎます。 1
Micro HDMI変換コネクタ Raspberry Pi 4を画面につなぐために使いました 1
ThinkPad T490 もともと持ってたPCです。Micro SDにOSのイメージを焼いたり、sshしてラズパイに諸々インストールしたりするのに使います。 1
ディスプレイ もともと持っていたものを使います 1

配線する

詳細に説明はしませんが、最終的には以下のように配線します。

f:id:yuya_hirooka:20210505115247p:plain

ラズパイ⇨電源、スイッチングハブ スイッチングハブ⇨電源、ルータ親機 ルータ親機⇨電源 ThinkPadスイッチングハブ

また、ルータ親機に関しては説明書を読みつつ自宅の無線LANに接続できるようにしておきます。
画像では電源もすでに入ってますが、この段階では大本の電源のケーブルを抜いておき、まだ電源を入れないようにしておきます。
Micro SDカードをラズパイに入れてから電源を指します。

Micro SDにUbuntuをインストールする

配線ができたら次にMicro SDにOSのイメージを焼いていきます。 今回はOSはUbuntuを使いたいと思います。Raspberry Pi 3には「Ubuntu Server 18.04.5 Arm64」のイメージ、Raspberry Pi 4には「Ubuntu Server 20.04.2 Arm64」を利用します。
それぞれ以下のページからダウンロードしてきます。

ダウンロードしてきたイメージをSDカードに焼きます。Micro SDの場合は/dev/mmcblk0にイメージを焼けば良さそうです。 以下のコマンドをそれぞれのSDカードをPCの組み込みSDカードドライブに差し込んでから実行します。

$ xzcat ubuntu-18.04.5-preinstalled-server-arm64+raspi3.img.xz | sudo dd bs=4M of=/dev/mmcblk0
0+318958 レコード入力
0+318958 レコード出力
2653289472 bytes (2.7 GB, 2.5 GiB) copied, 29.1715 s, 91.0 MB/s

Raspberry Pi 4に利用するSDカードにはubuntu-20.04.2-preinstalled-server-arm64+raspi.img.xzという名前のイメージがダウンロードされると思うので、同じコマンドを実行してください。

3枚のMicro SDカードにイメージを焼き終わったら、ラズパイに差し込んで電源を入れます。
また、ディスプレイと 電源を入れるとUbuntuのインストールがはじまります。
しばらく待つと初期ユーザネーム/パスワードを聞かれるので、ubuntu/ubuntuと入力してください。
初回のパスワード変更では任意のものを入力してください。 同様の作業をすべのSDカードで行ってください「Ubuntu20+Raspberry Pi 4」でも同様のセットアップを行ってください。

Ubuntuが起動したら、この後、諸々わかりやすくするためにホスト名を変更します。
それぞれのラズパイで/etc/hostnameを編集してホスト名を以下のように変更し、rebootコマンドで再起動します。

ホスト名 ラズパイ
leader-01 Raspberry Pi 4
worker-01 Raspberry Pi 3
worker-02 Raspberry Pi 3

今後の作業はsshして行なうため、hostname -Iコマンド等を使って、それぞれのIPも調べておきます。
僕の環境では以下のような対応付になりました。

ホスト名 ip
leader-01 192.168.13.5
worker-01 192.168.13.2
worker-02 192.168.13.3

これで、基本のところのセットアップは完了です。

クライアントツールのインストール

ThinkPadの方でクライアントツールをインストールしておきます。
インストールするのは以下のツールです。

  • kubectl
    • いわずもがな
  • cfssl、cfssljson

kubectlのインストール

まずはkubectlをインストールします。
以下のコマンドを実行してください。

$ wget https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/amd64/kubectl
$ chmod +x kubectl
$ sudo mv kubectl /usr/local/bin/

これで、インストールはOKです。
ちなみに諸事上で、僕の環境ではkubectlはv1.20.5のものを使います。

$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:10:43Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}

ドキュメントによるとkubectlは2つのバージョンがサポートされるようです。

cfssl、cfssljsonのインストール

cfsslとcfljsonはPKI公開鍵暗号基盤)を構築するために利用します。

$ wget -q --show-progress --https-only --timestamping \
  https://storage.googleapis.com/kubernetes-the-hard-way/cfssl/1.4.1/linux/cfssl \
  https://storage.googleapis.com/kubernetes-the-hard-way/cfssl/1.4.1/linux/cfssljson

$ chmod +x cfssl cfssljson

正しくインストールができていれば以下のコマンドでそれぞれバージョンが表示されるはずです。

$ cfssl version
Version: 1.4.1
Runtime: go1.12.12

$ cfssljson --version
Version: 1.4.1
Runtime: go1.12.12

これでクライアントツールのインストールは完了です。

CAのプロビジョニングとTLS証明書の発行

etcd、kube-apiserver、kubelet、kube-proxyのコンポーネント間の通信で利用されるTSL証明書の作成などを行います。

CAのプロビジョンを行なうために、CAの設定ファイルを作成します。

cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "kubernetes": {
        "usages": ["signing", "key encipherment", "server auth", "client auth"],
        "expiry": "8760h"
      }
    }
  }
}
EOF

次に、CAのための証明書署名リクエストのJsonを作成します。

cat > ca-csr.json <<EOF
{
  "CN": "Kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "CA",
      "ST": "Oregon"
    }
  ]
}
EOF

そして、CSの証明書と秘密鍵を作成します。

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca

すると以下のファイルが作成されているのを確認します。

  • ca-key.pem
  • ca.pem

クライアントとサーバの証明書発行

Kubernetesの各コンポーネントとクライアント(adminユーザ)のための証明書を発行します。

Admin クライアントの証明書の発行

Adminクライアントのための証明書署名リクエストのJsonを作成します。

cat > admin-csr.json <<EOF
{
  "CN": "admin",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:masters",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

cfssl gencertコマンドを用いて、Adminクライアントの秘密鍵と証明書を発行します。

$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  admin-csr.json | cfssljson -bare admin

その際に前に使っているCAの証明書および秘密鍵を利用します。
実行すると以下のファイルが作成されているのを確認します。

  • admin-key.pem
  • admin.pem

kubeletの証明書の発行

Kubernetesはkubeletからのリクエストの認可を行なうためにNode Authorizerと呼ばれるような特別な認可モードを利用します(詳細はこちら)。
werkerノードがNode Authriozerのリクエストを発行するための証明書を作成します。
今回はwerkerノードが2つなので以下のコマンドで証明書を発行します。

$ cat > worker-01-csr.json <<EOF
{
  "CN": "system:node:worker-01",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:nodes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF


$  cfssl gencert \
   -ca=ca.pem \
   -ca-key=ca-key.pem \
   -config=ca-config.json \
   -hostname=worker-01,192.168.13.2 \
   -profile=kubernetes \
   worker-01-csr.json | cfssljson -bare worker-01

ここで、Node Authriozerでリクエストを送るためには、system:node:worker-01worker-01の部分はノードのホスト名にする必要があります。
同様のことをworker-02でも行います。worker-01の部分を単純置換してcfssl genecertコマンドの-hostnameオプションに渡すIPは 192.168.13.3になります(手元の環境でそれぞれのIPは確認してください)。
以下の4つのファイルができると思います。

  • worker-01-key.pem
  • worker-01.pem
  • worker-02-key.pem
  • worker-02.pem

Controller Managerの証明書の発行

kube-controller-managerにも証明書を発行します。

$ cat > kube-controller-manager-csr.json <<EOF
{
  "CN": "system:kube-controller-manager",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-controller-manager",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager

kube-proxyの証明書の発行

今までと同様の方法でkube-proxyにも証明書を発行します。

$ cat > kube-proxy-csr.json <<EOF
{
  "CN": "system:kube-proxy",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:node-proxier",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-proxy-csr.json | cfssljson -bare kube-proxy

以下のファイルが作成されます。

  • kube-proxy-key.pem
  • kube-proxy.pem

Scheduler Clientの証明書の発行

Schedulerの証明書を発行します。

$ cat > kube-scheduler-csr.json <<EOF
{
  "CN": "system:kube-scheduler",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-scheduler",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-scheduler-csr.json | cfssljson -bare kube-scheduler

以下のファイルが作成されます。

  • kube-scheduler-key.pem
  • kube-scheduler.pem

Kubernetes APIサーバの証明書の発行

APIサーバの証明書を発行します。 APIサーバはleader-01にデプロイするため、IPなどは、そちらのものを利用します。

$ cat > kubernetes-csr.json <<EOF
{
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF

$ export KUBERNETES_PUBLIC_ADDRESS=192.168.13.5

$ export KUBERNETES_HOSTNAMES=kubernetes,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.svc.cluster.local

$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=10.32.0.1,10.240.0.10,10.240.0.11,10.240.0.12,${KUBERNETES_PUBLIC_ADDRESS},127.0.0.1,${KUBERNETES_HOSTNAMES} \
  -profile=kubernetes \
  kubernetes-csr.json | cfssljson -bare kubernetes

次のファイルが作成されると思います。

Service Accountの証明書を発行します。

Service Accountの証明書を発行します。

$ cat > service-account-csr.json <<EOF
{
  "CN": "service-accounts",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF


$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  service-account-csr.json | cfssljson -bare service-account

}

作成した証明書のNodeへの配置

作成した証明書を各ノードに配置しておきます。

$ scp ca.pem ca-key.pem kubernetes.pem kubernetes-key.pem  ubuntu@192.168.13.5:~/

$ scp ca.pem ca-key.pem worker-01-key.pem worker-01.pem ubuntu@192.168.13.2:~/

$ scp ca.pem ca-key.pem worker-02-key.pem worker-02.pem ubuntu@192.168.13.3:~/

認証のためのkubeconfigsの作成

KubernetesクライアントがKubernetes API Serverを発見し、認証を行なうためのkubeconfigsファイルを作成する必要があります。
kubeconfigはkubeletkube-proxyscheduleradminユーザcontroller manager用に作成します。

Kubeletのkubeconfigファイルを作成する

以下のコマンドでそれぞれのworker Nodeで動くkubeletのためのconfigファイルを作成します。
kubeletが正しく認可されるためにはkubeconfigファイルの作成にはNodeのホスト名を利用する必要があります。
また、KUBERNETES_PUBLIC_ADDRESSにはAPIサーバが動くノードのIPをセットしておきます(今回は前の工程ですでにexportしているのでそのまま利用します)。

$ for instance in worker-01 worker-02 ; do
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://${KUBERNETES_PUBLIC_ADDRESS}:6443 \
    --kubeconfig=${instance}.kubeconfig

  kubectl config set-credentials system:node:${instance} \
    --client-certificate=${instance}.pem \
    --client-key=${instance}-key.pem \
    --embed-certs=true \
    --kubeconfig=${instance}.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:node:${instance} \
    --kubeconfig=${instance}.kubeconfig

  kubectl config use-context default --kubeconfig=${instance}.kubeconfig
done

以下のファイルが作成されたと思います。

  • worker-01.kubeconfig
  • worker-02.kubeconfig

kube-proxyのkubeconfigファイルを作成する

次はkube-proxyのファイルを作成します。
以下のコマンドを実行します。

$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://192.168.13.5:6443 \
    --kubeconfig=kube-proxy.kubeconfig

 $ kubectl config set-credentials system:kube-proxy \
    --client-certificate=kube-proxy.pem \
    --client-key=kube-proxy-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-proxy.kubeconfig

 $ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-proxy \
    --kubeconfig=kube-proxy.kubeconfig

 $ kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

以下のファイルが作成されたと思います。

  • kube-proxy.kubeconfig

kube-controller-managerのkubeconfigファイルを作成する

次はkube-controller-managerのファイルを作成します。
以下のコマンドを実行します。

$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-controller-manager.kubeconfig

$ kubectl config set-credentials system:kube-controller-manager \
    --client-certificate=kube-controller-manager.pem \
    --client-key=kube-controller-manager-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-controller-manager.kubeconfig

$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-controller-manager \
    --kubeconfig=kube-controller-manager.kubeconfig

$ kubectl config use-context default --kubeconfig=kube-controller-manager.kubeconfig

以下のファイルが作成されたと思います。

  • kube-controller-manager.kubeconfig

kube-scheduler.kubeconfigのkubeconfigファイルを作成する

次はkube-schedulerのファイルを作成します。
以下のコマンドを実行します。

$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://192.168.13.5:6443 \
    --kubeconfig=kube-scheduler.kubeconfig

$ kubectl config set-credentials system:kube-scheduler \
    --client-certificate=kube-scheduler.pem \
    --client-key=kube-scheduler-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-scheduler.kubeconfig

$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-scheduler \
    --kubeconfig=kube-scheduler.kubeconfig

$ kubectl config use-context default --kubeconfig=kube-scheduler.kubeconfig

以下のファイルが作成されました。

  • kube-scheduler.kubeconfig

adminのkubeconfigファイルを作成する

次はadminのファイルを作成します。
以下のコマンドを実行します。

$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=admin.kubeconfig

$ kubectl config set-credentials admin \
    --client-certificate=admin.pem \
    --client-key=admin-key.pem \
    --embed-certs=true \
    --kubeconfig=admin.kubeconfig

$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=admin \
    --kubeconfig=admin.kubeconfig

$ kubectl config use-context default --kubeconfig=admin.kubeconfig

作成したkubeconfigのNodeへの配置

以下のコマンドを実行して、Nodeへkubeconfigへ配置します。

$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig ubuntu@192.168.13.5:~/

$ scp worker-01.kubeconfig kube-proxy.kubeconfig ubuntu@192.168.13.2:~/

$ scp worker-02.kubeconfig kube-proxy.kubeconfig  ubuntu@192.168.13.3:~/

データ暗号化の設定と鍵を作成する

Kubernetesクラスターの状態、アプリケーションコンフィグ、Sercretとなどの様々なデータをストアしています。
Kubernetesクラスターのデータを利用されていないときに暗号化して保持する機能を持っています。
ここでは、暗号化の設定と鍵を作成します。

まずは暗号化するための鍵を作成します。

$ ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)

次に設定ファイルを作成ます。

$ cat > encryption-config.yaml <<EOF
kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: ${ENCRYPTION_KEY}
      - identity: {}
EOF

作ったencryption-config.yamlをleaderのNodeに配置します。

$ scp encryption-config.yaml ubuntu@192.168.13.5:~/

Bootstrapping the etcdの起動

諸々の設定ファルの作成とその配置ができたので、コンポーネントを起動していきます。
まずは、etcdからです。
etcdは分散型のkey-valueストアでKubernetesのすべてのクラスターの情報の保存場所として利用されています。
通常はクラスターを組むと思いますが、今回はleaderのNodeは1つのためひとつだけ起動します。
leaderのNodeにsshします。

$ ssh ubuntu@192.168.13.5

ログインに成功したらセットアップを行っていきます。
まずは、etcdのバイナリをダウンロードします。

$ wget -q --show-progress --https-only --timestamping   \
   "https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-arm64.tar.gz"

cpuアーキテクチャはarm64を選択するように注意しましょう。
ダウンロードしたバイナリを回答して、/usr/local/binに配置します。

 $ tar -xvf etcd-v3.4.15-linux-arm64.tar.gz
 $ sudo mv etcd-v3.4.15-linux-arm64/etcd* /usr/local/bin/

etcdサーバのセットアップを行います。

$ sudo mkdir -p /etc/etcd /var/lib/etcd
$ sudo chmod 700 /var/lib/etcd
$ sudo cp ca.pem kubernetes-key.pem kubernetes.pem /etc/etcd/

systemdで管理するためにユニットファイルを作成します。
以下のコマンドを実行します。

cat <<EOF | sudo tee /etc/systemd/system/etcd.service
[Unit]
Description=etcd
Documentation=https://github.com/coreos

[Service]
Type=notify
ExecStart=/usr/local/bin/etcd \\
  --name leader-01 \\
  --cert-file=/etc/etcd/kubernetes.pem \\
  --key-file=/etc/etcd/kubernetes-key.pem \\
  --peer-cert-file=/etc/etcd/kubernetes.pem \\
  --peer-key-file=/etc/etcd/kubernetes-key.pem \\
  --trusted-ca-file=/etc/etcd/ca.pem \\
  --peer-trusted-ca-file=/etc/etcd/ca.pem \\
  --peer-client-cert-auth \\
  --client-cert-auth \\
  --initial-advertise-peer-urls https://192.168.13.5:2380 \\
  --listen-peer-urls https://192.168.13.5:2380 \\
  --listen-client-urls https://192.168.13.5:2379,https://127.0.0.1:2379 \\
  --advertise-client-urls https://192.168.13.5:2379 \\
  --initial-cluster-token etcd-cluster-0 \\
  --initial-cluster leader-01=https://192.168.13.5:2380 \\
  --initial-cluster-state new \\
  --data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
Environment="ETCD_UNSUPPORTED_ARCH=arm64"

[Install]
WantedBy=multi-user.target
EOF

systemdでetcdを起動します。

$ sudo systemctl daemon-reload
$ sudo systemctl enable etcd
$ sudo systemctl start etcd

起動に成功していれば以下のコマンドでリストが取得できると思います。

$ sudo ETCDCTL_API=3 etcdctl member list \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/etcd/ca.pem \
  --cert=/etc/etcd/kubernetes.pem \
  --key=/etc/etcd/kubernetes-key.pem

6ceeb31f89f1fb0d, started, leader-01, https://192.168.13.5:2380, https://192.168.13.5:2379, false

Kubernetes Control Planeの起動

Control Planeを起動しいきます。

Control Planeとは

  • kube-apiserver
  • kube-scheduler
    • Podに対してNodeが割り当てられているか監視し、当てられていなかった場合はNodeの割当を行います。
  • kube-controller-manager
    • 各コントローラーのプロセスを実行します。コントローラーはコントロールループの中でクラスターの状態を監視し必要に応じて変更をくわえたり、要求したりしクラスターが望ましい状態になるように調整を行います。代表的なコントローラーには以下のようなものがあります。
      • Deploymentコントローラー
      • ReplicaSetコントローラー
      • CronJobコントローラー

コントロールプレーンの各コンポーネントのより詳細の情報に関してはこちらを確認ください。

バイナリダウンロードと配置

それではインストールしていきます。 etcd同様この作業もleaderのNodeで行います。
まずは、kubernetesの設定を配置するディレクトリを作成します。

$ sudo mkdir -p /etc/kubernetes/config

次にそれぞれのバイナリソースを取得します。
Control Planeとkubectlもインストールします。

wget -q --show-progress --https-only --timestamping \
  "https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kube-apiserver" \
  "https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kube-controller-manager" \
  "https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kube-scheduler" \
  "https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kubectl"

ダウンロードしたバイナリに実行権限を与え、適当なところに配置します。

$ chmod +x kube-apiserver kube-controller-manager kube-scheduler kubectl
$ sudo mv kube-apiserver kube-controller-manager kube-scheduler kubectl /usr/local/bin/

Kubernetes API Serverの設定を行なう

API Serverを設定していきます。

まずは証明書を配置するディレクトリを作成して、証明書をいどうさせます。

$ sudo mkdir -p /var/lib/kubernetes/

$ sudo mv ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem \
   service-account-key.pem service-account.pem \
   encryption-config.yaml /var/lib/kubernetes/

API Serverをsystemdで起動したいので、ユニットファイルを作成します。

cat <<EOF | sudo tee /etc/systemd/system/kube-apiserver.service
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-apiserver \\
  --advertise-address=192.168.13.5 \\
  --allow-privileged=true \\
  --apiserver-count=3 \\
  --audit-log-maxage=30 \\
  --audit-log-maxbackup=3 \\
  --audit-log-maxsize=100 \\
  --audit-log-path=/var/log/audit.log \\
  --authorization-mode=Node,RBAC \\
  --bind-address=0.0.0.0 \\
  --client-ca-file=/var/lib/kubernetes/ca.pem \\
  --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \\
  --etcd-cafile=/var/lib/kubernetes/ca.pem \\
  --etcd-certfile=/var/lib/kubernetes/kubernetes.pem \\
  --etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \\
  --etcd-servers=https://127.0.0.1:2379 \\
  --event-ttl=1h \\
  --encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \\
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \\
  --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \\
  --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \\
  --runtime-config='api/all=true' \\
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\
  --service-account-signing-key-file=/var/lib/kubernetes/service-account-key.pem \\
  --service-account-issuer=https://192.168.13.5:6443 \\
  --service-cluster-ip-range=10.32.0.0/24 \\
  --service-node-port-range=30000-32767 \\
  --tls-cert-file=/var/lib/kubernetes/kubernetes.pem \\
  --tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \\
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

Kubernetes Controller Managerの設定を行なう

Controller Managerの設定を行っていきます。

kube-controller-manager.kubeconfig/var/lib/kubernetesに配置します。

sudo mv kube-controller-manager.kubeconfig /var/lib/kubernetes/

Controller Managerのユニットファイルを作成します。

$ cat <<EOF | sudo tee /etc/systemd/system/kube-controller-manager.service
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-controller-manager \\
  --bind-address=0.0.0.0 \\
  --cluster-cidr=10.200.0.0/16 \\
  --cluster-name=kubernetes \\
  --cluster-signing-cert-file=/var/lib/kubernetes/ca.pem \\
  --cluster-signing-key-file=/var/lib/kubernetes/ca-key.pem \\
  --kubeconfig=/var/lib/kubernetes/kube-controller-manager.kubeconfig \\
  --leader-elect=true \\
  --root-ca-file=/var/lib/kubernetes/ca.pem \\
  --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem \\
  --service-cluster-ip-range=10.32.0.0/24 \\
  --use-service-account-credentials=true \\
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

Kubernetes Schedulerの設定を行なう

Schedulerの設定を行っていきます。
kube-scheduler.kubeconfig/var/lib/kubernetesに配置します。

$ sudo mv kube-scheduler.kubeconfig /var/lib/kubernetes/

次に、kube-scheduler.yamlを作成します。

$ sudo mkdir -p /etc/kubernetes/config/

$ cat <<EOF | sudo tee /etc/kubernetes/config/kube-scheduler.yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: "/var/lib/kubernetes/kube-scheduler.kubeconfig"
leaderElection:
  leaderElect: true
EOF

systemdのユニットファイルを作成します。

cat <<EOF | sudo tee /etc/systemd/system/kube-scheduler.service
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-scheduler \\
  --config=/etc/kubernetes/config/kube-scheduler.yaml \\
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

各Control Planeの起動

コンポーネントのユニットファイルは作成したので、読み込んで起動します。

$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-apiserver kube-controller-manager kube-scheduler
$ sudo systemctl start kube-apiserver kube-controller-manager kube-scheduler

起動が正常にできているか以下のコマンドで確認します。

$ kubectl cluster-info --kubeconfig admin.kubeconfig

Kubernetes control plane is running at https://127.0.0.1:6443

Kubernetes control plane is runningというのが出ていればOKっぽいです。

KubeletへのRBACの設定を行なう

API Serverが各Workerで動くKubeletへのアクセスをするためのRBACの設定を行います。
API Serverはメトリクスの収集、ログの取得、Pod内でのコマンド実行などのためにkubeletにアクセスします。

以下のコマンドを実行して、system:kube-apiserver-to-kubelet ClusterRoleを作成します。

$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

API ServerはKubuletにkubernetesユーザとして認証します。なので、先程作ったsystem:kube-apiserver-to-kubelet ClusterRolekubernetesユーザにバインドします。

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kubernetes
EOF

Worker Nodeの起動

2つのworker Nodeを起動します。
Worker Nodeでは以下のようなソフトウェアが起動します。

  • runc
    • OCI Specificationに沿って、コンテナの生成、実行を行なうCLIツール
  • container networking plugins
  • containerd
  • kubelet
    • 各ノードで動作する主要なNodeエージェント。API Serverにホスト名等を使ってNodeを登録する。PodSpecのセットを取得し、PodSpecに記載されているコンテナが正常に動作している状態を保証する
  • kube-proxy
    • 各ノードで動作するネットワークプロキシ。Nodeのネットワークルールをメンテナンスする。

Worker Nodeをプロビジョニングする

以下の操作は各Worker Nodeで実行します。なお、説明ではworker-01でセットアップを行い02のセットアップは省略しますが基本的に同じようなセットアップを行います(別途、別の操作が必要な場合は補足します)。

最初にworker-01にアクセスします。

$ ssh ubuntu@192.168.13.2

必要な依存を取得してきます。

$ sudo apt-get update
$ sudo apt-get -y install socat conntrack ipset

socatkubectl port-forwardコマンドのサポートを行なうために必要なようです。

デフォルトではkubeletはswapが有効化されていると起動しません。
以下のコマンドを実行した際に出力がなにもなければswapは有効化されていません。

$ sudo swapon --show

もし、有効化されていた場合は以下のコマンドで、無効にしてください。

$ sudo swapoff -a

無効化が確認できたら、必要なバイナリをインストールします。

まずはバイナリをダウンロードします。

$ wget -q --show-progress --https-only --timestamping \
  https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.21.0/crictl-v1.21.0-linux-arm64.tar.gz \
  https://github.com/containernetworking/plugins/releases/download/v0.9.1/cni-plugins-linux-arm64-v0.9.1.tgz \
  https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kubectl \
  https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kube-proxy \
  https://storage.googleapis.com/kubernetes-release/release/v1.21.0/bin/linux/arm64/kubelet

次に必要なディレクトリを作成しておきます。

$ sudo mkdir -p \
  /etc/cni/net.d \
  /opt/cni/bin \
  /var/lib/kubelet \
  /var/lib/kube-proxy \
  /var/lib/kubernetes \
  /var/run/kubernetes

バイナリを各ディレクトリに移動 or 解凍します。

$ tar -xvf crictl-v1.21.0-linux-arm64.tar.gz
$ sudo tar -xvf cni-plugins-linux-arm64-v0.9.1.tgz -C /opt/cni/bin/
$ chmod +x crictl kubectl kube-proxy kubelet  
$ sudo mv crictl kubectl kube-proxy kubelet /usr/local/bin/

containerdとruncに関してはarm64アーキテクチャでのインストールにはひと工夫が必要です。 まず、containerdですが、このIssueによるとdownload.docker.comで提供されているものがあるみたいだったのでそちらを利用させていただこうと思います。

以下のコマンドでインストールします。

$ wget https://download.docker.com/linux/ubuntu/dists/focal/pool/test/arm64/containerd.io_1.4.3-2_arm64.deb
$ sudo apt install ./containerd.io_1.4.3-2_arm64.deb
$ containerd -v
containerd containerd.io 1.4.3 269548fa27e0089a8b8278fc4fc781d7f65a939b

続いて、runcですが、こちらは公式での提供が内容だったので(少なくとも僕が調べる限りでは)自分でビルドしようと思います。
ビルドは1番スペックがよいmaster-01で行って、実行ファイルをcspでそれぞれのworkerに配布しようと思います。

$ ssh ubuntu@192.168.13.5

まず、ビルドにはgo が必要なようなので、goのインストールを行います。

$ wget https://golang.org/dl/go1.16.3.linux-arm64.tar.gz
$ sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.16.3.linux-arm64.tar.gz 
$ export PATH=$PATH:/usr/local/go/bin
$ go version
go version go1.16.3 linux/arm6

次にビルドに必要な依存をとってきます。

$ sudo apt install build-essential
$ sudo apt install pkg-config
$ sudo apt install -y libseccomp-dev

最後にソースコードを取得して、ビルドを行います。

$ git clone https://github.com/opencontainers/runc
$ cd runc
$ make
$ sudo make install

ビルドが完了したらできた実行ファイルをそれぞれのworkerに配布します。

$ scp /usr/local/sbin/runc ubuntu@192.168.13.2:~/
$ scp /usr/local/sbin/runc ubuntu@192.168.13.3:~/

それぞれのworkerで適当なディレクトリにruncを移動します。

$ sudo mv runc /usr/local/bin/
$ runc -v
runc version 1.0.0-rc93+dev
commit: 2965ffc7e327dc3dc33a9b308ba8396e60e5bb58
spec: 1.0.2-dev
go: go1.16.3
libseccomp: 2.4.3

(versionの指定をちゃんとしてなかったので、devがインストールされてしまってますね...一旦ここでは先に進みます)

CNIの設定を行なう

bridgeネットワークの設定ファイルを作成します。

$ cat <<EOF | sudo tee /etc/cni/net.d/10-bridge.conf
{
    "cniVersion": "0.4.0",
    "name": "bridge",
    "type": "bridge",
    "bridge": "cnio0",
    "isGateway": true,
    "ipMasq": true,
    "ipam": {
        "type": "host-local",
        "ranges": [
          [{"subnet": "10.200.0.0/24"}]
        ],
        "routes": [{"dst": "0.0.0.0/0"}]
    }
}
EOF

loopbackのネットワーク設定を記述します。

$ cat <<EOF | sudo tee /etc/cni/net.d/99-loopback.conf
{
    "cniVersion": "0.4.0",
    "name": "lo",
    "type": "loopback"
}
EOF

kubeletの設定を行なう

kubeletのための設定や証明書を必要なディレクトリに配置します。

$ sudo mv ${HOSTNAME}-key.pem ${HOSTNAME}.pem /var/lib/kubelet/
$ sudo mv ${HOSTNAME}.kubeconfig /var/lib/kubelet/kubeconfig
$ sudo mv ca.pem /var/lib/kubernetes/

kubelet-config.yamlを作成します。

$ cat <<EOF | sudo tee /var/lib/kubelet/kubelet-config.yaml
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/var/lib/kubernetes/ca.pem"
authorization:
  mode: Webhook
clusterDomain: "cluster.local"
clusterDNS:
  - "10.32.0.10"
podCIDR: "10.200.0.0/24"
resolvConf: "/run/systemd/resolve/resolv.conf"
runtimeRequestTimeout: "15m"
tlsCertFile: "/var/lib/kubelet/${HOSTNAME}.pem"
tlsPrivateKeyFile: "/var/lib/kubelet/${HOSTNAME}-key.pem"
EOF

kubuletのユニットファイルを作成します。

cat <<EOF | sudo tee /etc/systemd/system/kubelet.service
[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=containerd.service
Requires=containerd.service

[Service]
ExecStart=/usr/local/bin/kubelet \\
  --config=/var/lib/kubelet/kubelet-config.yaml \\
  --container-runtime=remote \\
  --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \\
  --image-pull-progress-deadline=2m \\
  --kubeconfig=/var/lib/kubelet/kubeconfig \\
  --network-plugin=cni \\
  --register-node=true \\
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

containerdの設定を行なう

containerdの設定ファイルを作成します。
以下のコマンドを実行します。

cat << EOF | sudo tee /etc/containerd/config.toml
[plugins]
  [plugins.cri.containerd]
    snapshotter = "overlayfs"
    [plugins.cri.containerd.default_runtime]
      runtime_type = "io.containerd.runtime.v1.linux"
      runtime_engine = "/usr/local/bin/runc"
      runtime_root = ""
EOF

Kubernetes Proxyの設定を行なう

kube-proxyの設定を行います。
まずは、必要な設定ファイルを適当なディレクトリに配置します。

$ sudo mv kube-proxy.kubeconfig /var/lib/kube-proxy/kubeconfig

次にkube-proxy-config.yamlを作成します。

$ cat <<EOF | sudo tee /var/lib/kube-proxy/kube-proxy-config.yaml
kind: KubeProxyConfiguration
apiVersion: kubeproxy.config.k8s.io/v1alpha1
clientConnection:
  kubeconfig: "/var/lib/kube-proxy/kubeconfig"
mode: "iptables"
clusterCIDR: "10.200.0.0/16"
EOF

例のごとく、ユニットファイルを作成します。

cat <<EOF | sudo tee /etc/systemd/system/kube-proxy.service
[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-proxy \\
  --config=/var/lib/kube-proxy/kube-proxy-config.yaml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

コンポーネントの起動

設定が完了したので、最後にコンポーネントを起動します。
以下のコマンドを実行します。

$ sudo systemctl daemon-reload
$ sudo systemctl enable containerd kubelet kube-proxy
$ sudo systemctl start containerd kubelet kube-proxy

正常に起動が完了すると、leader-01からNodeが認識されているのが確認できます。

$ kubectl get nodes --kubeconfig admin.kubeconfig
NAME        STATUS   ROLES    AGE     VERSION
worker-01   Ready    <none>   8m2s    v1.21.0
worker-02   Ready    <none>   8m59s   v1.21.0

リモートからkubectlでアクセスできるようにする

kubectlの設定を行って毎回--kubeconfig等でファイルを指定しなくても良いようにします。
ThinkPadのクライアントPCで以下のコマンドを実行します。

$ kubectl config set-cluster kubernetes-the-hard-way \
   --certificate-authority=ca.pem \
   --embed-certs=true \
   --server=https://192.168.13.5:6443

$ kubectl config set-credentials admin \
   --client-certificate=admin.pem \
   --client-key=admin-key.pem

$ kubectl config set-context kubernetes-the-hard-way \
   --cluster=kubernetes-the-hard-way \
   --user=admin

$ kubectl config use-context kubernetes-the-hard-way

kubectl get nodeでNodeの一覧を取得できるようになってます。

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.5", GitCommit:"6b1d87acf3c8253c123756b9e61dac642678305f", GitTreeState:"clean", BuildDate:"2021-03-18T01:10:43Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:25:06Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"linux/arm64"}


$ kubectl get node
NAME        STATUS   ROLES    AGE   VERSION
worker-01   Ready    <none>   16m   v1.21.0
worker-02   Ready    <none>   17m   v1.21.0

Podネットワークルールのプロビジョニングを行なう

Pod間の通信を行なうためにflannelクラスタにインストールします。
flannelはkubernetesのlayer 3でのネットワーク設定を行ってくれます。

$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

このあと失敗した

ここまでは、いろいろ苦難しつつもできたのですが、前述の通りflannelがうまく動かず失敗しました。
また、時間が立ってから再度やってみようと思います。