kubernetesをココナラで本番運用出来るか試行錯誤している話
こんにちは!
株式会社ココナラのインフラ・SREチーム所属のおさだと申します。
本記事では、コンテナオーケストレーションのデファクトスタンダードであるkubernetesに対する弊社の取り組みについて紹介いたします。
ココナラのサービス開発の課題
こちらの記事でも述べている通り、弊社サービス開発には以下の課題があります。
- 現状アプリケーション基盤がEC2、ECS+EC2、ECS+Fargateに分散しており、運用管理コストや拡張性に課題がある
- 新規機能毎にインフラを構築する工数を確保出来ずに、既存アプリケーションの肥大化が進んでいる
- 既存アプリケーションに実装することにより、新規機能に適した言語を選択する幅が狭まっている
kubernetesが上記課題の解決手段になりうるか、導入検討を進めております。
kubernetes導入検討でやったこと
直近では以下の対応を実施しており、それぞれ内容について触れたいと思います。
- kubernetesプロトタイプ環境の構築
- EKS VS ECS
- kubernetesへの懸念を払拭させる段取りの検討
- 開発環境管理画面のkubernetes化
kubernetesプロトタイプ環境の構築
まず初めに、弊社サービスを実際にkubernetesに載せて検証できる環境を構築するため、プロトタイプ環境の構築を行いました。
構成としては、以下の通りとなります。
デプロイはArgoCDを利用したGitOps、モニタリングはAmazon Managed Service for Prometheusを利用しています。
プロトタイプ環境は弊社のプリンシパルエンジニアが設計・構築しているため、詳細構成は別途記事にしていただくこととして、本記事では簡易的な紹介に留めます。
EKS VS ECS
kubernetesが他と比べて、弊社に適しているのか28個の観点で比較をしました。
弊社基盤はAWSが主体なため、EKSとECSを比較対象としました。
今回特に重視した観点の比較結果としては、以下の通りとなります。
結論から申し上げると、ECSと比較してEKSが確実に優位性があるという判断にはなりませんでした。
kubernetesを利用する上での以下のデメリットが他のメリットを上回るか、机上では結論は出ませんでした。
- 運用・保守工数の増加
- 他の基盤と並行で利用している間は、単純に運用・保守対象が純増するため、運用・保守工数が増加する
- kubernetesのライフサイクルは短く、最長でも1年程度でクラスタのアップデートが必要
- 学習コストの高さ
- 本格導入する場合、一部メンバーのみではなく開発者全員がある程度kubernetesの基礎知識がないと運用が回らなくなる可能性がある
しかし、kubernetesの以下のような部分は開発者にとって魅力的であり、上で挙げたデメリットへの懸念を払拭出来ないか、考えることにしました。
- 豊富なアドオンによる高い拡張性
- OSS且つデファクトスタンダードであるがゆえの進化の速さ
kubernetesへの懸念を払拭させる段取りの検討
kubernetesを本番導入することによって、運用・保守工数にどれだけの影響があるかが最大の懸念でした。
kubernetesを本番運用されている他社様のお話を聞くと、kubernetesの運用保守に1〜2名程度が張り付きで担当されているようでした。
弊社インフラ・SREチームは個人でそれぞれ20%前後の係数でリアクティブタスク・プロジェクト対応・施策をバランスよく担当する割り振りになっています。
そのため、kubernetesの運用保守に張り付きで担当するのはタスクの割り振り上も工数上も難しく、他社様と異なる体制を敷いて運用が回るか、事前にフィジビリティを取る必要があります。
フィジビリティは、以下のような流れで取ろうとしています。
- kubernetesプロトタイプ環境をしばらく運用して、本番運用で課題になりそうな点を洗い出す
- サービス影響のないアプリケーションを既存基盤とkubernetes基盤で並行運用させ、クリティカルな課題を洗い出す
- 弊社でのkubernetes運用が難しいと判断した場合は、いつでも既存環境に戻せるようにする
- 1.2.にてkubernetesの本番運用のフィジビリティが取れた場合、他のアプリケーションを順次kubernetes基盤に移行
現状は1.を優先して対応しつつ、2.をスキマ時間で進めています。
開発環境管理画面のkubernetes化
「2. サービス影響のないアプリケーションを既存基盤とkubernetes基盤で並行運用させ、クリティカルな課題を洗い出す」の対応のために、手始めに社内で利用している管理画面をkubernetesプロトタイプ環境で動かしました。
ここでは一部のコードをご紹介します。
秘匿情報はAWSのSecretsManagerに格納して、単一コンテナで稼働させるシンプルな構成になっています。
gitops/backend/apps/coconala-admin/base/kustomization.yaml
resources:
- external-secret.yaml
- deployment.yaml
- gateway.yaml
- virtual-service.yaml
- services.yaml
gitops/backend/apps/coconala-admin/base/external-secret.yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: admin-secret
namespace: backend
annotations:
argocd.argoproj.io/sync-wave: "-1"
spec:
secretStoreRef:
name: secret-store
kind: SecretStore
refreshInterval: "0"
target:
name: admin-secret
creationPolicy: Owner
deletionPolicy: Delete
template:
data:
admin-master-key: "{{ .adminMasterKey }}"
data:
- secretKey: XXX
remoteRef:
property: XXX
key: XXX
gitops/backend/apps/coconala-admin/base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: coconala-admin
namespace: backend
spec:
replicas: 1
selector:
matchLabels:
app: coconala-admin
template:
metadata:
labels:
app: coconala-admin
spec:
containers:
- name: coconala-admin
image: XXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/XXXXXXXXX:XXXXXXXXX
command: ["bash", "-c"]
args:
- |
echo $(MASTER_KEY) > config/master.key
echo "RAILS_ENV=development" >> .env
chmod 755 /admin/scripts/docker-entrypoint.sh
/admin/scripts/docker-entrypoint.sh
env:
- name: RAILS_ENV
value: development
- name: MASTER_KEY
valueFrom:
secretKeyRef:
name: "XXX"
key: "XXX"
ports:
- name: http
containerPort: 3000
protocol: TCP
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: coconala-admin
namespace: backend
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- XXX.com
gitops/backend/apps/coconala-admin/base/virtual-service.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: coconala-admin
namespace: backend
spec:
gateways:
- coconala-admin
hosts:
- XXX.com
http:
- name: primary
route:
- destination:
host: coconala-admin-stable
port:
number: 3000
weight: 100
headers:
request:
set:
x-forwarded-proto: https
x-forwarded-port: "443"
- destination:
host: coconala-admin-canary
port:
number: 3000
weight: 0
headers:
request:
set:
x-forwarded-proto: https
x-forwarded-port: "443"
gitops/backend/apps/coconala-admin/base/services.yaml
apiVersion: v1
kind: Service
metadata:
name: coconala-admin-canary
namespace: backend
spec:
ports:
- name: http
protocol: TCP
port: 3000
targetPort: http
selector:
app: coconala-admin
---
apiVersion: v1
kind: Service
metadata:
name: coconala-admin-stable
spec:
ports:
- name: http
protocol: TCP
port: 3000
targetPort: http
selector:
app: coconala-admin
とりあえず動かすというところまでは時間をかけずに出来ましたが、開発者が開発環境として使ったり、本番運用するにはまだまだ足りないことだらけですので、優先順位をつけてスキマ時間でコツコツ進めていきたいと思います。
今後やっていくこと
kubernetesプロトタイプ環境のクラスタバージョンが1.23となり、2023年10月までの更新が必要になります。
kubernetes保守のメインタスクになるであろうクラスタアップデートをして、必要となる工数感を掴んでいきたいと思います。
最後に
本記事では弊社のkubernetesへの直近の取り組みについて、紹介させていただきました。
今後も不定期ではありますが、状況にアップデートがあったタイミングで本ブログで紹介させていただきます。
ココナラでは一緒に働く方を募集しています。
幅広く募集していますので、ご興味ある方はぜひご応募ください!
ブログの内容への感想、カジュアルにココナラの技術組織の話をしてみたい方はこちら
https://open.talentio.com/r/1/c/coconala/pages/70417
※ブログ閲覧者の方限定のカジュアル面談の応募フォームとなります!
エンジニアの募集職種一覧はこちら
https://coconala.co.jp/recruit/engineer
Discussion