KubernetesでRubotyを動かして自動復旧を味わう
Kubernetes(以降k8s)の勉強をしたかったので、Rubotyが動くように試行錯誤して構成を整えてみました。 k8sで特に気になっていたのがPodの自動復旧で、障害発生で止まってしまった時にどのように振る舞うのかを手元で実験しました！
Dockerfileの構成はシンプルで、Dockerfileを以下のように定義してDockerhubにあげています。
手元においたファイルをワーキングディレクトリに突っ込んで、bundle exec ruboty --dotenvでrubotyを実行しています。
FROM ruby:2.3.0-alpine
RUN apk update && \
apk add build-base openssl
RUN mkdir /ruboty
ADD Gemfile /ruboty
ADD Gemfile.lock /ruboty
ADD .env /ruboty
WORKDIR /ruboty
RUN bundle install --path vendor/bundle
CMD ["bundle", "exec", "ruboty", "--dotenv"]
今回は、自動復旧の様子が見たいので、ReplicaSetを使ってyamlを定義しています。 ReplicaSetではテンプレートに従ったPod が、どんな時でも正しい数で動作するよう調整してくれるので、今回の実験にベストフィットです。
apiVersion: apps/v1 kind: ReplicaSet metadata: name: ruboty labels: app: ruboty spec: replicas: 1 selector: matchLabels: app: ruboty template: metadata: labels: app: ruboty spec: containers: - name: ruboty image: "keisuketsukamoto/ruboty:v1" imagePullPolicy: IfNotPresent
replicas: 1で定義されているように常に1Pod動作してほしいのでこのPodが意図的にdeleteされた場合であっても自動復旧してくれることが予想できます。
$ kubectl apply -f rs.yaml
で構成展開します。
$ kubectl get pods NAME READY STATUS RESTARTS AGE ruboty-cx6qc 1/1 Running 0 9s
Podが立ち上がりました。nameの後ろの値は自動で振り分けられたハッシュ値です。 ruboty自体もちゃんと起動しています。
今回、実験したかったのは不具合で落ちてしまった場合の自動復旧なので、ここでおもむろにPodを削除します。
$ kubectl delete pod ruboty-cx6qc
そして、Podsを表示
$ kubectl get pods NAME READY STATUS RESTARTS AGE ruboty-cx6qc 1/1 Terminating 0 28s ruboty-qblv9 0/1 ContainerCreating 0 3s
削除されたPodsはStatusがTerminatingになりましたが、ReplicaSetでreplicas: 1としているので1Podが常に動作している状態に戻すために復旧が始まります。
$ kubectl get pods NAME READY STATUS RESTARTS AGE ruboty-qblv9 1/1 Running 0 18s
これは、Podのオートヒーリング機能によるもので、ReplicationManagerがPodの状態を監視して、実際に稼働しているPodとマニフェストで定義したreplicasに差異が出た場合、Podの数を調整してくれるものです。
まとめ
ウェブエンジニアがインフラっぽいことに少しでも手が出せるようなるのでとても興味深い技術ですし、これからスタンダードになっていくので大注目してます。 今回のコードはgithubに公開しています。
参考
以下のブログを参考にさせていただきました！とても助かりました！
