Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a お小遣いでKubernetesクラスタ
Semelhante a お小遣いでKubernetesクラスタ (20)
Mais de Nobuaki Aoki
Mais de Nobuaki Aoki (20)
お小遣いでKubernetesクラスタ
- 2. アジェンダ 個人で費用を抑えてKubernetesクラ スタを運用するために調査・検討・ 試行してみたことを紹介 • Kubernetesクラスタの構成と費用 ➢Azure Kubernetes Service（AKS） ➢ConoHa VPSでの構築 ➢Google Kubernetes Engine（GKE）
- 3. はじめに
- 5. API基盤の条件 Dockerコンテナベースであること • これまでDockerコンテナを利用してきたことを踏襲 サーバ費用を抑えられること • 個人が非営利で運用するため、サーバの利用にあまり費用をかけら れない（マネタイズが確立するまでの持ち出しを抑える） • 予算は 耐障害性があること • フリーソフトとは言え、障害が発生してサービスが中断しないようにした い。これまでの環境ではこれが実現できない モバイルアプリから駅コードの報告／駅コードの更新取得を 受けるAPIをどこで稼働させるか？
- 6. Dockerコンテナを 使う理由 開発環境と運用環境の統一 • 開発環境から運用環境までDockerコンテナのデプロイで統一され るため、開発から運用までのギャップがない 移植性 • Webサーバなどミドルウェアを含んだ環境をコンテナイメージ化 するので、異なる運用環境に移植しやすい • ミドルウェアのバージョンなど稼働環境をコンテナに閉じ込めら れる サーバではなくサービスに注力したい • 開発ではコンテナ作成までを考えればよく、自動化もしやすい • 運用もコンテナをどうデプロイするかに注力できる
- 7. Dockerコンテナ基盤 の候補 Dockerコンテナを稼働させるサーバ／サービスの候補で、 費用を抑えられる構成を検討する Kubernetes • Dockerコンテナの運用・管理基盤のデファクトスタンダード • マネージドサービスにもオンプレミスでの構築にも対応 • 障害発生時の自動復旧にすぐれている Azure Web App for Containers • 単一のDockerコンテナイメージを稼働できる。昨年秋にGA • 複数コンテナのデプロイはプレビュー中 • Basicプラン以上が対応（B1：1コア/1.75GBで¥7,235.76/月） Docker Swarm mode • 今となっては…
- 8. Kubernetesとは
- 9. Kubernetesとは • クーベネティス / クーベルネイテス • ギリシャ語で航海長またはパイロット • コンテナのデプロイ・管理を行うオーケスト レーションシステム • dockerコンテナだけに限定しない https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82% A4%E3%83%AB:HUMBER_BRIDGE.JPG (CC BY-SA 3.0)
- 11. Kubernetesでの サービスの公開 Service • クラスタ内外からPodへのアクセスを提供する。L4レベルでの 負荷分散 • NodePort • Load Balancer： クラウドのL4ロードバランサーのみ対応 Ingress • クラスタ外部からのPodへのアクセスを提供する。 • URLからサービスに振り分けられるL7レベルでの負荷分散 ✓外部型： GKEなどクラウドのみ対応 ✓内部型： nginx-ingress, traefixなど
- 13. Kubernetesでの サービスの公開 Load Balancer node node node ロードバランサーが作成されて、外部からアクセス可能 な仮想IPアドレスを割り当てる。 ロードバランサーへのアクセスは、各ノードに分散され て、そこからPodにさらに負荷分散される。 ・ AKS,GKEなどクラウドでしか提供されていない ・L4なので、URLでの振り分けに対応しない pod pod pod Load Balancer 100.x.y.z:80
- 14. Kubernetesでの サービスの公開 Ingress (外部型) GKEなどでは、クラウドのL7ロードバランサーが作成され て、URLに対応するサービスへと振り分けられる。 ・サービスはNodePortでアクセスされる node node node pod pod pod Ingress (L7 Load Balancer) /api/stationcode ⇒ StationCodeService /api/cardhistory ⇒ CardHistoryService NodePort 30123 NodePort 30123 NodePort 30123 NodePort 30122 NodePort 30122 NodePort 30122
- 15. Kubernetesでの サービスの公開 Ingress (内部型) Ingressの処理を行うPodをデプロイする。 外部からはL4ロードバランサーを経由して、各Nodeにあ るIngerssコントローラーPodにアクセスされて、URLに対 応するサービスのPodに転送される。 node node node pod pod pod Ingress Controller Pod /api/stationcode ⇒ StationCodeService /api/cardhistory ⇒ CardHistoryService NodePort 30123 NodePort 30123 NodePort 30123 NodePort 30122 NodePort 30122 NodePort 30122 L4 Load Balancer 100.x.y.z:80
- 16. Kubernetesの実 行環境 オンプレミス・VPS・クラウドIaaS • kubeadmなどのツールを用いて、物理サーバ／仮想サーバにクラス タを構築する マネージドサービス • クラウドのサービスとして利用する • masterやnodeを構築する必要がない ローカル環境 • minikubeなどのツールでPCなどのローカル環境に構築する • 通常はnodeが1つだけの環境となり、あくまで開発用
- 17. 費用を抑えるた めの方針 ノード数 • masterを構築する場合、シングルノードとする • nodeは2ないし3ノードとする（3ノード以上が望ましいが） ロードバランサー • マネージドサービスもVPSも1台あたりの課金のため、ロード バランサーの台数を減らす ➢Load Balancer型のServiceは利用しない ➢内部型のIngressを設置して、Ingress Controller Podへの負 荷分散にロードバランサーを用いる インスタンスサイズ • APIはこれから開発するため負荷試験ができない。このため、 最低限のCPU/RAMを用いる（1CPU/1GBメモリ以上）
- 22. 構成 利用者 ConoHa VPS 管理者 master (2GB) node-1 (1GB) node-2 (1GB) ロードバランサー インターネット https://knowledge.sakura.ad.jp/4724/ (CC BY 4.0)インターネット Traefik Ingress Traefik Ingress master/nodeのVMを作成して、ポート開放・Dockerのインス トールなどを行い、k8sクラスタを構成する。 ・masterのサーバも用意する必要がある ・Ingressは内部型しか利用できない（今回はTraefikを利用） ・今回は利用しないがLoad Balancer型のServiceに対応していな い（Sakura VPSのように自分でコードを書けば利用可） pod pod
- 25. メモリの利用状況
- 27. 構成 利用者 GCP 管理者 master node-1 (3.75 GB) ロードバランサー インターネット https://knowledge.sakura.ad.jp/4724/ (CC BY 4.0)インターネット Traefik Ingress Traefik Ingress ・ Ingressは外部型と内部型の両方に対応しているが、外部型は 名前空間ごとに1個作成される（課金up↑）ので、内部型を使う。 ・masterのサーバはGKEが提供、管理するため課金対象外 ・今回は利用しないが、Load Balancer型のServiceに対応する。 pod pod Traefik Ingress pod node-2 (3.75 GB) preemptive node-3 (3.75 GB) preemptive
- 29. 費用について ◎1か月あたりの費用 ・n1-standard-1 × 1台 $31.17 ・ n1-standard-1（プリエンプティブ） × 2台 $19.34 ・L4ロードバランサー $28.27 合計 $ 78.78（約8,744円） ※非プリエンプティブなノードだけだと$121.78/月（約1.4 万円/月）でAKSと同程度になる。 ◎まとめ プリエンプティブなノードの活用で費用を抑えられるが、 ロードバランサーの費用がかさむため、それなりに費用が かかる。 →非プリエンプティブなノードだけでも、VPSで同スペッ クを構築した場合と大きく差があるわけでないので、プリ エンプティブなノードを活用できれば、安価に運用できる のでは？ ◎課題 プリエンプティブなノードでアプリ・APIが終了させられる 場合を考慮する必要がある（障害と同じ対応でよい？）
- 30. まとめ
- 31. まとめ VMへのクラスタ構築で安価に運用できるが… • 小さいインスタンスを使えば費用を月5-6,000円に抑えられるが、すで にメモリが73%利用されていて、Webアプリ／APIの利用が進むと不足 する可能性がある • マネージドサービスと同程度のインスタンスサイズだとあまり費用が 変わらないので、保守・運用のコストを考えるとマネージドサービス に移行したほうがよさそう やはりマネージドサービスで？ • GKEのプリエンプティブなノードを活用すると、運用費用を月1万円以 内に抑えらえるが、障害と同じ事象への考慮が必要 • 非プリエンプティブなノードだけの場合、月1.4万円が最低ライン （ノード数を2個にすれば月1.0万円程度に）