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

Kubernetes入門#1 運用例の紹介 / Kubernetes Getting Started#1 Case Introduction for k8ssa

hi-rose
October 05, 2018

Kubernetes入門#1 運用例の紹介 / Kubernetes Getting Started#1 Case Introduction for k8ssa

hi-rose

October 05, 2018
Tweet

More Decks by hi-rose

Other Decks in Programming

Transcript

  1. Kubernetes Sapporo for Beginners 自己紹介 廣瀬 亮輔(Ryosuke Hirose)/@hi-rose • 最近は家の近くにできたジムに通うのがマイブーム •

    旭川高専卒業後、札幌で今の会社に就職してシステム開発 ◦ 言語はC#、Java、delphiなど ◦ ミドルウェアはSQLServer、Oracle、Apache、Tomcatなど • 2017年4月からアーキテクト部署となりクラウドシステムのバックエンド系基盤機能開発に ◦ Kubernetesもそのころから利用 ▪ 普段GCPで使用しているため、 GCP実装ベースでの理解が中心となります ◦ データマイグレーション系サービスのプロジェクトリーダー
  2. Kubernetes Sapporo for Beginners はじめに ▶対象者  Kubernetesに触れたことの無い方、少しだけ知ってる方 ▶ゴール  Kubernetesを取り入れた開発・運用によりどんなことができるようになるのか  ふんわりわかるようになる

    ▶前提事項・注意事項 • 普段私がKubernetesを取り入れた環境で開発している流れを紹介します • 中規模~大規模レベルの業務アプリケーションでの例となります • 仕組みなど抽象化したり、ふんわりと説明している箇所があります
  3. Kubernetes Sapporo for Beginners Kubernetesはコンテナオーケストレーション。 コンテナ技術を用いてオーケストレーションを実現させるためのもの。 • CI(継続的インテグレーション)と組み合わせることで、開発面の自動化や管理・運用のメリット ◦ 開発者が開発に専念できる

    • 各種自動化とコンテナ化により、 CD(継続的デリバリー)やDevOps運用にもメリット ◦ デプロイ管理機能(ローリングアップデートなど)やスケールアウト機能も提供されます 今回主に伝えたいこと opsさん devさん
  4. Kubernetes Sapporo for Beginners 具体的にどんなことができるの? • Dockerコンテナの実行管理 • コンテナにアクセスするための Load

    balancerの管理 • スケーリング・デプロイ管理 • 障害時の自動復旧 これらの管理をyamlファイルによる定義+コマンドラインベースで行うことが可能 • 既に存在するCI/CDの仕組みやミドルウェアとの親和性が高く、各種自動化が組み込みやすい! • テキストファイルが扱えれば大体扱うことができる!
  5. Kubernetes Sapporo for Beginners Kubernetes周りのアーキテクチャ概略 LB GKE:Javaアプリケーション Kubernetesマニフェストファイル (yaml) ingress

    service statefulsets deployements replicasets アプリケーションが更新され た際には、ここのイメージ定 義を更新 アプリケーションが追加され たらこれらを更新。 ユーザーアクセス 各種データ ストア
  6. Kubernetes Sapporo for Beginners 在庫PJ Opsマシン 全体像 feature ブランチ Gitサーバー

    develop ブランチ release ブランチ Gitlab-runnerマシン (CI/CDツール) GCP master ブランチ App テスト App ビルド Docker ビルド Kubernetes デプロイ App テスト App ビルド Docker ビルド Kubernetes デプロイ Docker タグ Container Registry Google Kubernetes Engine 開発環境クラスタ ステージング環境クラスタ 本番環境クラスタ Kubernetes デプロイ作業 ←-----------------CIパイプライン------------------→ 本番設定反映作 業 設定PJ(※) master ブランチ 設定 反映 ※省略しましたが、環境別にプロジェクトを 分けてロール管理。 在庫 取引 … 在庫 取引 … 在庫 取引 … ①開発完了・テス ト完了時に特定ブ ランチに反映 develop:開発 release:ステージ ング master:本番 ②ブランチに対応したパイ プラインが実行される ③パイプライン内で Dockerイメー ジが作成され、コンテナレジスト リに管理される ④CI内にて環境反映 ⑤反映指示を受けた Kubernetes はコンテナレジストリから Docker イメージを取得して起動 ⑥DB接続先などの 環境別設定類は ConfigMapや Secretという瀬って ファイルをYamlファ イル化したもので管 理し、マージ ⑧本番環境は設定 もアプリケーション デプロイも運用チー ムが実施 ⑦開発系の環境は マージにより設定反 映のパイプラインで Kubernetesに反映 devチーム opsチーム
  7. Kubernetes Sapporo for Beginners 在庫PJ Opsマシン 全体像 feature ブランチ Gitサーバー

    develop ブランチ release ブランチ Gitlab-runnerマシン (CI/CDツール) GCP master ブランチ App テスト App ビルド Docker ビルド Kubernetes デプロイ App テスト App ビルド Docker ビルド Kubernetes デプロイ Docker タグ Container Registry Google Kubernetes Engine 開発環境クラスタ ステージング環境クラスタ 本番環境クラスタ Kubernetes デプロイ作業 ←-----------------CIパイプライン------------------→ 本番設定反映作 業 設定PJ(※) master ブランチ 設定 反映 ※省略しましたが、環境別にプロジェクトを 分けてロール管理。 在庫 取引 … 在庫 取引 … 在庫 取引 … ①開発完了・テス ト完了時に特定ブ ランチに反映 develop:開発 release:ステージ ング master:本番 ②ブランチに対応したパイ プラインが実行される ③パイプライン内で Dockerイメー ジが作成され、コンテナレジスト リに管理される ④CI内にて環境反映 ⑤反映指示を受けた Kubernetes はコンテナレジストリから Docker イメージを取得して起動 ⑥DB接続先などの 環境別設定類は ConfigMapや Secretという瀬って ファイルをYamlファ イル化したもので管 理し、マージ ⑧本番環境は設定 もアプリケーション デプロイも運用チー ムが実施 ⑦開発系の環境は マージにより設定反 映のパイプラインで Kubernetesに反映 このへん devチーム opsチーム
  8. Kubernetes Sapporo for Beginners 成果物リポジトリとCI/CDツール 今回の運用例では、 Gitlab+Gitlab-runnerを紹介しました。 ここはGithub+CircleCIだったり、Jenkinsを組み合わせるな ど何でも大丈夫です。 GitlabのCI/CD機能では

    ソースを格納している PJに.gitlab-ci.ymlファイルを配置して、 CI/CD処理を定義できます。 stages: - java-build - java-deploy - docker-build - docker-deploy before_script: - git clone -b develop $CI_SHELL_URL java-build: stage: java-build tags: - ci-runner script: - ./$CI_SHELL/java/build.sh only: - develop - release ~~略~~
  9. Kubernetes Sapporo for Beginners CI/CDパイプライン 簡単に流れを解説します。 ①stagesにて、パイプラインで実行する要素を定義  java-build … Javaプログラムをテスト&ビルド

     java-deploy … Javaプログラムのパッケージ管理  docker-build … Dockerイメージの構築  docker-deploy … Kubernetesに反映 ②before_scriptでは、スクリプトをとってくる ③とってきたスクリプトを実行 ④develop、releaseブランチへのマージをトリガとする stages: - java-build - java-deploy - docker-build - docker-deploy before_script: - git clone -b develop $CI_SHELL_URL java-build: stage: java-build tags: - ci-runner script: - ./$CI_SHELL/java/build.sh only: - develop - release ~~略~~ ② ① ③ ④
  10. Kubernetes Sapporo for Beginners Dockerイメージの構築 CI/CDによって起動されたdocker-build.sh(右上) ①Javaビルドで作成されたjarのコピー ②docker buildコマンドにより、GCP上のコンテナレジストリ で管理するためのタグをつけて

    Dockerイメージの作成 ③Dockerイメージをコンテナレジストリに push docker build時に実行されるDockerファイル定義(右下) ④ベースイメージとして docker hubのイメージを指定 (ここではalpine linuxにJava8を入れたもの) ⑤jarとDockerコンテナが起動した際に実行する shellの配置 ⑥配置したshellをENTRYPOINTとして定義 【docker-build.sh】 -------------------------- cp -af api-stock.jar docker/ docker build -t asia.gcr.io/gcp_example/api-stock:1.0.0 . gcloud docker -- push asia.gcr.io/gcp_example/api-stock:1.0.0 ① ② ③ 【docker/Dockerfile】 --------------------------- FROM openjdk:8-jdk-alpine ADD api-stock.jar /root/api-stock.jar ADD startup.sh /root/startup.sh ENTRYPOINT ["./root/startup.sh"] ④ ⑤ ⑥
  11. Kubernetes Sapporo for Beginners 余談 Dockerイメージはなるべく小さく作った方が良いです。 Oracle社の勉強会でもAlpine Linuxがおすすめされていました。 ※Alpine Linux(アルパインリナックス)は

    5MB以下の軽量なディストリビューション。  JDKを入れても100MB程度となる。 この勉強会でお話ししていた matsumotoさんが、以下QiitaでOpenJDK11を入れた軽量イメージ作成について 投稿しています(宣伝)。 OpenJDK11のdokcerイメージ(1GB)が大きいのでalpine linux+ jlinkで小さいイメージ(85MB)を作成する https://qiita.com/h-r-k-matsumoto/items/294eeb838cfd062d75b6
  12. Kubernetes Sapporo for Beginners Kubernetesデプロイ 外部へ公開するための service定義のYamlと実行イメージを指定したワークロード( statefulset、deployment、 replicaset)を用意し、 【kubectl

    apply -f ファイル名】と実行することで Kubernetesに反映 【service.yaml】 apiVersion: v1 kind: Service metadata: name: api-stock labels: app: api-stock tire: backend-api spec: type: NodePort ports: - port: 8080 targetPort: 8080 nodePort: 8080 name: api-stock selector: app: api-stock tire: backend-api 【statefulset.yaml 1】 apiVersion: apps/v1 kind: StatefulSet metadata: name: api-stock spec: serviceName: api-stock replicas: 2 updateStrategy: type: RollingUpdate rollingUpdate: selector: matchLabels: app: api-stock tire: backend-api template: metadata: 【statefulset.yaml 2】 labels: app: api-stock tire: backend-api spec: containers: - name: api-stock image: asia.gcr.io/gcp_example/api-st ock:1.0.0 imagePullPolicy: Always resources: requests: cpu: 150m memory: 300Mi 【statefulset.yaml 3】 limits: cpu: 900m memory: 900Mi envFrom: - configMapRef: name: api-env ports: - containerPort: 8080 - mountPath: /apps/config/ name: api-config readinessProbe: httpGet: path: /health/check port: 8080
  13. Kubernetes Sapporo for Beginners 設定ファイル 環境毎に異なるような設定ファイル類はConfigMapや、機密情報用のSecretによ り保持する。(右記はConfigMap定義。) ①のように   ファイル名: |-

      内容 と記述することでファイル自体を定義することができる。 • 環境毎に異なる要素は基本的にDBの接続先や鍵ファイルのようなリソー スファイルである • 例えばjavaであれば、そういったファイルはjar/warの外から取得するよう に外出しする • その上で、Kubernetesの機能であるConfigmapやSecretを使うことでコン テナ内の特定の位置にmountすることができ、通常のディスク上のファイ ルと同じように扱うことができる kind: ConfigMap metadata: name: api-stock namespace: backend-api apiVersion: v1 data: application.properties: |- server.port=8080 application.context_path=/stock ①
  14. Kubernetes Sapporo for Beginners 在庫PJ Opsマシン 全体像 feature ブランチ Gitサーバー

    develop ブランチ release ブランチ Gitlab-runnerマシン (CI/CDツール) GCP master ブランチ App テスト App ビルド Docker ビルド Kubernetes デプロイ App テスト App ビルド Docker ビルド Kubernetes デプロイ Docker タグ Container Registry Google Kubernetes Engine 開発環境クラスタ ステージング環境クラスタ 本番環境クラスタ Kubernetes デプロイ作業 ←-----------------CIパイプライン------------------→ 本番設定反映作 業 設定PJ(※) master ブランチ 設定 反映 ※省略しましたが、環境別にプロジェクトを 分けてロール管理。 在庫 取引 … 在庫 取引 … 在庫 取引 … ①開発完了・テス ト完了時に特定ブ ランチに反映 develop:開発 release:ステージ ング master:本番 ②ブランチに対応したパイ プラインが実行される ③パイプライン内で Dockerイメー ジが作成され、コンテナレジスト リに管理される ④CI内にて環境反映 ⑤反映指示を受けた Kubernetes はコンテナレジストリから Docker イメージを取得して起動 ⑥DB接続先などの 環境別設定類は ConfigMapや Secretという瀬って ファイルをYamlファ イル化したもので管 理し、マージ ⑧本番環境は設定 もアプリケーション デプロイも運用チー ムが実施 ⑦開発系の環境は マージにより設定反 映のパイプラインで Kubernetesに反映 このへん devチーム opsチーム
  15. Kubernetes Sapporo for Beginners CI/CDにおける本番環境とそれ以外の環境の違い • 本番環境向けにソースのビルドや Dockerイメージのビルドは基本的に実施しません ◦ テストで作成された実行ファイルや

    Dockerイメージをそのまま利用することで、間の構成管理で不 具合が入り込む余地をできる限り無くす ◦ 前述したConfigMapなどを組み合わせて実現 • 本番環境に対しては自動的に反映はさせない ◦ 人の手またはそれに準ずるものをトリガとして反映 ◦ 品質適合判定・承認といった、プロセスを守らざるを得ない状態とする ◦ 不慮の事故を減らす
  16. Kubernetes Sapporo for Beginners 設定反映・アプリケーションデプロイ • 新しいバージョンのデプロイ ◦ 新しいイメージバージョンに書き換えて反映 【statefulset.yaml

    2】 spec: containers: - name: api-stock image: asia.gcr.io/gcp_example/api-stock:1.0.1 imagePullPolicy: Always $ kubectl apply -f statefulset.yaml • スケールアウトをコマンドから行う例 $ kubectl scale statefulset api-stock --replicas=5
  17. Kubernetes Sapporo for Beginners Kubernetesによる自動復旧 • Kubernetesでは、コンテナに障害が発生して停止した際などには、定義されている状態をあるべき形とし て、自動的に復旧する機能が備わっています $ kubectl

    get pod | grep api-stock-0 api-stock-0 1/1 Running 0 3d $ kubectl delete pod api-stock-0 pod "api-stock-0" deleted $ kubectl get pod -n backend-api|grep api-stock-0 api-stock-0 0/1 ContainerCreating 0 7s $ kubectl get pod -n backend-api|grep api-stock-0 api-stock-0 1/1 Running 0 30s ①Running中 ②コンテナの入った Podを削除 ③コンテナ作成が自動的に始まる ④自動的にRunningに戻る
  18. Kubernetes Sapporo for Beginners この開発を取り入れる前後の変化一例 修正の度に発生するビルド~サーバー 担当者へ依頼しての環境反映 前 後 CIの自動化により開発環境では一日

    50 回以上のデプロイが可能に 開発環境でうまく動いていたのに本番環 境でエラーになる。 Kubernetesさんが自動で定義ファイル に従いあるべき姿に復旧 サーバー止まっちゃった・・・ サーバー担当帰っちゃってる>< コンテナ化により成果物の変更無くイ メージをそのままデプロイ 本番リリース時に致命的不具合発見。 あのファイルとこのファイル戻して・・・・ 一つ前のイメージを使えばええんやで ^^
  19. Kubernetes Sapporo for Beginners Kubernetesもまだまだ完璧ではない • 比較的新しい仕組みで、バージョンアップ速度も速い ◦ 3カ月ごとのメジャーバージョンアップ ◦

    それに比例して管理ツール類を使う場合、そのバージョンアップ管理も必要 • 対応できる技術者が少なく、環境面が一部の人に負荷が集まる • 安定していない部分もまだある ◦ 突然マイナーバージョンアップで挙動が変わったり ◦ LB定義を更新しても動作に反映しない場合があったり(これは GCPか) • コンテナ化したことで内部が見えにくいという面も ◦ 慣れかな