Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DockerCompose to k8s

Avatar for matsuo matsuo
September 24, 2019

DockerCompose to k8s

Avatar for matsuo

matsuo

September 24, 2019
Tweet

More Decks by matsuo

Other Decks in Technology

Transcript

  1. 自己紹介 1 名前 : 松尾 所属 : 株式会社オージス総研 仕事 :

    インフラエンジニア 趣味 : ラーメン作り = + (CKA勉強中)
  2. 今回お話する内容 3  前提 • 動かそうとしたアプリはWeb/AP/DB/KVSで構成 • コンテナ化され、Docker-composeで動作確認済み  お話する内容

    • どのようにアプリを定義するか • どこで動かすか • 実際に動かす • DBをどのように選定するか  お話しない内容 • コンテナ化 • CI/CD • 監視 • ストレージ、KVSなど
  3. なぜKubernetesを選んだか 4  課題があった • パフォーマンスや可用性の要件が厳しいアプ リがあり、Docker-composeで動かしていたが オーケストレーションに難があった  Kubernetesなら解決できる可能性

    • 優れたコンテナオーケストレーションツール であり、スケーリング機能もある  Kubernetesに取り組んでおきたい • コンテナオーケストレーションツールのデフ ァクトスタンダードであるKubernetesの知見 もキャッチアップしておきたい
  4. 移行するにあたり何を考慮したか 6 Cloud Native Landscape • このランドスケープは、クラウドネイティブ テクノロジーのこれまでにない地形を通る地 図として意図されています •

    クラウドネイティブアプリケーションをデプ ロイするには多くのルートがあり、CNCFプ ロジェクトは特によく行き届いたパスを表し ます 何から構成要素を選べ ば良いか? 引用 https://landscape.cncf.io/
  5. 8 引用 https://github.com/cncf/trailmap • どのようにアプリを定義するか • どこで動かすか • 実際に動かす •

    DBをどのように選定するか • アプリ定義をする(Helm等) • どこで動かすか決める
  6. アプリ定義 - Docker-composeとは 10 • 簡易的なDockerオーケストレーシ ョンツール • 出来ない •

    コンテナの水平方向のスケーリング • コンテナの死活監視、障害時の自動復 旧(コントローラ) ⇒アプリケーション担当で試作した Docker-composeファイルがあるの で、それらからKubernetes構成設定 (Manifest)を作っていく Docker-composeファイル version: '3' services: DB: image: sample-DB:1.0 environment: DB_USER: xxxx DB_PASS: xxxx KVS: image: sample-KVS:1.0 command: redis --xxxx container_name: KVS WEB: image: sample-WEB:1.0 depends_on: - DB ports: - "3000:3000" command: httpd -xxxx AP: image: sample-AP:1.0 depends_on: - DB links: - DB command: appd -xxxx ports: - "2000:2000"
  7. アプリ定義 - Manifest作成 12 • しかし、Docker-composeを読み解いて一から Manifestファイルを起こすのは初心者には難し い(ましてやHelm Chartも難しい) •

    簡単に出来るツールが無いか調べた • Docker-composeファイルからManifestファイ ルを変換できる、Kubernetes公式プロジェクト ツール(Kompose)を使用してみることに
  8. アプリ定義 - Manifest作成 13 • Kompose結果  何が出来た?  Docker-composeに記載されているservices単位

    で、ServiceやDeploymentの変換・作成が自動 で行われた。  Serviceに関連するLabels、Selectorなどの自動 生成。  何が出来なかった?  Docker-compose側にportsやlinksの記載がない 場合はServiceが作られない。  環境変数(environment)はそのままEnvへ(秘匿 情報は必要に応じてSecretにする) KD250-M06 KubernetesOverview P40→deployment P53→service
  9. Namespace:default AP AP DESIRED:1 アプリ定義 - Komposeを元に起こした構成図 14 AP #1

    KVS KVS DESIRED:1 KVS #1 DB DB DESIRED:1 DB #1 Web Web DESIRED:1 Web #1
  10. 15 引用 https://github.com/cncf/trailmap • どのようにアプリを定義するか • どこで動かすか • 実際に動かす •

    DBをどのように選定するか  アプリ定義をする • どこで動かすか決める
  11. どこで動かすか - EKSとは 17  AWSのマネージドKubernetesサービス  コントロールプレーンの管理が不要  ワーカーノードをスケール可能

    引用 https://eksworkshop.com/introduction/eks/eks_high_architecture/ KD250-M10-Kubernetes Architecture P5→Worker Nodes P6→Control Plane
  12. どこで動かすか - EKSクラスタ作成 18 • eksctlを使用  eksctlのインストール  権限設定

     eksctl create cluster ¥ --name test-cluster ¥ --version 1.12 ¥ --nodegroup-name test-workers ¥ --node-type t3.medium ¥ --nodes 3 ¥ --nodes-min 1 ¥ --nodes-max 4 ¥ --node-ami auto ※当時のEKS最新クラスタVerを使用
  13. 20 • どのようにアプリを定義するか • どこで動かすか • 実際に動かす • DBをどのように選定するか 引用

    https://github.com/cncf/trailmap  アプリ定義をする  どこで動かすか決める
  14. 実際に動かす - ステータスを確認する 24  kubectl get all NAME READY

    STATUS RESTARTS AGE pod/Web 1/1 Running 0 20h pod/AP 1/1 Running 0 20h pod/KVS 1/1 Running 0 20h pod/DB 1/1 Running 0 20h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/Web ClusterIP 10.100.3.5 <none> 80/TCP 3d service/AP ClusterIP 10.100.149.242 <none> 1883:31721/TCP 45d service/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 45d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/Web 1/1 1 1 17d deployment.apps/AP 1/1 1 1 17d deployment.apps/KVS 1/1 1 1 17d deployment.apps/DB 1/1 1 1 17d NAME DESIRED CURRENT READY AGE replicaset.apps/Web 1/1 1 1 17d replicaset.apps/AP 1/1 1 1 17d replicaset.apps/KVS 1/1 1 1 17d replicaset.apps/DB 1/1 1 1 17d KD250-M06 Kubernetes Overview P34→ReplicaSet
  15. 実際に動かす - アプリケーション動作確認 25 • アプリケーションの動作確認を行う • 事前にAPにログインし、AP上からテスト用の設 定をDBに登録する 

    Kubectl exec –it -- bash AP  ./add-command -D DB 2019-07-16T10:34:04.412456+0000 [fatal][AP]():caught exception: Unknown MySQL server host 'DB' (0) ⇒ DBに接続できない(調査するとKVSも同様)
  16. Namespace:default AP AP DESIRED:1 実際に動かす - アプリケーション動作確認 26 AP #1

    KVS KVS DESIRED:1 KVS #1 DB DB DESIRED:1 DB #1 Web Web DESIRED:1 Web #1 正常起動 正常起動 正常起動 正常起動 原因は? 接続不可 接続不可
  17. Namespace:default AP AP DESIRED:1 実際に動かす - アプリケーション動作確認 27 AP #1

    KVS KVS DESIRED:1 KVS #1 DB DB DESIRED:1 DB #1 Web Web DESIRED:1 Web #1 Pod間のホスト名での通信には、Serviceが必要 ※IP直指定でも通信は可能
  18. (参考)Serviceとは 28  一連のPod 上で実行されているアプリケーションをネットワークサービスと して公開するための抽象的な方法。  なじみのないサービス検出メカニズムを使用するようにアプリケーションを 変更する必要はありません。Kubernetesは、ポッドに独自のIPアドレスと ポッドのセットに対する単一のDNS名を付与し、それらの間でロードバラン

    スをとることができます。 • An abstract way to expose an application running on a set of Pods as a network service. • No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives pods their own IP addresses and a single DNS name for a set of pods, and can load-balance across them. 引用 https://v1-14.docs.kubernetes.io/docs/concepts/services-networking/service/
  19. (参考)Serviceの種類 29  ClusterIP • デフォルトで作成されるサービス • Pod同士からアクセス出来る • クラスタ外部からのアクセスは出来ない

     Nodeport • クラスタ外からアクセス出来る • ClusterIPの機能を包含  LoadBalancer • クラウドプロバイダ側提供のLBと連携するためのもの • NodePortの機能を包含  ExternalName • クラスタ内から外部ホストを解決するためのエイリアスを提供 • RDS等と連携する時に必要 今回はClusterIP を作成 KD250-M06 Kubernetes Overview P53→Service
  20. Namespace:default AP AP DESIRED:1 実際に動かす - アプリケーション動作確認 30 AP #1

    KVS KVS DESIRED:1 KVS #1 DB DB DESIRED:1 DB #1 Web Web DESIRED:1 Web #1 • 動作確認する Request OK
  21. まとめ – アプリ定義から実際に動かすところまで 31  Docker-composeからの移行の 場合は、Komposeを適宜使い移 行を楽にする。  作られたmanifestは要確認

    (service大事)。  PodのstatusがRUNNINGとなっ ている事だけでなくアプリケー ションの動作確認まで行う。(※ )  この状態だとDBやKVSがシング ル構成なので、クラスタ構成を 組んでおきたい  (EKSの場合は)eksctlとkubectl などのCLIツールを適宜使う。 引用 https://github.com/cncf/trailmap • アプリ定義をする • どこで動かすか決める ※ KD250-M09-Kubernetes Best Practices P39→ReadinessProbe/LivenessProbe https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-tcp-liveness-probe https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes
  22. 32 • どのようにアプリを定義するか • どこで動かすか • 実際に動かす • DBをどのように選定するか 引用

    https://github.com/cncf/trailmap  MySQL DBの信頼性やスケーラビリティをより 求めるならVitessがお勧め
  23. DB選定 – 候補について  MySQL • 純粋なMySQLエンジンを使用 • 今回はOperatorでのクラスタ構築運用を検討 

    MariaDB • MySQL完全互換ではないが、サンプルアプリがMariaDBで開発さ れているため選択肢になる • GaleraClusterを用いたマルチマスタのクラスタ構成がある  Vitess • クラウドネイティブなOSS • Youtube用に開発され、スケーリングやパフォーマンスに優れて いる • MySQLに一部互換性がある  RDS • AWSのマネージドRDBサービス • MySQLエンジンのインスタンス提供有り 35
  24. (参考) Operatorとは? 引用 https://coreos.com/blog/introducing-operators.html  Kubernetesは自動化のために設計されています。すぐに使用できるよう にKubernetesのコアから多くの組み込みの自動化機能を利用できます。 あなたはワークロードを展開し実行を自動化するためにKubernetesを使 用することができ、そしてKubernetesはそれを自動化することができま す。

     Kubernetesのコントローラーコンセプトにより、Kubernetes自体のコー ドを変更せずにクラスターの動作を拡張できます。オペレーターは、カス タムリソースのコントローラーとして機能するKubernetes APIのクライ アントです。 36 引用 https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
  25. (参考) Operatorがなぜ必要なのか? 例: MySQLのMaster-Slave構成をmanifestで組む • MySQLを定義 • ConfigMap • Secret

    • Statefulset • Service • データ格納用に内部ストレージ割当 • PersistentVolume • 各種設定 • ConfigMap • データ同期設定 • Pod再作成時の復帰処理を作りこみ • バックアップスケジュール Manifest 数百行 例: Master-Slave構成をOperatorで組む • MysqlClusterを定義 Manifest 数行 38
  26. (参考) Operatorは、Helmとどう違う? • Helm • Manifestの塊をパッケー ジ(chart)化してインスト ール、削除などできるも の •

    オブジェクトを監視、管 理する機能は無い • Operator • カスタムリソースの manifestに沿ってK8sの APIにアクセスしてオブ ジェクトの状態を監視、 管理する 引用 https://helm.sh/ 引用 https://blogs.oracle.com/developers/introducing-the-oracle-mysql-operator-for-kubernetes 39
  27. DB選定 – 机上比較 候補 \ 比較項目 Mysql シングル 構成 Mysql-

    Operator MariaDB Galera Cluster Vitess RDS (MySQL) MySQL 互換性 ◎ 同等 ◎ 同等 ◦ 完全互換ではない がアプリ開発は MariaDBなので 問題なし △ 一部SQL未サポート ◎ 同等 対応言語 ◦ 多数 (C++有り) ◦ 多数 (C++有り) ◦ 多数 (C++有り) ◦ 多数 (C++有り) ◦ 多数 (C++有り) サポート △ OSS △ OSS △ OSS △ OSS ◦ マネージド リソース 拡張性 △ 手動で スケーリング △ 手動で スケーリング △ 手動で スケーリング ◎ LiveReSharding ◦ リードレプリカ可 スケールアップ可 耐障害性 △ Podオート ヒーリングのみ ◦ Failover可 ◦ Failover可 ◦ Failover可 ◦ Failover可 ※これは製品や構成の優劣比較を行ったものではなく、あく までサンプルアプリを動かすために、どのような構成が取れ 得るか判断するために、独自に整理したもの 40
  28. DB選定 – 検証方針 41  まず下記の簡易的な検証を行い比較を行った  ManifestやOperator等で問題なく構築できるか  DB初期化用のSQLが発行できるか

     アプリの動作確認は問題ないか  Podを無作為に削除  自動復旧するか  データは欠損していないか  ダウンタイムはどの程度か
  29. DB選定 – MySQLシングル構成検証内容 42 ns:MySQL Kubernetesクラスタ Service ns:AP AP DBアクセス

    MySQL  ManifestやOperator等で問題なく構築で きるか(OK)  DB初期化用のSQLが発行できるか(OK)  アプリの動作確認は問題ないか(OK)  MySQLのPodを無作為に削除(NG)  ダウンタイムが発生
  30. DB選定 – MySQL Operator検証内容 43 ns:MySQL Kubernetesクラスタ Master Service MySQLクラスタ

    状態監視・管理 ns:AP AP DBアクセス MySQLクラスタ Master Slave Slave Operator、 Orchestrator  ManifestやOperator等で問題なく構築で きるか(OK)  DB初期化用のSQLが発行できるか(OK)  アプリの動作確認は問題ないか(OK)  MySQLのPodを無作為に削除(NG)  Masterのpodを削除したところ7 秒程度でFailOver完了。  新PodのステータスはRunningと なっているがMasterServiceにリ クエストするとDBに繋がらず。  Orchestratorのログを見ると、 sys_operator.heartbeatテーブ ルが無いとのエラー有り。初期処理 に問題がある可能性有り。  その他の問題  環境をクリアにするため、helm delete –purge、およびEBS削除 を行った後に再度helm installし ようとしたところ、削除済みのEBS を見に行ってしまいinstallが失敗 する。削除も新規作成も出来ない状 態。  helm init等行っても同様。  pvcを作り直して解決。
  31. DB選定 - MariaDB Galera Cluster検証内容 44 ns:MySQL Kubernetesクラスタ Service ns:AP

    AP DBアクセス MySQLマルチマスタ Master1 Master2 Master3  ManifestやOperator等で問題 なく構築できるか(OK)  DB初期化用のSQLが発行でき るか(OK)  アプリの動作確認は問題ないか (OK)  Podを無作為に削除(OK)  自動復旧するか(OK)  データは欠損していないか (OK)  ダウンタイムはどの程度か (podは10秒程度で再作成 されるがデータ同期が完了 するまではクラスタに参加 しない)  データが永続化されていないの で定期バックアップ取得等の対 策が必要。 負荷分散 • PVは無し • 障害時は他podから 全データをコピー
  32. DB選定 - Vitess検証内容 45 Kubernetesクラスタ MySQLクラスタ 状態監視・管理 ns:AP AP DBアクセス

    MySQLクラスタ Master Slave Slave Operator、 Orchestrator  ManifestやOperator等で問題 なく構築できるか(OK)  DB初期化用のSQLが発行でき るか(NG)  初期化用のSQLの半分が実 行エラー。  アプリの動作確認は問題ないか (NG)  アプリ起動せず  rpc error: code = FailedPrecondition desc = SELECT_LOCK disallowed outside transaction (CallerID: xxxx) while executing "select xxxx from yyyy lock in share mode” ns:Vitess ns:Vitess
  33. DB選定 – RDS検証内容 46 ns:MySQL Kubernetesクラスタ ns:AP AP DBアクセス 

    問題なく構築できるか(OK)  DB初期化用のSQLが発行でき るか(OK)  アプリの動作確認は問題ないか (OK)  RDSのMasterNode再起動(OK)  自動復旧するか(OK)  データは欠損していないか (OK)  ダウンタイムはどの程度か (30秒程度) RDS ExternalName Service AWS Cloud
  34. DB選定 – 比較結果 候補 \ 比較項目 Mysql シングル 構成 Mysql-

    Operator MariaDB Galera Cluster Vitess RDS (MySQL) MySQL 互換性 ◎ 同等 ◎ 同等 ◦ 完全互換ではないが アプリ開発は MariaDBなので問題 なし △ 一部SQL未サポート ◎ 同等 対応言語 ◦ 多数 (C++有り) ◦ 多数 (C++有り) ◦ 多数 (C++有り) ◦ 多数 (C++有り) ◦ 多数 (C++有り) サポート △ OSS △ OSS △ OSS △ OSS ◦ マネージド リソース 拡張性 △ 手動で スケーリング △ 手動で スケーリング △ 手動で スケーリング ◎ LiveReSharding ◦ リードレプリカ可 スケールアップ可 耐障害性 △ Podオート ヒーリングのみ ◦ Failover可 ◦ Failover可 ◦ Failover可 ◦ Failover可 サンプル アプリ 検証状況 ◦ • 動作確認OK • ダウンタイム約 10秒発生 × • 動作確認OK • Failover後のpod に欠損テーブル 有り ◦ • 動作確認OK • Failover約10秒 • データ未永続化 × • AP起動せず • DB初期化用SQLスク リプトも一部しか実 行できず ◦ • 動作確認OK • Failover約30秒 ※これは製品や構成の優劣比較を行ったものではなく、 あくまでサンプルアプリを動かすために、どのような構 成が取れ得るか判断するために、独自に整理したもの 47
  35. まとめ – DBをどのように選定するか 48 • 今回のサンプルアプリで言えば、 現状はMySQLのシングル構成か 、MariaDB Galera Cluster、

    RDSのいずれかが選択肢となる。 • MariaDB Galera Cluster構成 は、現状データを永続化でき ていない(課題) • 永続化もしくは定期バックア ップ取得などの対策が必要 • 今後はVitessを試行することも検 討していきたい。 • K8s上できちんとMySQLのクラス タ構成を組める選択肢は、今後も 情報収集していきたい。 引用 https://github.com/cncf/trailmap