Rancher Day 2019の資料です。

1. ©Internet Initiative Japan Inc. ‐ 1 ‐‐ 1 ‐
寺田 充毅
Rancher/k8sを利用した運用改善の取り組み
(Rancher Day 2019/07/24)

2. ©Internet Initiative Japan Inc. ‐ 2 ‐‐ 2 ‐
自己紹介 & チーム紹介
 名前：寺田 充毅(Michitaka Terada)
 仕事：オブジェクトストレージの開発、運用
 会社：株式会社インターネットイニシアティブ
 部署：IoTビジネス事業部 プラットフォーム開発課
 趣味：
バードウォッチング 農業 ギター演奏

3. ©Internet Initiative Japan Inc. ‐ 3 ‐‐ 3 ‐
担当サービス IIJオブジェクトストレージサービス
 内製のs3互換ストレージ
 サービスを構成する各アプリケーションがREST APIでつながっている
 サーバ台数は二ケタ前半
フロントサーバ(外部向けREST API)メタデータ管理
契約管理 分散ファイルシステム
インターネット
分散DB

4. ©Internet Initiative Japan Inc. ‐ 4 ‐‐ 4 ‐
今回のテーマ
Kubernetesの初心者チームがオンプレミスに
Kubernetesを構築し、現行サービスをマイグ
レーションさせるまでの試行錯誤を共有する

5. ©Internet Initiative Japan Inc. ‐ 5 ‐‐ 5 ‐
動機

6. ©Internet Initiative Japan Inc. ‐ 6 ‐‐ 6 ‐
Kubernates(k8s)をサービス基盤に使う動機
 直面している問題
• 本番とステージングの差異に起因するデプロイ事故の頻発
• バージョンアップで内部APIのインタフェース齟齬が起き障害発生
• バージョン推移で初めて気が付く失敗
• 複数の社内基盤に対応出来るポータビリティの確保が必要になった
 今回の解決手段
• デプロイの改善&試験強化
• デプロイ、試験を自動化して組合せ試験の強化
• Blue/Greenの導入による障害時間の短縮
• テストをした組み合わせ一式を丸ごとデプロイすることで事故を減らす
• インフラとアプリの間に層(k8s)を導入して基盤を抽象的に扱う
 APIの設計改善、品質保証の強化でもアプローチするべきだが、今回はデプロ
イで解消する方向
 東日本リージョンの追加に合わせてアーキテクチャを見直すことに決定

7. ©Internet Initiative Japan Inc. ‐ 7 ‐‐ 7 ‐
Kubernetesを基盤に使う？
 2017年の秋ぐらいから検討開始
 経験値0なので、まずは検証から
• アークテクチャ(方式)は作りながら試行錯誤で進めて行った状況
プロトタイピング
(コンテナ化、manifest)
k8s構築技術の確立
性能試験、安定性試験
k8sに対する学習
方式検討/設計/実装
性能試験
アプリマイグレーション
(helm化とか)
障害試験
基盤設計
(サーバ、NW)
セキュリティ設計
機能試験k8s構成設計
監視設計
検証 構築/実装 試験
ロングラン
CI/CD
ログ収集
リポジトリ ボリューム管理 ←このあたりを中心に今日は話します。

8. ©Internet Initiative Japan Inc. ‐ 8 ‐‐ 8 ‐
検証編

9. ©Internet Initiative Japan Inc. ‐ 9 ‐‐ 9 ‐
k8s構築技術の確立
 基盤
• ほぼオンプレミスの自社クラウド
• 社内のk8s環境の検討が始まっていたが、オブジェクトストレージの基盤要件を満たす
I/O性能、NW性能は無さそうだったので除外
 どうやってk8sを構築するか
• 構築ツール候補：kubeadm, kubespray, RKE etc
• 要件
• とにかく簡単であること
• オンプレのingressどうするのか問題をクリアしている
• HA構成を構築できる
• ドキュメント調査してRKEを第一候補に
 RKEより下のレイヤをどう構築するか？
• TerraformとAnsibleを利用
• 自社クラウド用のRancherドライバを以前は開発、利用していたがこののころは不透
明だったので除外
 オーバレイ(flannel)の構築で試行錯誤
• 複数面ある構成で、ルーティングの設定をRKEが入れてくれるという思い込み
• ツールを使う場合は、各ツールの担当範囲を理解しないと狭間に落ちるタスクがある

10. ©Internet Initiative Japan Inc. ‐ 10 ‐‐ 10 ‐
プロトタイピング – アプリをk8sに載せる
 Kubernetes力が足りない
• 日本語の書籍もまだ(あまり)なかった
• 勉強会に参加したり、ドキュメント読んだり色々な手段で情報収集
• 幸い環境は立ったので、触りながらStep by Stepで覚えていった
• チームの所帯が小さく、かつプロトをやっていたのは2人だけだったので、内部の共有
等無く、ひたすら試して学ぶ
 最初から無理をしないことを心掛けた
• 最初はLiveness Probeも、Resource Limitなども書かず、ただdeployするだけのシン
プルなマニフェストを書く
• kubectl editで実験してmanifestに書き戻す
• おそらく皆さんこんな感じ？
• helmは存在を知ってはいたが手を付けず

11. ©Internet Initiative Japan Inc. ‐ 11 ‐‐ 11 ‐
プロトタイピング – アプリをk8sに載せる
 もともとREST APIで接続されている構造
 Liveness probe相当も実装済み
 DNSラウンドロビンでAPI間の通信の冗長性、負荷分散を実施
• この仕組みはk8sと相性がよくKubernestesのDNSを使うように変更
 Java
• Heapの状態、GCの状態の収集はJMX exporterで収集
• サイドカーで載せている
• コンテナに詰めるにあたり1つあたりのheap量、スレッド数を小さくする方向で調整
• プロセス落ちた際の影響範囲の範囲を狭める
• k8sのスケジューリング機能との相性(大きいものははめ込みずらい)
• JVMが増えることでメモリ使用量は増えるが上記理由を優先
JVM
アプリ
監視プ
ラグイン
JVM
アプリ
死活監視
名前引いて..
呼び出す
munin
JVMの情報収集
JVM
アプリ
k8s
Liveness probe
名前引いて..
呼び出す
Prometheus
JVMの情報収集
JMX
exporter
JVM
アプリ
JMX
exporter
クライア
ント
DNS
クライア
ント

12. ©Internet Initiative Japan Inc. ‐ 12 ‐‐ 12 ‐
性能試験、安定性試験
 k8sで本当にストレージサービス提供できるのか、材料を集める
• 性能、安定性をまずは検証し判断をしたい
• 耐障害性は、アプリとk8sの組み合わせで実現するべきだと考えており、この時点では
追い込まなかった
 ネットワーク性能の基礎値を取得
• iperfを使って比較
• MSSを小さくした場合(ショートパケット風)、ホストNWより性能が落ちるが、今回の
通信要件では問題無いと判断

13. ©Internet Initiative Japan Inc. ‐ 13 ‐‐ 13 ‐
 ①ホストからの直接アクセスと、②Podからアクセスで性能差があるか確認
• 理屈では差はないはずだが裏取りを実施
• 性能差はなかった
 安定性試験
• 24時間以上連続で負荷をかけてエラーが発生しないか確認(gatling、locustなど)
• これが思いのほか苦戦
• dockerのワークディレクトリの見積もりミスでdisk pressureでeviction
• Javaのヒープサイズでresource limitを設定してkillされる
• スケジューラの制御方法がわからず、配置ガチャ状態
• Resource Limit / Requirement, Affinityなど大雑把に設定
性能試験、安定性試験
分散ファイルシステム
/mnt/volume/
/var/lib/kubelet/pods/～
/volumes/～/
POD
① ホストに直接マウント
テストツール
/mnt/volume/
テストツール
② podにマウント

14. ©Internet Initiative Japan Inc. ‐ 14 ‐‐ 14 ‐
結論：k8s上でオブジェクトストレージサービスは作れる
 アーキテクチャの概略図
• 2018年12月の「Rancher 2.0 Tech Night!」で書いたイメージをそ
のまま踏襲して実現まで行ける確証を得た

15. ©Internet Initiative Japan Inc. ‐ 15 ‐‐ 15 ‐
方式検討編

16. ©Internet Initiative Japan Inc. ‐ 16 ‐‐ 16 ‐
CI/CDパイプラインの検討
 取り組みの当初
• Jenkinsがあったが活用されていない状態
• コードによるUT、ITは完備されているが自動実行はUTまで
 人間系も含めてフローをかなり詳細に設計した
• これが失敗のもと
 理想が高すぎ、完成まで至っていない
• 小さく始める原則に沿ってなかった
• 個々の要素の接続は完了しておりあとはパイプラインを作るだけ(なのだが)
 自動化 = 総合力の勝負
• UT、ITの自動化
• モジュール設計、リポジトリへの格納単位の設計
• バージョン戦略
• フロー設計 etc..

17. ©Internet Initiative Japan Inc. ‐ 17 ‐‐ 17 ‐
CI/CDパイプラインの検討
 ツールの選定
• 候補はGitLab、Concourse CI、spinnaker
• 試行して使いやすかったGitLabでCI、連携(結合)試験から先をConcourse CIで実装す
る方針で開始
 最終的にはConcourse CIですべて実装
• ビルドとチケットの連携などGitLabのAPIを叩けば実現できたため一本化した
 どこで動かすか？
• 開発支援系のツールk8sを実行基盤にするものが多い
• 今日のテーマであるRancher(Server) もその一つ
• 運用用のk8sをサービス稼働用とは別に構築してツールはそこに載せることに
• 運用k8sとサービスk8s
 運用用k8sに載せているもの
• Ansible AWX
• Concourse CI
• Rancher
• (Longhorn)

18. ©Internet Initiative Japan Inc. ‐ 18 ‐‐ 18 ‐
 Concourse CIをコアにビルドが流れる
 最終的な本番へのデプロイ指図、切り替えは人間
Gitlab
CI/CDパイプラインの検討 - 全体像
運用 k8s Hosts
k8s Hosts(Stg)
運用 k8s Hosts
運用k8s
運用k8s
Concourse
サービス k8s
Docker
レジスト
リ
アプリ
作業用 Host
Rancher
CLI
ソース
コード
4. image push
2. コード取得
6. デプロイ(helmカタログを利用)
3. build & test
helm
repo
k8s Hosts(本番)
サービス k8s
アプリ
5. ステージへのデプロイ
してIT(ITは図略)
8. image pull
7.定義情
報の取得
11. 定義情
報の取得
10. デプロイ&ingress切り替え
9. 本番デプロイ&ingress
切り替え操作
1. git push
Rancher Server
青::ビルド～IT
緑: デプロイ
12. image pull

19. ©Internet Initiative Japan Inc. ‐ 19 ‐‐ 19 ‐
k8s適用範囲の検討 - どこまでk8sに載せるのか？
 勉強会等で話を聞くと会社、案件によってまちまち
 データのような重みのあるものをどう考えるか
App
サーバ
DB 分散FS DNS
ログ
収集
可視化 プロキシ
k8s
全部のせ？
App
サーバ
DB 分散FS DNS
ログ
収集
可視化 プロキシ
k8s k8s
データを管理するものは全部外にする？
App
サーバ
DB 分散FS DNS
ログ
収集
可視化 プロキシ
k8s
最小限でもいいのか？

20. ©Internet Initiative Japan Inc. ‐ 20 ‐‐ 20 ‐
k8sの適用範囲の検討
 我々の結論：アプリケーションだけ乗せる
 ホストの役割を分類
• アプリケーションサーバ
• データサーバ(DB、分散FS)
• ユーティリティ
• DNSキャッシュサーバ、NTPサーバ等APIリクエストが直接流れないサーバ群
• 運用
• 踏み台とか、プロキシとか
 変化のスピード、頻度を検討
• データ、ユーティリティ、運用は変更の適用頻度が低い
• バージョンアップ、セキュリティfixの適用がメインで設定変更もほぼ無い
• 結局ホストへのfix適用というタスクは残る
• アプリケーションは変更の適用頻度が高い(適用速度上げたい)
 スケールアウトの有無による検討
• 顧客要求に応じてスケールアウトが必要なレイヤはアプリケーションサーバ
のみ

21. ©Internet Initiative Japan Inc. ‐ 21 ‐‐ 21 ‐
運用設計
 アカウント管理
• Rancherを利用して管理することに決定
• ロールによる操作権限の管理を実施し、かつRancher経由で操作を行うこと
で事故を減らす
• 完全ではないが素のkubectlによる運用を排除している
 デプロイ
• 今は手動で実施中(不本意ではあるが)
• GUIベースでカジュアルにデプロイしている
• 自サービスhelmチャートを作成して、それをカタログとして登録している
• Blue / Greenの切り替えはGUIからingressの設定を変更して対応
• 人為的ミスは廃しきれていない
 アプリの設定変更
• 全てデプロイ扱い

22. ©Internet Initiative Japan Inc. ‐ 22 ‐‐ 22 ‐
監視、ログ収集
 ログ収集はk8sのスコープ外
• Docker管理下のログをfluentdで収集して集める
• 公式ドキュメントに記載がある
• 収集後にログからエラーを拾って通知
• (余談) 作業中のログ確認はRancher GUIかSternでやることが多い
• アプリのDebugはStern
 メトリクスの収集&監視
• Podの監視はPrometheusで実施
• 現状これを超えるものはない
• ホストの監視はIIJ内製の監視基盤
• KubernetesのAPI
• 監視基盤の監視はIIJの監視サービスで監視
 検証段階ではPrometheus、fluentdは公式リポジトリのhelmチャートを
ベースに導入していたが、現状はRancherの機能を使って導入している

23. ©Internet Initiative Japan Inc. ‐ 23 ‐‐ 23 ‐
監視、ログ収集
 かなり複雑
• 監視システムを監視して、そこからアプリを監視
• 多層化しており複雑だが簡素化する方法が思いつかない
内製監視システム用 Hosts
IIJ内製監視システ
ム
サービス用 k8s Hosts
サービス k8s
アプリPrometheus
Prometheusはaffinityを使ってアプリと
は別のホストに入るようにしている
IIJ統合運用監視サービス
APIサーバ
死活監視
ホストの監視
(SNMP)
ホストの監視
(SNMP)
APIキックで
メール、架電
IIJ内製メトリクス
収集ツール
SNMP情報収集
flu
en
td
ログ収集サーバ
(正副)
OSレベル
のログ
fluentd
健全性監
視テスト
flu
en
td
健全性試験を実施
ワードをひっ
かけてキック
APIキックで
メール、架電
健全性試験でNGの場
合は架電する仕組み

24. ©Internet Initiative Japan Inc. ‐ 24 ‐‐ 24 ‐
監視、ログ収集 – なぜRancherに変更したか？
 理由：システム状況をダッシュボードから俯瞰して把握できるから
 実装物はアカウント連携プラグインが導入されているだけで、 Prometheus
Operatorから大きな変更がない
• 既存ナレッジ、監視連携用のアプリがそのまま使えリスクは少ないと判断
 監視項目が素のOperatorで入れた場合と比べると監視項目が少ない
• 必要に応じて足していっている状況
CPU、メモリ、NWの状況が
deployment単位で一画面で確
認できる。
昔のRancherライクな状態になる。

25. ©Internet Initiative Japan Inc. ‐ 25 ‐‐ 25 ‐
本番化するまでのもう一山

26. ©Internet Initiative Japan Inc. ‐ 26 ‐‐ 26 ‐
性能試験、障害試験
 性能試験
• シングルテナントなので目いっぱいリソースを使えるようにチューニング
• 動的スケールアウト未対応なので既存の考え方で試験できた
 障害試験
• プロセスダウン、サーバダウン、NW障害など地道に実施
• 既存システムの試験方法、考え方と大きな差はない
• Etcdのデータ破壊などまだ出来ていないものもある
• 現時点ではRKEのコマンドでバックアップを取っているのでそれを戻す
 アプリケーション側の見直し
• Liveness Probeは最後まで既存実装そのまま利用できた
• 各アプリケーションが管理するデータリソース(ファイルシステム、DB）が健全に利用できない
場合failするように実装
• デプロイ先のノードの故障をきっかけに再デプロイが実行されることを意図している
• ファイルシステム、DBの全損などで大移動が発生するがレアケースとして扱っている
• Manifestの見直し
• 適切なスケジュールのためResource Requirements/Limitsをかならず書く

27. ©Internet Initiative Japan Inc. ‐ 27 ‐‐ 27 ‐
まとめ

28. ©Internet Initiative Japan Inc. ‐ 28 ‐‐ 28 ‐
まとめ
 IIJオブジェクトストレージの新リージョンをk8sベースのアーキテク
チャで構築した
 運用、開発は効率化できたのか？
• デプロイの簡便にするという目的は達成
• Blue / Greenデプロイも実現
• CI/CDパイプライン未完成な状況でリリース後に改善していく
 Rancherの活用場面は？
• k8sの構築、関連コンポーネントの導入(Prometheus、fulentd)、ユーザ管
理、権限管理、システム状況の把握、監視項目の投入、抑止、デプロイ
 今後の展望：アプリケーションの粒度見直し
• メンテナンス性が落ちているので分解していきたい
• 一度k8sに載せてしまえばソフトウェアアーキテクチャの改善は簡単になる
• 機能拡張が既存コードに影響しないようポン付けできるアーキテクチャに変える予定

29. ©Internet Initiative Japan Inc. ‐ 29 ‐‐ 29 ‐
オンプレでもあきらめないで！

30. ©Internet Initiative Japan Inc. ‐ 30 ‐‐ 30 ‐