1. ホーム /
  2. WESEEK Tech Blog /
  3. k8s /
  4. Rancherを利用した社内Kubernetes構築
  • 2019.09.09
  • 2023.04.17

Rancherを利用した社内Kubernetes構築

本記事では SEROKU の開発を例に社内 Kubernetes の紹介をしています。

WESEEK の kouki です。SEROKU では主にインフラ担当をしています。

今回は社内で展開しつつ、SEROKU の開発でも利用している社内 Kubernetes 環境についてご紹介します。具体的な構築ログはこちらに記載しています。

Qiita: 快適な kubernetes オンプレミス環境を構築する(1. 設計編)

上記の記事は淡々と記載していますが、今回は社内 Kubernetes での利用例や実は苦労した点をつらつらと書かせていただきます。

はじめに、SEROKU の開発は Jenkins などを利用して CI/CD 環境を構築しています。マルチブランチパイプラインによる各トピックブランチのテスト実施など、昨今では「当たり前」になっている環境を提供しています。

SEROKU での社内 Kubenetes 利用例

そういった開発を行っているうちに、「トピックブランチのデモを簡単に作れるといいなぁ」という要望が社内から上がりました。

本番環境は GKE(Google Kubernetes Engine) を利用していますが、社内サーバの活用と Kubenetes ノウハウ蓄積のために Kubernetes クラスタを社内に構築することに至りました。

具体的には以下のような流れでトピックブランチのデモ環境を活用しています。

  1. 開発者が開発用にトピックブランチ切る
  2. 開発者が手元で開発を行い、適宜完成したらレポジトリに commit
  3. 開発者が実装が終わったら、レビュー担当者にレビュー依頼
  4. 開発者が社内 Kubernetes 環境にトピックブランチをデプロイ & 別の開発者に動作確認を依頼
  5. 動作確認者が社内 Kubernetes 環境に構築されたデモ環境を使って動作確認
  6. レビュー担当者が動作確認まで完了をしていることを確認して、リリース用ブランチにマージ

Kubernetes にデモをデプロイする手順は、社内 wiki に記載して開発者に周知しています。各開発者の方たちはスムーズにデモ環境の構築ができているようです。

構築するときに苦労した点

GKE と同様の環境を構築するにあたって苦労した点を紹介します。

Kubernetes クラスタ自体を構築するのは rancher を使ったため、とても容易に構築できました。しかし、実利用という観点から考えると様々な懸念点が浮上してきました。

  1. インターネット上にデモを公開するとして、グローバル IP アドレスはどの Node が受け持つのか？

    • グローバル IP アドレスとプライベート IP アドレスを 2つ持つ Node に Ingress 相当を担当させることができるか？

  2. GKE 環境にデプロイするときには Google Container Registry を利用すればいいが、社内に閉じるためにはプライベートなレジストリが必要

  3. GKE は PersistentVolume を意識しなくてもよいが、社内 Kubernetes の PersistentVolume は何を使う？

構築した時期が 2017年の末あたりだったので、ネットに情報も少なく海外のサイトを渡り歩いたり、公式ドキュメントを読み込んだりしていました。調査をしているうちに、いくつかシンプルに実装できる方法が分かってきました。

  1. の問題に対する解決方法

    • グローバル IP アドレスを持つ Node に対して、 nginx-ingress-controller を DaemonSet として動作させることによって意図した動作ができるようになりました。

  2. の問題に対する解決方法

    • docker-registry と Portus をコンテナとしてクラスタにデプロイすることによって、プライベートなレジストリを利用することができました。また、Portus には LDAP 認証機能が付いているので、社内の LDAP と連携することができました。

  3. の問題に対する解決方法

    • 社内に NFS サーバを構築して、 nfs-client-provisioner を利用することで解決しました。他にも Rook などの選択肢もありましたが、分散ストレージ運用よりもインフラ環境のシンプルさを選択しました。

まとめ

私は開発も担当していますが、調査などを含めて1ヵ月程度で構築することができました。トピックブランチのデモができるようになったことで、SEROKU の新機能実装や画面イメージなどが共有しやすくなりました。

また、社内 Kubernetes 環境が構築されたことで、社内のアプリをコンテナ化する気概が高まったという点が一番のメリットだと感じています。

SEROKU 以外にも、Prometheus や Jenkins X など様々なインフラツールを試す土壌ができているため、興味があるメンバーは社内 Kubernetes にお手軽に環境を構築していたりもします。最近はアプリ側も helm package にして、煩雑になりがちな Kubernetes の yaml を隠蔽していこうという流れになっていたりもします。

今回を機に今後も SEROKU と共にインフラ環境の整備を進化させ続けようと思います。

関連記事

No related photos.