Rancher/k8sを利用した運用改善の取り組み

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

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

IIJオブジェクトストレージサービス
 内製のs3互換ストレージ
 サービスを構成する各AppがREST APIでつながっている
 サーバ台数は二ケタ前半
 今日はこのサービスの新リージョンを構築する際にトライしたことを話します
フロントサーバ(外部向けREST API)メタデータ管理
契約管理分散ファイルシステム
インターネット
分散DB

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

動機

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

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

検証編

 基盤
• ほぼオンプレミスの自社クラウド
• 社内のk8s環境の検討は走っていたが、オブジェクトストレージを実装できるI/O性能、
NW性能は無さそうだったので除外
 どうやってk8sを構築するか
• 構築ツール候補：kubeadm, kubespray, RKE etc
• 要件
• とにかく簡単であること
• オンプレのingressどうするのか問題をクリアしている
• HA構成を構築できる
• ドキュメント調査してRKEを第一候補に
 RKEより下のレイヤをどう構築するか？
• TerraformとAnsibleを利用
• 自社クラウド用のRancherドライバを以前は開発、利用していたがこののころは不透
明だったので除外

 RKEでCluster Networkが構成出来ない問題に直面(flannel)
 今回は複数面NWがある構成
• グローバルセグメント、内部セグメント、管理セグメント
• Cluster Networkは内部セグメントで通信させたかった
• IaaSの仕様上、デフォルトGWは管理セグを向いている
 この環境だと内部セグを指定してRKE upしても通信が成立しない
• RKEの設定を試行錯誤(advertise addressを追加)
• これだけではダメでStatic Routingの設定も必要
• 複雑な面構成のNWは構築時点で挫折しやすい
 何かを使うときはスコープを明確にしないとハマる
• k8sは要件を満たすNWをCluster Networkとして使うというスタンス
• RKEはCluster Networkの構成をしてくれるが、さらに下のIP NWのレイヤーは面倒を
見てくれない
 このあたりから、k8sを動かす、かつ安定に動かすにはホストやDockerを適
切に構成する必要がある点を理解し始める
• Ansibleで頑張る

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

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

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

 ストレージの性能測定
• クラスタ外部に分散ファイルシステムを構築
• ホストに直接マウントして読み書きするパターンと、k8sでマウントしてコンテナから
読み書きするパターンを比較
• 仕組みとしては、ホストへのマウントを手動でやるのか、k8s(CSIドライバ)がやるか
の差でしかなく、当然ながら性能差は無かった
 安定性試験、アプリも含めた性能試験
• アプリケーションをk8sに載せて負荷をかけて試験を実施
• 24時間連続稼働しておかしなことが起きないか確認
• これが思いのほか苦戦
• dockerのワークディレクトリの見積もりミスでdisk pressureでeviction
• Javaのヒープサイズでresource limitを設定してkillされる
• スケジューラの制御方法がわからず、配置ガチャ状態
• resource limit / requirement、affinityなど学びながら設定して何とか動くように

結論：k8sでオブジェクトストレージサービス動かせる
 Rancher 2.0 Nightというイベントで話をした際の、この図のようなアーキ
テクチャで進める
カタログに
よるデプロイ
k8sクラスタ
の構築
分散データベース
インターネット
分散ファイルシステム
本番
ステージング
自社クラウド基盤上
（略)
Blue/Green

方式検討編

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

CI/CDパイプラインの検討
 ツール
• 候補はGitLab、Concourse CI、spinnaker
• 実際に触ってみて感触の良かったGitLabでCIまで、Concourse CIで後半の工程を行う
想定で開始
 Concourse CIですべて実装する結論に
• Concourse CI が柔軟で、GitLabと役割分担する理由が特になかった
 開発支援系のツールにもk8sを実行基盤にするものが多い
• 今日のテーマであるRancher(Server) もその一つ
• 運用用のk8sをサービス稼働用とは別に構築してツールはそこに載せることに
 運用用k8sに載せているもの
• Ansible AWX
• Concourse CI
• Rancher
• (Longhorn)

CI/CDパイプラインの検討 - 全体像
 Concourseをコアにビルドが流れる
 最終的な本番へのデプロイ指図、切り替えは人間
Gitlab
運用 k8s Hosts
k8s Hosts(Stg)
運用 k8s Hosts
運用k8s
運用k8s
Concourse
サービス k8s
Docker
レジスト
リ
アプリ
作業用 Host
Rancher
CLI
ソース
コード
image push
コード取得
デプロイ(helmカタログを利用)
build & test
helm
repo
k8s Hosts(本番)
サービス k8s
アプリ
ステージへのデプロイ
(ITは図として略)
image pull
定義情報の取得
定義情報
の取得
デプロイ&ingress切り替え
デプロイ&ingress
切り替え操作
git push
Rancher Server

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

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

監視、ログ収集
 ログ収集はk8sのスコープ外
• Docker管理下のログをfluentdで収集して集める
• 公式ドキュメントに記載がある
• 通常のログの確認は、Rancher GUIかSternでやることが多い
• アプリのDebugはStern
 メトリクスの収集&監視
• 多層化している状況
• Podの監視はPrometheusで
• 現状これを超えるものはない
• ホストの監視はIIJ内製の監視基盤
• KubernetesのAPI
• 監視基盤の監視はIIJの監視サービスで監視

監視、ログ収集
 RancherのMulti Tenant Prometheus機能は未使用
• Rancher使わずPrometheus Operatorで導入当時
• 現在運用k8sに導入済みで、本番利用検討中
 ここまでやるのは運用負荷を考えるとお勧めしない
内製監視システム用 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の場合
は架電する仕組み

セキュリティ
 正直、まだまだ手を入れられる箇所がありそうな状況
 ホストのセキュリティは一般的な対応を実施している
 k8sの操作制限にRancherを利用
• Rancher経由で操作を行うことで、事故を減らす
• 完全には排除しきれていないが素のkubectlを排除中
• コマンドライン文化なのでRancher CLIを利用
 その他の検討
• ネットワークポリシーを使うかどうか
• 内外の接続に制約をかけられるのは非常に魅力的
• 結局使わなかった
• 経験値を積んできたflannelは対応していない
• トラブルシュートの難しさ(予測)
• Callicoのiptablesルールがかなり複雑で、NWポリシーを有効にすると輪をかけてやばい

まとめ

まとめ
 オブジェクトストレージのアプリケーションの管理にk8sを利用しています
 本番リリースはまだですが、間もなくリリースします
 Rancherは①k8sの構築ツール ②クイックなシステム状況の確認ツール ③
ユーザ管理ツールとして主に利用しています
 Multi Tenant Prometheusへ乗り換えようとしています
オンプレでもあきらめないで！

Rancher/k8sを利用した運用改善の取り組み

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Rancher/k8sを利用した運用改善の取り組み

Similar to Rancher/k8sを利用した運用改善の取り組み (20)

Rancher/k8sを利用した運用改善の取り組み