On-Premise Kubernetes on Rancher

On-Premise Kubernetes on Rancher
On-premise Kubernetes on Rancher
自己紹介金屋泰士 UZABASE, Inc SRE Team SPEEDAのインフラエンジニア（主にサーバ／ミドル）オンプレミス環境の経験が長い 2007年04月～　NAVITIME JAPANにて、基盤運用部サーバチーム所属 2011年10月～　Chip1Stop(半導体ECサイト）にて、インフラ全般担当 2014年04月～　UZABASEにJoin 　・k8s環境、ElasitcSearch環境、Xen仮想基盤、ハード監視、ストレージ等を構築
Table of Contents 1. Backgrounds 2. Why Rancher 3. What’s Rancher 4. k8s on Rancher 5. DevOps with k8s 6. Monitoring k8s 7. Next Generation
Backgrounds • SPEEDAはオンプレミス環境で稼働 • 巨大でモノリシックなアプリケーション • 開発者はマイクロサービスを推進したい • 開発者はコンテナ化を推進したい • 開発者はk8sを使いたい
Backgrounds • SPEEDAはオンプレミス環境で稼働 • 巨大でモノリシックなアプリケーション • 開発者はマイクロサービスを推進したい • 開発者はコンテナ化を推進したい • 開発者はk8sを使いたいアジャイルで高速に開発したい！
・小改修でも全体に影響・機能追加も大がかり・開発スピードが遅い・デプロイが遅い・増大し続けるヒープ・頻繁なGC ・サーバ増設のコストデータ量も更新量も多く、単純にクラウド移行も難しい Version:1.0
・小改修でも全体に影響・機能追加も大がかり・開発スピードが遅い・デプロイが遅い・増大し続けるヒープ・頻繁なGC ・サーバ増設のコストデータ量も更新量も多く、単純にクラウド移行も難しい Version:2.0 ・新機能はMicroService ・機能別に開発できる・e2eテストのコスト大・インフラへ依頼が多い（開発スピード上がらない）・多数のVM構築・リソース効率悪い・機能別にエンドポイント (LB)準備・運用コスト増加
・小改修でも全体に影響・機能追加も大がかり・開発スピードが遅い・デプロイが遅い・増大し続けるヒープ・頻繁なGC ・サーバ増設のコストデータ量も更新量も多く、単純にクラウド移行も難しい Version:3.0 ・新機能はMicroService ・機能別に開発できる・リソース効率アップ・運用コスト減・バランサも含め、開発者が環境構築でき、開発スピードアップ・e2eテスト環境も構築・Blue／Greenデプロイ
今回のスコープ kubernetes on Rancher DevOps with k8s モニタリング Rancher環境
Why Rancher Rancherを導入するに至った経緯　┗ 開発環境でdockerを導入した　　┗ コンテナ乱立で管理が困難　　　┗ 統合管理プラットフォームが必要
Dev with Docker 開発環境でdockerを使いたい docker engineを起動したサーバを複数準備
Dev with Docker 開発環境でdockerを使いたい docker engineを起動したサーバを複数準備コンテナの乱立・どこで何が動いているか分からない・クラスタ化されてないからリソース増強しづらい・どこで何が動いているか分からない・スケールが困難
Dev with Docker 開発環境でdockerを使いたい docker engineを起動したサーバを複数準備コンテナの乱立・どこで何が動いているか分からない・クラスタ化されてないからリソース増強しづらい・どこで何が動いているか分からない・スケールが困難統合管理したい使い易い環境が良い
Dev with Docker 開発環境でdockerを使いたい docker engineを起動したサーバを複数準備コンテナの乱立・どこで何が動いているか分からない・クラスタ化されてないからリソース増強しづらい・どこで何が動いているか分からない・スケールが困難使い易い環境が良い統合管理したい
What’s Rancher ・コンテナ統合管理プラットフォーム・RancherLabsが開発、運営、有償サポート・現行は1.6系(今回はこちら）
RancherOSの特徴　・軽量で新しいLinux/Docker 　・各環境で稼働 Cloud,VM,BareMetal 　・cloud-config.yml で一括設定可能　・Docker on Dockerで分離・モジュール化　・コマンドが軽量OSでは充実(defaultで)
軽量で新しいLinux/Docker ・随時追従(Stable) 2018/03時点・Docker 17.09.1-ce ⇔ 17.12.1-ce(本家) ・Linux 4.9.78 ⇔ 4.9.87(本家LTS) ・ISOファイルは70MB ・インストール後は300MB程度
各環境で稼働　・AWS（AMIあり）　・GCE（Imageあり）　・Digital Ocean 　・OpenStack、VMwareESXi、XenServer →しっかりメンテされていて安心
cloud-config.yml で一括設定可能・hostname,Network,Disk,SSH-Key,sysctl ・write_files でファイル生成可能・必要な設定を柔軟に設定可能
Docker on Dockerで分離・モジュール化ホスト（仮想 or 物理マシン） SYSTEM DOCKER 下記を提供・デバイス・コンソール・ネットワーク・基本サービス　(NTP,DNS等） USER DOCKER Docker Engineに相当ユーザのコンテナを稼働させる
Docker on Dockerで分離・モジュール化　・OS/dockerやConsoleを簡単に切替可能利用可能なdocker # ros engine list disabled docker-1.12.6 disabled docker-1.13.1 disabled docker-17.03.1-ce current docker-17.03.2-ce disabled docker-17.09.1-ce 切替え # ros engine switch docker-17.09.1-ce 利用可能なconsole # ros console list disabled alpine disabled centos disabled debian current default disabled fedora disabled ubuntu 切替え # ros console switch centos 利用可能なOSバージョン # ros os list rancher/os:v1.2.0 remote latest rancher/os:v1.1.4 remote available rancher/os:v1.1.3 local available running rancher/os:v1.1.2 remote available 切替え（バージョンアップ） # ros os upgrade -i rancher/os:v1.2.0
コマンドが軽量OSでは充実(default console) ・telnet netstat traceroute wget tftp ・less tr jq envsubst ・bash getopt expr basename dirname ・lsof lspci mount rsync
・コンテナ稼動・クラスタ／HA構成・スタック・Environment、RBAC、オーケストレーション・アプリケーションカタログ
Rancherクラスタの構成 rancher/server rancher/server rancher/server cattle外部DB 外部バランサ https://rancherXX.uzabase.com Rancher Agent rancher/agent rancher/agent rancher/agent Rancher Server ホスト管理・管理GUIを提供・管理情報（ユーザ、ホスト、レジストリ、etc...）・複数台サーバでクラスタ化・外部DBで管理情報を永続化・コンテナ稼働環境・Environmentで定義した（オーケストレーション、ユーザ）・必要に応じてホスト追加 Environment（ホスト、ユーザ、オーケストレーション）
コンテナ稼動・RancherServer（管理）　・管理GUI、管理情報、RancherAgent管理　・RancherAgent（コンテナ動作環境）　 rancher/server rancher/agent
Rancherクラスタの構成 rancher/server rancher/server rancher/server cattle外部DB 外部バランサ https://rancherXX.uzabase.com Rancher Agent rancher/agent rancher/agent rancher/agent Rancher Server ・管理GUIを提供・管理情報（ユーザ、ホスト、レジストリ、etc...）・複数台サーバでクラスタ化・外部DBで管理情報を永続化・コンテナ稼働環境・Environmentで定義した（オーケストレーション、ユーザ）・必要に応じてホスト追加 Environment（ホスト、ユーザ、オーケストレーション）ホスト管理
クラスタ／HA構成　・外部DB起動（MySQL）　・複数RancherServerを起動（外部DB接続）　・外部バランサに追加 docker run -d --restart=unless-stopped -p 8080:8080 rancher/server --db-host myhost --db-port 3306 --db-user username --db-pass password --db-name cattle
Rancherクラスタの構成 rancher/server rancher/server rancher/server cattle外部DB 外部バランサ https://rancherXX.uzabase.com Rancher Agent rancher/agent rancher/agent rancher/agent Rancher Server ・管理GUIを提供・管理情報（ユーザ、ホスト、レジストリ、etc...）・複数台サーバでクラスタ化・外部DBで管理情報を永続化・コンテナ稼働環境・Environmentで定義した（オーケストレーション、ユーザ）・必要に応じてホスト追加 Environment（ホスト、ユーザ、オーケストレーション）ホスト管理
スタック（docker-compose）　・アプリケーション、システムサービスをスタックとして管理　　・インフラストラクチャースタック　　　・システム共通で稼動するサービス　　　　・ネットワーク（CNI、Rancher内部DNS）　　・ユーザースタック　　　・ユーザーが作成したアプリケーション
docker-compose.yml 一般的な docker-composeファイル version：2 rancher-compose.yml マルチホスト用のdocker-compose スケール数などを設定できる
Rancherクラスタの構成 rancher/server rancher/server rancher/server cattle外部DB 外部バランサ https://rancherXX.uzabase.com Rancher Agent rancher/agent rancher/agent rancher/agent Rancher Server Environment（ホスト、ユーザ、オーケストレーション）インフラストラクチャースタック　ネットワーク／CNI(Container Networking Interface)、Rancher内部DNS マルチホストでのDockerネットワークをサポートユーザースタック　ユーザーが作成したアプリケーションホスト管理
Environment、RBAC、オーケストレーション下記をEnvironment(環境)として管理　・オーケストレーション（k8s,cattle,Mesos,swarm）　・ホスト　・ユーザ　・ロール（RBAC）
権限のタイプユーザタイプできることユーザA 管理者管理操作（ユーザ追加、アクセス権操作）含む全てユーザB ユーザ自分が所属するEnvironmentの情報を表示 Environmentタイプできること Owner 管理操作（マッピング管理）含む全て member Environment操作以外の全て restiricted 所属するEnvironment内のコンテナ操作 read only 所属するEnvironmentの情報表示のみ
管理者の例（フル権限）ユーザタイプできることユーザA 管理者管理操作（ユーザ追加、アクセス権操作）含む全てユーザB ユーザ自分が所属するEnvironmentの情報を表示 Environmentタイプできること Owner 管理操作（マッピング管理）含む全て member Environment操作以外の全て restiricted 所属するEnvironment内のコンテナ操作 read only 所属するEnvironmentの情報表示のみ
デプロイ用の例（CIから利用）ユーザタイプできることユーザA 管理者管理操作（ユーザ追加、アクセス権操作）含む全てユーザB ユーザ自分が所属するEnvironmentの情報を表示 Environmentタイプできること Owner 管理操作（マッピング管理）含む全て member Environment操作以外の全て restiricted 所属するEnvironment内のコンテナ操作 read only 所属するEnvironmentの情報表示のみ
参照用の例（監視ツール等）ユーザタイプできることユーザA 管理者管理操作（ユーザ追加、アクセス権操作）含む全てユーザB ユーザ自分が所属するEnvironmentの情報を表示 Environmentタイプできること Owner 管理操作（マッピング管理）含む全て member Environment操作以外の全て restiricted 所属するEnvironment内のコンテナ操作 read only 所属するEnvironmentの情報表示のみ
ユーザB ユーザA ユーザB RBAC ユーザロール Environment
Rancherクラスタの構成 rancher/server rancher/server rancher/server cattle外部DB 外部バランサ https://rancherXX.uzabase.com Rancher Agent rancher/agent rancher/agent rancher/agent Rancher Server ・複数台サーバでクラスタ化・外部DBで管理情報を永続化・管理GUIを提供・管理情報（ユーザ、ホスト、レジストリ、etc...）・ユーザコンテナを稼働させるリソースを、定義したEnvironmentで提供・必要に応じてホスト追加 Environment（ホスト、ユーザ、オーケストレーション）ホスト管理
アプリケーションカタログ　・簡単にアプリケーションを展開　・カテゴリ別に選択　・カスタマイズ可能
カテゴリ分類検索
ユーザースタックとして追加される WordPressが起動する
What’s Rancherまとめメリット　・Docker統合管理ツールとして完成度高い　・HAクラスタがとても簡単に構築できる　・アプリケーションカタログで、簡単にアプリ展開　・商用利用想定（RBAC、APIの監査ログが取れる等）注意点　・外部DBはSPOFなので、別途HAが必要
k8s on Rancher • 前述のEnvironmentで説明した通り、Rancherがオーケストレーションの１つとしてkubernetesを標準でサポートしている（Version1.8.5@2018/03時点）
k8s on Rancher ・Environmentのオーケストレーションでkubernetesを選択・Environmentにホストを追加すると、インフラストラクチャースタックとして、RancherAgentにkubernetesが展開される
k8s on Rancherクラスタ Rancher Agent rancher/agent rancher/agent rancher/agent Environment（ホスト、ユーザ、オーケストレーション）インフラストラクチャースタック　ネットワーク／CNI(Container Networking Interface)、Rancher内部DNS インフラストラクチャースタック　kubernetes（etcd、kubelet、master、proxy、kubectld、dashboard）インフラストラクチャースタック　kubernetes-ingress（namespace毎のingress or service） k8s外部のシステム
kube-proxy(全台で稼働) master(kube-api) kubelet(全台で稼働) etcd(3台で稼働)
凡例ホスト毎でのコンテナ配備状況 etcd(3台で稼働) kubelet(全台で稼働) master(kube-api) kube-proxy(全台で稼働) kubernetesスタック
安定稼働のための工夫（etcdの専用化） etcd用ホストはアプリを配備させてない(cordon)
正常にk8sスタックが展開されるとダッシュボードが表示可能（この先はkubernetesの世界）
管理GUIから、kubectl を実行できる（権限があるユーザのみ）
k8s on Rancherクラスタ Rancher Agent rancher/agent rancher/agent rancher/agent Environment（ホスト、ユーザ、オーケストレーション）インフラストラクチャースタック　ネットワーク／CNI(Container Networking Interface)、Rancher内部DNS インフラストラクチャースタック　kubernetes（etcd、kubelet、master、proxy、kubectld、dashboard）インフラストラクチャースタック　kubernetes-ingress（namespace毎のingress or service） k8s外部のシステム
Ingress of k8s on Rancher ・k8s外からアクセスするためにIngressでホストにポートをリッスンさせる・デフォルトでは80番ポートのため、ポートを変更する必要がある・実体としては、Rancher側でhaproxyが起動して連携している
（おさらい）SPEEDAの利用方法 Ingress経由で k8s外システムからアクセスここを詳細に拡大
k8s rancher rancher Pod:5000 backend rancher agent / network Node01（10.XX.XX.100）IP (haproxy) Ingress:30080 Pod:8080 front NameSpace FuncA (haproxy) Ingress:40080 NameSpace FuncB rancher agent / network Node02（10.XX.XX.200） k8s外部LoadBalancer Service:8080 front-svc Service:5000 backend-svc (haproxy) Ingress:30080 NameSpace FuncA (haproxy) Ingress:40080 NameSpace FuncB k8sスタック(kubelet、etcd、kube-api、ingress-controller等） Pod:5000 backend Pod:8080 front Service:8000 front-svc Service:4000 backend-svc Pod:5000 backend Pod:8080 front Service:8080 front-svc Service:5000 backend-svc Pod:5000 backend Pod:8080 front Service:8000 front-svc Service:4000 backend-svc Ingress (haproxy) 経由で k8s外部からアクセスポート変更 NameSpace で分離
k8s rancher rancher Pod:5000 backend rancher agent / network Node01（10.XX.XX.100）IP (haproxy) Ingress:30080 Pod:8080 front NameSpace FuncA (haproxy) Ingress:40080 NameSpace FuncB rancher agent / network Node02（10.XX.XX.200） k8s外部LoadBalancer Service:8080 front-svc Service:5000 backend-svc (haproxy) Ingress:30080 NameSpace FuncA (haproxy) Ingress:40080 NameSpace FuncB k8sスタック(kubelet、etcd、kube-api、ingress-controller等） Pod:5000 backend Pod:8080 front Service:8000 front-svc Service:4000 backend-svc Pod:5000 backend Pod:8080 front Service:8080 front-svc Service:5000 backend-svc Pod:5000 backend Pod:8080 front Service:8000 front-svc Service:4000 backend-svc kind: Ingress metadata: name: FuncA-ingress namespace: FuncA annotations: io.rancher.scheduler.global: “true” #全NodeでIngress起動 http.port: “30080” # 変更するポート spec: rules: - http: paths: - path: /web backend: serviceName: front-svc servicePort: 8080 - path: /v2/api backend: serviceName: backend-svc servicePort: 5000
k8s on Rancherまとめメリット・非常に簡単にk8sクラスタを構築できる・ユーザ管理／アクセス制限も可能注意点・etcdも展開されるので、ケアが必要
DevOps with k8s ・k8s環境でのＣＩ／ＣＤ・Blue／Greenデプロイ・苦労したところ
ローカル環境で開発 Push Pull ローカルPCのminikubeで高速に開発を回すことができる
Blue／Greenをバランサで切替開発k8sに e2eテスト環境をデプロイ自動テストを実行本番k8sの Blue環境にデプロイ kubectl ＋ Shell Script kubectl ＋ Shell Script
k8s rancher rancher Pod:5000 backend rancher agent / network Node01（10.XX.XX.100）IP (haproxy) Ingress:30080 Pod:8080 front NameSpace Blue (haproxy) Ingress:40080 NameSpace Green rancher agent / network Node02（10.XX.XX.200） k8s外部LoadBalancer Service:8080 front-svc Service:5000 backend-svc (haproxy) Ingress:30080 NameSpace Blue (haproxy) Ingress:40080 NameSpace Green k8sスタック(kubelet、etcd、kube-api、ingress-controller等） Pod:5000 backend Pod:8080 front Service:8000 front-svc Service:4000 backend-svc Pod:5000 backend Pod:8080 front Service:8080 front-svc Service:5000 backend-svc Pod:5000 backend Pod:8080 front Service:8000 front-svc Service:4000 backend-svc バランサで Blue/Greenの Ingressに切り替え NameSpace で分離
苦労したところ・プロキシが多い・k8sのアロケーション・シェルスクリプトが多い
プロキシが多い構成上プロキシが多段になるため、トラブルシュート時の切り分けに注意（例）Timeout設定を延ばしたが切断される外部LB 　　Ingress　　Kong　　　App 300sec 300sec 60sec 200sec timeout 504 Gateway Timeout
k8sのアロケーション開発環境のk8sでリソース逼迫しそうなノードにコンテナが配置されて、OOMKiller が発動　→コンテナ側でメモリ確保を設定した resources: requests: memory: XXGi
シェルスクリプトが多い kubectlを利用するため、用途毎に様々なシェルスクリプトが生まれた　・ビルド、テスト、デプロイ等で127個 ⇒envsubst でテンプレートから設定を生成するように、高機能・共通化した
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: hoge namespace: ${NAMESPACE} spec: replicas: 1 template: metadata: labels: name: hoge spec: containers: - name: hoge image: docker-registry.uzabase.com/hoge ports: - containerPort: 5555 テンプレート生成スクリプト（抜粋） configuration=".template.yml" # テンプレートから envsubst で環境変数を置き換えて、設定生成 cat ${template} | envsubst > "${configuration}" # 既存設定を削除 kubectl delete -f "${configuration}" || true # 設定反映 kubectl create -f "${configuration}" # 生成した設定を削除 rm -f "${configuration}" 設定をカスタマイズしつつ、 k8sの不要設定や不要ファイルを残さない
1. Backgrounds 2. Why Rancher 3. What’s Rancher 4. k8s on Rancher 5. DevOps with k8s 6. Monitoring k8s 7. Next Generation Table of Contents
Monitoring k8s 監視基盤としてPrometheusを採用　・ServiceDiscoveryできる　　・k8sで増減するコンテナに追従　・監視性能が高く、高頻度で収集できる　　・1台で800k処理（10秒間隔×1万）　・PromQLで柔軟にクエリが書ける
大まかな流れ・k8sにNamespace作成(metrics) ・k8sにNode-exporter、Prometheusをデプロイ・k8sの各ノードで収集・データ保存期間は24時間・k8s外のPrometheusからfederationで収集・Grafanaで表示・詳細は弊社テックブログを参照ください！　http://tech.uzabase.com/entry/2018/03/14/200512
Prometheus Monitoring構成 k8s cluster App pods node node node App pods App pods Node Exporter federation datasource PrometheusAlertmanager $ kubectl describe deployment prometheus --namespace=metrics Args: --config.file=/mnt/etc/prometheus.yml --storage.tsdb.retention=24h --web.external-url=$(EXTERNAL_URL)/prometheus
Alert example groups: - name: mem-usage.rules rules: - alert: NodeMemoryUsage expr: ( ( ( node_memory_MemTotal - node_memory_MemFree - node_memory_Cached ) / ( node_memory_MemTotal ) * 100)) > 85 for: 2m labels: severity: page annotations: DESCRIPTION: '{{$labels.instance}}: Memory usage is above 85% (current value is: {{ $value }})' SUMMARY: '{{$labels.instance}}: High memory usage detected' mem-usage.rules.yml
Istio導入・トラフィック調整しながらデプロイ　・Warm-up後にサービス投入・新機能のβリリースのみ振り分け　・特定Headerだけを別のサービスに送る・細やかなRBACでアクセス制御　・Namespace,Service,Pod,Method単位で制御
ROOK導入 Cephをストレージ仮想基盤としてk8sへ統合　・分散ストレージで可用性アップ　・データ量に合わせた柔軟でリニアな増強　・データソースもk8sにデプロイ可能
まとめ
k8s on Rancherの導入効果（Dev）リリース回数10倍！　1回/週 → 10回/週（Blue/Greenデプロイ）開発効率200%UP！　フルセットe2eテスト環境が簡単にデプロイできる　　・データソース(DB,ES,FileServer）　　・従来のAPサーバ（モノリシックな部分）　　・自動テスト環境(Gauge) 　　・外部サービスのダミーサーバ（API、FTP、Mail等）
k8s on Rancherの導入効果（SRE） k8s運用の知見が得られた　・監視環境の整備が進んだ（Prometheus,Grafana）　・コードで構成管理（Ansible＋kubectl）バッチ処理のk8sが進んだ　・従来はジョブスケジューラから、バッチ専用サーバで実行　　・k8sのCronJobに移行　　　・実行される環境を意識せず、定期処理を実行できる　　　・バッチ環境としての可用性もアップ
ありがとうございました

On-Premise Kubernetes on Rancher

Check these out next

On-Premise Kubernetes on Rancher

Recommended

More Related Content

Slideshows for you(20)

Similar to On-Premise Kubernetes on Rancher(20)

Recently uploaded(20)

On-Premise Kubernetes on Rancher