Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

お小遣いでKubernetesクラスタ

1.883 Aufrufe

Veröffentlicht am

第16回まどべんよっかいちでの発表資料です。

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

お小遣いでKubernetesクラスタ

  1. 1. お小遣いで Kubernetesクラスタ @第16回まどべんよっかいち 2018/10/13 のぶクマ(@kumar0001)
  2. 2. アジェンダ 個人で費用を抑えてKubernetesクラ スタを運用するために調査・検討・ 試行してみたことを紹介 • Kubernetesクラスタの構成と費用 ➢Azure Kubernetes Service(AKS) ➢ConoHa VPSでの構築 ➢Google Kubernetes Engine(GKE)
  3. 3. はじめに
  4. 4. 事の発端 次リリースの新機能として、 駅コードの報告、オンライン 更新機能に着手 駅のコード(サイバネコード)は 非公開情報のため、有志での収 集が必要 アプリからの報告機能と、オン ラインでの駅コード情報の更新 機能を追加して対応 駅コードを管理するAPIが必要に Kumalica v0.4.1を2016年4月に公開
  5. 5. API基盤の条件 Dockerコンテナベースであること • これまでDockerコンテナを利用してきたことを踏襲 サーバ費用を抑えられること • 個人が非営利で運用するため、サーバの利用にあまり費用をかけら れない(マネタイズが確立するまでの持ち出しを抑える) • 予算は 耐障害性があること • フリーソフトとは言え、障害が発生してサービスが中断しないようにした い。これまでの環境ではこれが実現できない モバイルアプリから駅コードの報告/駅コードの更新取得を 受けるAPIをどこで稼働させるか?
  6. 6. Dockerコンテナを 使う理由 開発環境と運用環境の統一 • 開発環境から運用環境までDockerコンテナのデプロイで統一され るため、開発から運用までのギャップがない 移植性 • Webサーバなどミドルウェアを含んだ環境をコンテナイメージ化 するので、異なる運用環境に移植しやすい • ミドルウェアのバージョンなど稼働環境をコンテナに閉じ込めら れる サーバではなくサービスに注力したい • 開発ではコンテナ作成までを考えればよく、自動化もしやすい • 運用もコンテナをどうデプロイするかに注力できる
  7. 7. Dockerコンテナ基盤 の候補 Dockerコンテナを稼働させるサーバ/サービスの候補で、 費用を抑えられる構成を検討する Kubernetes • Dockerコンテナの運用・管理基盤のデファクトスタンダード • マネージドサービスにもオンプレミスでの構築にも対応 • 障害発生時の自動復旧にすぐれている Azure Web App for Containers • 単一のDockerコンテナイメージを稼働できる。昨年秋にGA • 複数コンテナのデプロイはプレビュー中 • Basicプラン以上が対応(B1:1コア/1.75GBで¥7,235.76/月) Docker Swarm mode • 今となっては…
  8. 8. Kubernetesとは
  9. 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)
  10. 10. Kubernetesの システム構成 https://commons.wikimedia.org/wiki/File:Kubernetes.png (CC BY-SA 4.0) コンテナを管理するMasterと、コンテナがデプロイされ るNodeから構成される
  11. 11. Kubernetesでの サービスの公開 Service • クラスタ内外からPodへのアクセスを提供する。L4レベルでの 負荷分散 • NodePort • Load Balancer: クラウドのL4ロードバランサーのみ対応 Ingress • クラスタ外部からのPodへのアクセスを提供する。 • URLからサービスに振り分けられるL7レベルでの負荷分散 ✓外部型: GKEなどクラウドのみ対応 ✓内部型: nginx-ingress, traefixなど
  12. 12. Kubernetesでの サービスの公開 NortPort node node node NodePort 30123 各Nodeに共通したポート番号がサービスごとに割り当て られる ・通常は30000~32767の範囲 ・外部からのアクセスが可能(実際にはロードバラン サーを経由してNodeにアクセスさせる) ・Podへのアクセスは負荷分散される NodePort 30123 NodePort 30123 pod pod pod
  13. 13. Kubernetesでの サービスの公開 Load Balancer node node node ロードバランサーが作成されて、外部からアクセス可能 な仮想IPアドレスを割り当てる。 ロードバランサーへのアクセスは、各ノードに分散され て、そこからPodにさらに負荷分散される。 ・ AKS,GKEなどクラウドでしか提供されていない ・L4なので、URLでの振り分けに対応しない pod pod pod Load Balancer 100.x.y.z:80
  14. 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. 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. 16. Kubernetesの実 行環境 オンプレミス・VPS・クラウドIaaS • kubeadmなどのツールを用いて、物理サーバ/仮想サーバにクラス タを構築する マネージドサービス • クラウドのサービスとして利用する • masterやnodeを構築する必要がない ローカル環境 • minikubeなどのツールでPCなどのローカル環境に構築する • 通常はnodeが1つだけの環境となり、あくまで開発用
  17. 17. 費用を抑えるた めの方針 ノード数 • masterを構築する場合、シングルノードとする • nodeは2ないし3ノードとする(3ノード以上が望ましいが) ロードバランサー • マネージドサービスもVPSも1台あたりの課金のため、ロード バランサーの台数を減らす ➢Load Balancer型のServiceは利用しない ➢内部型のIngressを設置して、Ingress Controller Podへの負 荷分散にロードバランサーを用いる インスタンスサイズ • APIはこれから開発するため負荷試験ができない。このため、 最低限のCPU/RAMを用いる(1CPU/1GBメモリ以上)
  18. 18. Azure Kubernetes Service(AKS) 方法その1
  19. 19. AKSでの費用 ・ノードに使用できるVMのメモリは基本的に4GB以上 ・利用できるインスタンスでは、B2sの約3,916円/月が最 安で、3ノード以上が推奨のため、11,748円/月から利用 できる ・ロードバランサーはStandardタイプだと2,038円/月 結論: AKSでの運用費用は1.4万円/月から
  20. 20. ConoHaでのKubernete クラスタ構築 方法その2
  21. 21. ConoHaって? GMOによるVPSサービスで、OpenStackで構築されている ・応援団長(マスコットキャラ)美雲このは
  22. 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
  23. 23. 費用について 2018年9月の利用明細(1日あたり164円くらい) ⇒1か月あたり5,000円前後で2ノードのk8sクラスタを運用 できる (4GBメモリ×3node+2GB×1masterだと12,000円前後)
  24. 24. 構築の問題点 ■クラスタの構築に50時間ほどかかった ◎事前学習 ・公式ドキュメントを通勤途中に閲覧して、方法を調査 ⇒ 1日1.0時間×20日間 ≒20時間 ◎構築作業 ・作成したサーバでドキュメントに従ってクラスタを構築 ・動作しない原因の調査は、通勤途中にWeb検索や公式ド キュメントの読み込みで対応 ⇒1日2.5時間×8日間(構築)+1日1.0時間×10日間(調査) ≒30時間 ■問題点 ・Kubernetesクラスタを利用すること自体が初めてで、構築 でのトラブルが、操作の不備によるものかわからず、対応に 時間がかかった。 (ローカル環境では出ない問題もあった) ・k8sやTraefikの進化が激しく、調査で見つけた資料が古く なっていることもあった。 ⇒最初はマネージドサービスを利用してk8sになれるべき? (いったん構築できればよいが…)
  25. 25. メモリの利用状況
  26. 26. GKE Google Kubernetes Engine 方法その3
  27. 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
  28. 28. preemptive インスタンス GCPのPreemptibleインスタンスは、以下の制限があるが、 非常に安価である。 ■制限 ・GCPがいつでも終了させることができる ・24時間実行すると、必ず終了させられる ・常に利用できるわけではない →非プリエンプティブなノードが1個は必要 ■費用 n1-standard-1(1CPU/3.75GBメモリ) 東京リージョン ・31.17米ドル/1か月 プリエンプティブだと ・9.67米ドル/1か月 →非プリエンプティブなノード1台に、負荷に応じてプリエ ンプティブなノードを追加することで安価に運用できる (終了時はk8sによって自動復旧)
  29. 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. 30. まとめ
  31. 31. まとめ VMへのクラスタ構築で安価に運用できるが… • 小さいインスタンスを使えば費用を月5-6,000円に抑えられるが、すで にメモリが73%利用されていて、Webアプリ/APIの利用が進むと不足 する可能性がある • マネージドサービスと同程度のインスタンスサイズだとあまり費用が 変わらないので、保守・運用のコストを考えるとマネージドサービス に移行したほうがよさそう やはりマネージドサービスで? • GKEのプリエンプティブなノードを活用すると、運用費用を月1万円以 内に抑えらえるが、障害と同じ事象への考慮が必要 • 非プリエンプティブなノードだけの場合、月1.4万円が最低ライン (ノード数を2個にすれば月1.0万円程度に)

×