2ヶ月ぶりのブログとなります。「最近ブログ書いてなくないですか?あだちんさん何やってるんですか?」と思う方もいらっしゃると思いますが、ご安心ください。業務がAzureとKubernetesなので、覚えることも多くてヒーヒー言っております。最近は備忘録の方で(https://wiki.adachin.me)アウトプットをしております。業務でやってきたことなどは後ほどアドベントカレンダーでむちゃくちゃ書くのでしばしお待ちください!

[DigitalOcean][Kubernetes]WordPressコンテナをCircleCIで自動デプロイとローリングアップデートを実装してみた

さて、以前個人のKubernetes(https://wiki.adachin.me)でCircleCIを利用して自動デプロイと、ローリングアップデートを実装しました。しかし、ローリングアップデート時にダウンタイムが発生してしまうことが起き、一旦レプリカを2台にすることで解決しました。そこで、今回StatefulSetからDeploymentに移行し、ダウンタイムなしで改善することができたのでブログします。


懸念点とDeploymentに移行

https://kubernetes.io/ja/docs/concepts/workloads/controllers/statefulset/

https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/

[K8s] DeploymentとStatefulSetの違い

  • 既存のデプロイフロー

そもそもStatefulSetで運用していたということもあって、デプロイ、スケーリング、ローリングアップデートは順序付けされた動作の元に実行されるようになっています。さらに公式ではデータベースやキャッシュなどの持続的な状態の管理が必要な場合に適しているので、WordPressコンテナはWebサーバーなので、Developmentの方がふさわしいです。(そもそもなぜStatefulSetにしているのかは以下変更点で書いています)

以下リンクより、Kubernetesは新しいPodが起動したことまでは検知できますが、Running状態になったことを検知しないようで、ダウンタイムの発生がある前提のようです。

https://nilesh93.medium.com/enable-rolling-updates-in-kubernetes-with-zero-downtime-31d7ec388c81

また、対策としてはreadinessProbeによるヘルスチェックを設定すればStatefulSetでもレプリカ1台でいけるか!?と思いましたが、普通にダウンタイムになってしまったのと、通常時に2台ある前提ということもあり、用途もWebサーバーなので、Deploymentに移行しました。Deploymentであれば、ローリングアップデートのカスタマイズが豊富にあるので、色々と調整がしやすいことも分かりました。早速修正点を書いていきましょう。


変更点

  • k8s/wiki/manifests/wordpress.yaml

https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/#deployment%E3%81%AE%E3%83%AD%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88

https://kubernetes.io/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

まずはkindからDeploymentにしていますが、11行目での maxSurge宣言したPod数で、レプリカ1台とmaxSurge1台でローリングアップデートをしていきます。 12行目の maxUnavailableアップデート時に許容したunavailableになるPod数でデフォルト値を指定しています。次は34行目の readinessProbe によるヘルスチェックの設定ですが、今回はtcpSocketでのエンドポイントを指定しています。httpでのエンドポイントにしたかったのですが、うまくいかなかったので後ほど調査していきます。 initialDelaySeconds ではコンテナが起動してからヘルスチェックを始めるまでを5秒にして、 periodSecondsヘルスチェックの間隔も5秒にしました。

ついでにKubernetesもバージョンアップして以下エラーが出たので、24行目でコンテナのリソース(CPU,Memory)も指定しました。

[Kubernetes]Set resource requests and limits for container `hoge` to prevent resource contention

※ちなみに元々はDeploymentだったのが、2年前のバージョンアップで以下のエラーでStatefulSetに変更してしまったという…(知識がなかったんだな..)一旦エラーはそのまま出ていましたが、サービスの影響はないので、persistentVolumeClaimは指定したままにしました。今後はボリュームマウントを廃止してリポジトリをコピーしてbuildするように修正する予定です。

Pod referencing DOBS volumes must be owned by StatefulSet

[DigitalOcean]wiki.adachin.meのKubernetesをv1.15からv1.21にバージョンアップしました!

設定はこれで完了なので、デプロイしてみましょう。


動作確認

  • Rolling Update

ECSと比べると切り替わるスピードが早い..!30秒くらいかな?


まとめ

これで安全にリリースできるようになったのと、Pod数も1台になったのでリソースを削減することができました。しかしKubernetesは難しい….次回はボリュームマウントの廃止、WordPressコンテナのNginxを分離、PHP8.3にバージョンアップしていきます。NewRelicにも移行だ…

個人のインフラ環境やりたいことが多すぎて壮大過ぎる。



adachin

1989年生まれのFindy/SRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWSでのインフラ構築、Docker開発環境の提供、IaC、新技術の検証、リファクタリング、セキュリティ強化、分析基盤の運用などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTA/TechBullで未経験者にインフラのコーチング/コミュニティマネージャーとして立ち上げと運営をしている。また、過去「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください