freee 株式会社 Kubernetesへのデプロイメント 〜進化の過程と展望〜 前半パート 2018.07.11 Kubernetes Meetup Tokyo #12 

- メーカーの研究所を経て半年前にfreeeにJoinし たWebエンジニア見習い - Kubernetesはここ3ヶ月ほど - 会社blogでもk8sについて書いてます - KubernetesでのService公開方法に関する検証 - Github: at-k - Twitter: at_k Atsushi Kawamura 河村 篤志 freee株式会社 2 

The package manager for Kubernetes 

4 - helm : [hélm] 【名】 舵 - Kubernetes(ギリシャ語で航海長)におけるパッケージマネージャ - aptやyum、brewのようにクラスタへのパッケージインストールを補助 - CNCFプロジェクト、 Microsoft, Google, Bitnamiの協力の元で開発推進 Helmとは 

Helmについて話すその前に 

Kubernetesへのdeploy 皆さんどうやっていますか？ 

7 0. 何かクラスタに入れたいアプリケーションがある 1. コンテナイメージを用意する 2. manifestを書く - deployment.yaml, service.yaml, rbac.yaml, … 3. 環境ごとにmanifestを用意する - deployment-staging.yaml, service-staging.yaml, ... 4. CIパイプラインを書く - kubectl apply -f deployment-${stage}.yaml, ... 基本的なデプロイ方法 

8 適切なコンテナイメージ問題 - 公式イメージを使うことが望ましい - 公式がない場合は？自作？ 大量のManifestファイル問題 - 1つのパッケージに複数のmanifest、さらに環境ごとに増殖 - 管理が煩雑 - 設定の見通しが悪く、変更への検証コストが高い - コピー & ペースト、品質の低下 - yaml書きたくない 基本的なデプロイ方法: 何が問題？ 

9 適切なコンテナイメージ問題 - 公式がなければ准オフィシャルなイメージを使いたい - どこか信頼のおけるレポジトリは？ 大量のmanifest問題 - 定形的なもの、類型はまとめて整理したい - そもそも、同じアプリをインストールする場合、ある程度どのケースでも似たよう な設定になったり、共通するベストプラクティスがあるのでは？ ではどうするか 

The package manager for Kubernetes 再び 

11 filebeat - コンテナのログを収集・送出するElastic社製log shipper filebeatのimageはどうする、どうクラスタ上に配置しよう、 設定ファイルの渡し方、ログの収集はどうやろう、セキュリティは、etc etc.. 例: filebeatをinstall Container A Container B elasticsearch (一例) filebeat 疑問 

12 % helm search filebeat NAME CHART VERSION APP VERSION DESCRIPTION stable/filebeat 0.2.0 6.2.3 A Helm chart to collect Kubernetes logs with fi… % helm install stable/filebeat -n hello-filebeat % helm list NAME REVISION UPDATED STATUS CHART NAMESPACE hello-filebeat 1 Wed Jul 11 00:29:18 2018 DEPLOYED filebeat-0.2.0 default % kubectl get pod NAME READY STATUS RESTARTS AGE hello-filebeat-rdxzm 1/1 Running 0 4m ...and other pods とりあえずhelmでInstall 探す Install ! 確認 確認 確かに簡単ではあるがこれで期待の設定になっているのか？ 

13 デフォルト設定を確認する % helm inspect values stable/filebeat 〜 数十行のyaml 〜 … config: ... output.file: path: "/usr/share/filebeat/data" filename: filebeat rotate_every_kb: 10000 number_of_files: 5 ... Elasticsearchへログを送りたい デフォルトの設定はどうなっているか確認する ファイル保存がデフォルト動作のようなので、ここを書き換えたい # helm inspect readme コマンドも仕様確認に有用 # もしくはkubect exec -it shでコンテナに入って直接設定を確認するとか 

14 カスタマイズする % vim values.yaml 〜 設定追加 〜 % cat values.yaml config: output.file.enabled: false output.elasticsearch: hosts: https:elasticsearch-host:9243 % helm upgrade hello-filebeat stable/filebeat -f values.yaml オーバーライドする部分のみ設定を追加、ファイル指定してupgrade values.yamlはデフォルト設定からの差分として管理、以降も必要に応じて加筆 

15 検証・ロールバック # Dry run & 適用内容検証 % helm upgrade hello-filebeat stable/filebeat -f values.yaml --debug --dry-run # diff pluginでの確認 % helm diff upgrade hello-filebeat stable/filebeaaat -f values.yaml # revision間での差分確認 % helm diff revision hello-filebeat 2 3 # 特定revisionに戻す % helm rollback hello-filebeat 2 

16 適切なコンテナイメージ問題 - 公式がなければ准オフィシャルなイメージを使いたい - メンテナによりレビュー・検証されたイメージ 大量のmanifest問題 - 定形的なもの、類型はまとめて整理したい - テンプレート化・簡略化されたパッケージ管理スキーム Helmによるソリューション 

Inside Helm 

18 - helm (舵) - client side package manager - tiller (舵柄) - server side package manager - あまり意識することない、将来的にはなくなるかも - chart (航海図) - packageのテンプレート Helmの構成 

19 # helmコマンドで参照されるpackage一覧をgit clone % git clone [email protected]:kubernetes/charts.git charts % cd charts && ls ... stable/ … incubator/ … % ls stable/ -l | wc -l 198 % ls incubator/* -l | wc -l 48 % cd stable/filebeat && ls Chart.yaml README.md templates/ values.yaml - values.yaml - chartのデフォルトパラメータ - templates/* - template本体 Chartを覗く 

20 % cd templates/ && ls NOTES.txt _helpers.tpl clusterrole.yaml clusterrolebinding.yaml daemonset.yaml secret.yaml serviceaccount.yaml % cat daemonset.yaml apiVersion: apps/v1beta2 kind: DaemonSet ~ 略 ~ spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" imagePullPolicy: {{ .Values.image.pullPolicy }} args: - "-e" {{- if .Values.plugins }} - "--plugin" - {{ .Values.plugins | join "," | quote }} {{- end }} ~ 略 ~ templateを覗く - 通常のmanifestにtemplateが埋め込まれた形 - .Values.xxがvalues.yamlの記述に対応 

21 すでにmanifestがある場合 - どこをパラメータとして公開すべきか検討する - 必要箇所をテンプレート化する manifestがない場合 - 既存の類似機能のchartをベースに作る helper関数が用意されているので適宜活用する 作成したらPRを出してプロジェクトに貢献しましょう！ Chartを自作する 

Issues 

23 - 個々のchartの仕様 - 仕様を確認する手間に加え、そもそも正しく必要なパラメータが公開されているか - chartがメンテナンスされない、chartがない問題 - コントリビュートする、もしくは代替を考える必要がある - chartのバージョンアップへの追従 - 従来どおり、使うバージョンを指定して運用、アップデートは慎重に - 自社サービス・アプリのchart化 - 自社内運用だけなのにそこまでやる必要があるか(大量のyamlを書くことに変わりはない) - template化の手間と秤にかける必要あり Helmの課題 

まとめ 

25 - Kubernetesへのアプリケーションのデプロイを簡略化 - manifestが集約・隠蔽されて、見通しの良い構成に - テンプレートによる環境毎の特殊化 - どこを変更したかひと目で分かり、管理が楽に - 公式でメンテナンス・レビューされるチャート - 比較的安心して使用できる - Helmの検証機能、revision管理 - トラブル・手戻りのコスト削減 - 一方で課題もあり Helmによるデプロイ改善 

26 課題はありますが、公開されているchartを使う分にはとてもよいツール 積極的に活用してデプロイパイプラインをすっきりさせましょう 公式chartがなければコントリビュートしましょう 後半へ続く 

スモールビジネスに携わる すべての人が「創造的な活動」に フォーカスできるよう