こんにちは!!こんにちは!!
インフラエンジニアのyamamotoです。
ついに、ついに「いこーよ」も kubernetes(k8s) を導入しました！
弊社morishitaと半年みっちり集中して、ようやく導入することができました。
今回はその体験談をお話したいと思います。
とにかく用語を覚えるのが大変
kubernetesを勉強し始めた時、まず大変だったのが、難解な用語を覚えることでした。
pod、replicaset、deployment、ingress、daemonset、クラスタ、ノード……と言われても、何のことやらって感じですよね。
しかしkubernetesをやるなら、これらは覚えて概念を理解しないと始まりません。
とにかく理解できるまで書籍やWebサイトを読みまくり、手元のMacで実際に動作させて覚えました。
概念的には、従来のインフラ環境から連想できることも多く、なんとなくイメージできたので、意外とすんなり入ってきました。
基礎を知っていることは非常に大事なことですね。
環境を整えるのが面倒
kubernetesはコンテナ技術を使っています。そのため、dockerイメージを保存しておくリポジトリがどこかに必要になります。
また、サイトのWebアプリケーションをリリースするのに、毎回dockerイメージをビルドする必要があります。
まずはこれらの環境を整える必要がありました。従来のインフラ環境に比べて、このあたりがちょっと面倒に感じられるかもしれません。
当社はAWSをメインに使っているので、CodePipelineやCodeBuildを活かして、GitHubリポジトリのmasterにマージされたら自動的にdockerイメージをビルドするCIを作成しました。
このあたりのパイプラインや、サブネット、EKSなどのAWS環境を整えるのに、今回AWS CDKを使って全てコード化しました。これはCloudFormationのスタックをTypeScript等で作れるツールです。YAMLやJSONでスタックを作るのはしんどいので、今回大活躍しました。
マニフェスト？
kubernetesでインフラをデプロイするにはマニフェストが必要になります。
マニフェストとはなんぞや？と思いましたが、要はどういうインフラを構築したいかをYAML等で書いたものになります。
まさにインフラのコード化ですね。
kubernetesを使うにはマニフェストは必須で、非常に多くの設定があり複雑です。また、デプロイする環境も開発環境、本番環境でもリリース前検証環境、実本番環境と複数の種類があります。
環境の差については「kustomize」を使う必要がありました。これはマニフェストを差分更新したりできる機能で、環境に依る部分はkustomizeを使って書き換えることで、各環境の設定を簡単に管理できるようになりました。
マニフェストについても、とにかく書いてみて、デプロイしてみて覚えるのが一番だと思います。
kubernetesの用語や概念を覚えられたら、書くこと自体はそれほど難しくないです。
実際のパフォーマンスはどうか？
kubernetes環境を構築して、podも立ち上げたところで、実際パフォーマンスがどのぐらい出るのか気になりますよね。
当社では負荷テストやパフォーマンステストを行って検証しました。
負荷テストはjmeterを使って、徐々にリクエストを増やして最大200req/sぐらいまで試してみました。
その中で、Horizontal Pod Autoscalerで自動的にpodが増え、Cluster Autoscalerによってノードが増える状態が確認できました。
パフォーマンステストでは、webpagetestを使ってレスポンスタイムを測りました。
kubernetesのpodは稼働させていないと休眠状態になるのか、何もない状態でいきなりアクセスするとレスポンスが悪くなるようです。
でも継続したアクセスがあると、結構いいレスポンスタイムが得られるんですよね。
こちらも、現行環境と比較して遜色ないレスポンスタイムだったので問題は無さそうでした。
実際にリリースしてみると、これまでのEC2の環境より安定して早いレスポンスを返せるようになりました。
最後に
なんだかマイナス面ばかり書いてしまいましたが、導入してみるととても便利ですね。
障害復旧が早いですし、実行環境のアップデートもコンテナを更新するだけ。デプロイも非常に楽ですし早いです。
何よりkubernetesがいろいろよしなにやってくれるところがイイですね！
機会があったらぜひ触ってみてください。
