2019/06/18 に開催された Rancher Meetup Deep Dive #02 のイベントレポートです。

●イベント概要
過去のRancher Meetupでは、初心者の方々に向けたGenericなコンテンツを中心にお届けしてきました。Rancherのユーザーも増え「もう少しレベルの高いセッションを聞きたい、ディスカッションをしたい」という声も聞かれるようになりました。そこで今回「Rancher Meetup Deep Dive」を企画してRancherの本番ユーザーと、本番利用を想定している方のための勉強会を開催する運びとなりました。

■オープニング

@tsukaman さん

●イベントの趣旨
サブスクリプションを買うだけでは不安
Rancherを本番で使っているユーザー同士の交流をする場として
活用していきましょう！

■Rancher2.0を活用した開発・運用効率の改善への取り組み

寺田 充毅 さん [IIJ]

●導入
カットオーバーに失敗してまだ本番運用できていない
バグを踏み抜いてしまったお話です

●IIJオブジェクトストレージサービス
・内製のS3互換ストレージ
・分散DB
　　-> メタデータ -> 契約管理
　　-> フロントサーバ(REST API) -> 分散ファイルシステム
　　-> Internet

●テーマ
・k8s初心者がオンプレk8sを構築
・現行サービスを移行するまでの試行錯誤

●直面していた問題
・本番とステージングの際でデプロイ事故
・バージョンアップでAPIのIF齟齬
　　システム障害の60%はデプロイ時に起きる
・ジプシー状態
　　会社の基盤に合わせて引っ越し

●解決手段
・Blue/Greenで障害復旧を時短
・テストした組み合わせをまるごとデプロイ
・インフラとアプリの間にk8sレイヤを挟んで抽象化

●k8sを基盤に使う
・2017年秋から検討開始
　　まずは検証から
・k8s構築技術
　　基盤
　　　　ほぼオンプレの自社クラウド
　　　　オブジェクトストレージなのでI/O性能、NW性能が肝
　　どう構築する?
　　　　kubeadm，kubespray，RKE etc
　　　　-> RKEへ
　　複数セグメントでの通信ではまる
　　　　-> Rancherのエンジニアに助けてもらった
　　Static Routingは必要で、ansibleで実現

●プロトタイピング
・k8s力が足りない
　　当時、日本語情報がなかった
　　環境は立ったので、触りながらstep by step
　　最初から無理をしない
・名前を引いたらその先にサービスがある構成
　　DNSからk8sに変更
・Heap, GCの状態は
　　JMX exporter -> prometheus
・メモリが10GB必要なアプリ
　　分割してk8sのスケジューリングに乗るように考慮

●性能試験、安定性試験
・性能、安定性を検証したい
　　iperfでflannel, Rancherを比較
　　-> ストレージなのでデータを流している時間が長いから問題なさそう
・ストレージ性能
　　glasterFSを使っている
　　マウントを誰がやるかだけなので、差はなかった
・安定性試験
　　ワークディレクトリの見積もりミスで、disk pressureでeviction
　　Javaのヒープサイズでresource limit を設定してkillされる

-> k8sでオブジェクトストレージサービスは動かせる！

●CI/CDパイプラインの検討
・当初
　　CIパイプラインがあったが活用されていない状態
　　UT、ITはあるが、自動はUTまで
・手作業を含めてフローを詳細に設計
　　-> 理想が高すぎて進まず。少しずつ
・ツール
　　GitLab, Concourse, spinnaker
　　-> Concourseで全部できる
・構成
　　Concourseをコアにビルドが流れる
　　運用k8s、アプリk8s を ネットワーク疎通性の問題で2重持ち

●どこまでk8sに載せるか
・ホストの役割を分類
　　データ、アプリ、ユーティリティ、運用
・変化のスピード、頻度
・スケールアウトの有無
-> 目的を突き詰めていったらアプリだけ載せる方針になった

●監視、ログ収集
・ログの確認はRancher GUIかStern
　　grepするならstern
・k8sの状況をPrometheusで監視
・内製監視システムでk8sを監視
　　-> fluentdで集約
・内製監視システムを監視するサービス

●セキュリティ
・素のkubectlでの操作を排除しようとしている
　　namespaceを消してしまった経験
　　-> Rancher CLIで
・ネットワークポリシーを使うか？
　　calicoはヒトでは読めないのでflannelで

オンプレでもあきらめないで！

■Rancher v2でML基盤始めます

@yassan168 さん [マイクロアド]

●マイクロアド
・オンプレメインでクラウドも使ってます

●やりたいこと
・データサイエンティストが実験できる場所
　　できるだけリードタイムゼロで
・学習モデルの効果を比較したい

●制約条件
・データはオンプレ上 TBオーダー
・オンプレ x HTTP PROXY
・k8sに精通したヒトはいない
・学習モデルの利用者は外にいる

●何が必要か？
・マルチテナントのk8sクラスター管理
　　-> rancher
・k8sに精通したヒト
　　-> Rancherの有償サポート
　　　　詳しい人を雇ったと思えば高くもない
　　　　サポート範囲が広い
・すぐに準備できてスケールアウトできる学習モデル作成環境
　　-> すぐに準備できないのでクラウド
　　　　MLならGCPが便利そう
　　　　kubeflow
・オンプレに学習モデルをデプロイできるしくみ
・複数学習モデル、複数verの学習モデルが同居できる、使い分けできる
　　-> TensorFlow Servingでいけるらしい

●実現方法
・kubeflow on GKE
・学習モデルはGCS
・オンプレ TF-Serving on Docker
・生データを前処理 -> 中継サーバ <- アプリ

●ここで登壇依頼
・6/10！
・rancherだし、いけるだろう

●悲しい現実
・HTTP PROXYの洗礼
　　これくらいなら想定内
・Rancher -> GKE作成
　　Helmからkubeflow でデプロイ
　　cattle-node-agentが全ノードでエラー
　　-> Rancher ServerがGKEから見えないから
　　　　NATでつなぐ？VPN張る？

「知っている」と「できる」の壁は厚い

■Rancher 2.2.4 アップデート情報

@Cheng さん [Rancher Labs]

●Rancher 2.2.4 変更点
・CVE-2019-12303
　　事象
　　　　fluuentdがdaemonsetで配置されている
　　　　複数プロジェクトで同じfluentdを共有
　　　　Fluentdコンテナーの設定ファイル
　　　　プロジェクト内の設定情報が外から見えてしまう
　　回避方法
　　　　バージョンアップ
　　　　v2.0.15
　　　　v2.1.10
　　　　v2.2.4
・CVE-2019-12274
　　事象
　　　　クラスタ作成
　　　　ファイルパスを渡せるノードドライバ経由
　　　　クラスター外のメンバーから見えてしまう
　　回避方法
　　　　バージョンアップ
　　　　v2.0.15
　　　　v2.1.10
　　　　v2.2.4
・プロジェクトレベルのモニタリング機能復活
　　クラスタ配下複数チーム
　　プロジェクト単位でalert, しきい値が設定できる機能が復活
　　クラスタレベルは今までどおり
・クラウド対応強化
　　AKSクラスタ構築でAzure AKSリージョン追加
　　RKEクラスタ構築でAWS EC2リージョン追加
・issue対応
　　Rancher UIパフォーマンス改善
　　　　機能画面の描画時間が短縮
　　　　通信のパフォーマンス

●Rancher 2.3
・2019/09リリース予定
　　alpha版出てます
・Windows GA Support
　　worker nodeとして
・クラスタのテンプレート機能
　　今までは手で同じ設定でつくっていたはず
　　同じ設定のクラスターを量産できる
・クラスタのセキュリティスキャン
　　定期スキャン
　　適用されたテンプレートの設定と差異を検知 -> 通知
・AWS AutoScalingグループ的な機能も
　　クラスタのノード数を一定数を維持

■クロージング＆今後の予定

@yassan168 さん

●Rancher Day
・7/24 渋谷ソラスタコンファレンス
・Cloud Native Days
　　7/22, 23 -> Rancher Dayへ

●RancherJP
・www.rancher.jp
　　内容刷新予定！
・slack.rancher.jp
　　rancherに限らずdocker, k8sの話ができます

●発表者募集中！
・はまったこと、現状の課題共有でも
・一緒に考えるネタになります

●運営メンバーも募集中！
・興味のある方はスタッフにお声がけを！

■感想

どこの現場でもネットワークの問題で開発が進まない問題を抱えているのだな、と改めて感じました。お手伝いさせてもらっている会社でも、閉じたネットワークが原因で古いOSだらけでdockerさえ使えないサーバがほとんど、k8sつかうならどれだけ穴あけ申請申請が必要なのか想像もつかないような状況でした。。。

rancherのおかげで、最小限のdocker imageでk8sが立てられるようになりましたが、これからの仮説検証のスピードについていく開発をするなら、早くzero trust networkのような考え方にシフトしていく必要がありそうですね。

登壇者の皆さん、運営の皆さん ありがとうございました！