Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OSS X 勉強会 Kubernetes 特長と最新動向

Maho Takara
January 30, 2018

OSS X 勉強会 Kubernetes 特長と最新動向

Maho Takara

January 30, 2018
Tweet

More Decks by Maho Takara

Other Decks in Technology

Transcript

  1. Kubernetes 特長と最新動向
    IBM社員にも知って欲しいk8sの利用価値
    日本アイ・ビー・エム株式会社
    クラウド事業本部 高良 真穂
    2018年1月30日
    OSSユーザーのための勉強会 < OSS X Users Meeting >
    #22 Dockerとkubernetes
    https://www.scsk.jp/event/2018/20180130.html

    View Slide

  2. 高良 真穂 (たから まほ)
    日本アイ・ビー・エム株式会社
    クラウド事業本部
    Watson & Cloud Platform テクニカルセールス
    お話する人
    IBM社内のセールスからは IaaSのスペシャリストと見なされ事が多いのですが、
    本来はソリューションを考えるITアーキテクトなので、
    お客様にとっての価値を追い求めてフル・スタックで取り組んでいます。

    View Slide

  3. 今日はOSS勉強会ですから、
    IBMのPRは少なく
    Kubernetes について
    知識と利用価値の
    お話に努めたいと思います

    View Slide

  4. Kubernetes とは
    • Google で 自社のため開発されたコンテナ・クラスタ管理ソフト Borg をベースにOSS化
    • CNCFへ寄贈され、OSSプロジェクトとして、多数の企業が参加して推進中
    • Apacheライセンス 2.0のもと配布
    • 2014年7月7日に初版リリース、 現在の最新版が1.9 (2017/12/15 GA)
    • ソースコード https://github.com/kubernetes
    ベースとなったBorgは10年以上に渡って、自社のサービスをコンテナ
    で提供してきており、毎週10億以上のコンテナを起動しているとされ
    ています。
    ギリシャ語で「操縦士」や「パイロット」を表す
    Kubernetesのロゴ
    ネイティブ・スピーカの発音では、
    クーベネティス や クベルネティス
    みたいです。

    View Slide

  5. Kubernetes を一言で表現すると
    Kubernetesは、
    コンテナの運用自動化のために開発されたOSS
    主な機能
    • コンテナ化したアプリをクラスタ運用する
    • 稼働中にアプリの実行基盤をスケール(拡大または縮小)する
    • 新機能をサービスをロールアウト(無停止でリリース)する
    • CPUやメモリなどハードウェアの利用量を制限する
    • ログ収集、負荷分散、ジョブ、監視などの運用機能を提供
    特長
    • 可搬性:パブリック、オンプレミス、ハイブリッド・クラウド、マルチ・クラウドでの動作
    • 拡張性: モジュール化、追加/接続/構成が可能
    • 自己修復:再配置、再起動、複製、スケーリング、リリースを自律的に実行

    View Slide

  6. Kubernetes は長いので
    Kubernetes
    k8s
    1 2 3 4 5 6 7 8
    省略

    View Slide

  7. 階層の中でのKubernetesの概念的な位置づけ
    • DockerはSwarmとKubernetesの統合を発表 DockerCon EU 2017
    Physical Infrastructure
    Layer 1
    Virtual Infrastructure
    Layer 2
    Operating System
    Layer 3
    Container Engine
    Layer 4
    Orchestration/Scheduling
    Service Model
    Layer 5
    Development Workflow
    Layer 6
    Docker Swarm
    IBM Cloud
    Bare Metal Network Storage
    IBM
    Private
    Cloud

    View Slide

  8. Kubernetesのアーキテクチャ
    • https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/architecture.md

    View Slide

  9. 相模湖で悟ったKubernetesとDockerの関係 !?
    くじら丸(Docker) を操る操縦士(Kubernetes)
    津久井振興株式会社 振興ボード くじら丸
    http://sagamiko-boat.com/

    View Slide

  10. メガクラウド各社
    Kubernetes
    対応状況

    View Slide

  11. © IBM Corporation 11
    Kubernetesを
    広めて勢力図を
    変えるぞ
    OSSなら参道して
    シェアを取りに
    行くぞ!
    複合環境でも
    便利♪
    豊富な資金力で
    独走を維持するぞ
    ロックインから
    解放だ! チャンス♪

    View Slide

  12. Kubernetesが
    解決する課題

    View Slide

  13. Kubernetesが解決する課題
    1. コンテナを共通的な基盤で本番運用したい
    2. 短いサイクルでリリースを繰り返したい
    3. サーバー資源の無駄を減らし、効率を高めたい

    View Slide

  14. Kubernetesが解決する課題
    • コンテナを共通的な基盤で本番運用したい
    • docker-compose を利用したアプリ開発が定着、本番環境もコンテナでリリースしたい
    • 本番ではコンテナを再作成する事無く、DBの接続先を変えたい。
    • SWスタックを気にせずに、アプリが安定して動作する不変のプラットフォームが欲しい
    OSカーネル
    ライブラリ
    SWパッケージ
    ミドルウェア
    アプリケーション
    OSカーネル
    開発環境
    OSカーネル
    ライブラリ
    SWパッケージ
    ミドルウェア
    アプリケーション
    OSカーネル
    本番環境
    工場の生産ラインの様に
    自動化して連続的に
    ソフトウェアを生産する基盤
    コンテナ コンテナ
    テスト完了した
    コンテナを
    K8sの本番環境へ
    可用性&クラスタ
    スケーラビリティ
    モニタリング

    View Slide

  15. Kubernetesが解決する課題
    • 短いサイクルでアプリのリリースを繰り返し、継続的に改善を進めるこ
    とで、他社より優位に立ちたい
    • スマホアプリでユーザー数が多いので止められない。変更を無停止でリリースしたい。
    • リリース後に問題が発覚したら、前バージョンに無停止でロールバックしたい。
    • A/Bテストとして一部のユーザーだけにリリースして、利用者の反応を確かめたい。
    1~4
    週間
    毎日
    デイリー
    スクラム
    スプリント
    サイクル
    リリース
    バックログ
    TARGET
    Devices
    業務をシステム化で自動化したり
    、改革するものではなく
    あらゆるデバイスを対象に市場の
    ニーズを発見するため試行錯誤で
    洗練が最短パス
    アジャイル/スクラム
    に実行イメージ

    View Slide

  16. Kubernetesが解決する課題
    • コンピューティング資源の無駄を減らし、高効率な運用をしたい
    • 特定クラウドに縛られて、リスクを高め、技術者の存在価値を無くしたくない。
    • オンプレとクラウドを自在に使い分け良い処取りしたい。
    • アプリとサーバーの結合を減らし、理想的なアプリの稼働環境にしたい。
    A社クラウド
    仮想サーバ
    抽象化
    コンテナ化
    実現したい事に対して
    環境個別の事を
    考えなくても良い
    共通化された運用環境
    アプリが依存するSW
    パケージをOSごと
    一緒に持ち運べる
    安定の不変の実行環境
    B社クラウド
    仮想サーバ
    自社オンプレ
    プライベートクラウド
    ベアメタルサーバ

    View Slide

  17. ココを抑えれば
    もう怖くない
    Kubernetesの要点

    View Slide

  18. k8sの要点 k8sの三大構成要素
    K8sの3大構成要素は3つ
    • マスターノード k8sクラスタの制御 パブリック・クラウドの場合はマネージド
    • ワーカーノード アプリのコンテナの動作、ノード数可変
    • コンテナ・レジストリ コンテナ保管場所
    Master
    Node
    Worker
    Node
    Public
    Network
    クライアント
    Container
    Registry
    コンテナ
    イメージ登録
    クラスタ
    操作
    User
    IBM流では ワーカーノードと呼び
    k8sプロジェクトでは、単にノード

    View Slide

  19. k8sの要点 Docker, k8sクラスタ, クラウドの関係
    • 3系統のコマンドを利用して操作
    • dockerコマンド コンテナのビルド、レジストリへの登録&取出し
    • kubectlコマンド アプリのデプロイ、ロールアウト/ロールバック
    • gcloud/bluemixコマンド クラスタ構成、ノードの追加/変更/削除、FW/LB設定
    Master
    Node
    Worker
    Node
    Public
    Network
    Container
    Registry
    Services
    Cloud
    Service
    Storage
    Service
    Load Balancer Firewall
    k8sクラスタ制御
    kubectlコマンド
    User
    (オプション)
    Server
    Worker Nodeは
    仮想サーバーを
    ベースに構成される

    View Slide

  20. k8sの要点
    アプリのデプロイ
    サービスを開始するまでの作業は3ステップ
    1. アプリのコードを開発してコンテナ化
    2. コンテナをコンテナ・レジストリへ登録
    3. 3種のYAMLを利用してデプロイ
    • デプロイメント
    • レジストリのコンテナ・イメージの指定
    • 起動するコンテナ数の指定
    • サービス
    • クラスタIP作成
    • 公開用ロードバランサ
    プライベート
    レジストリ
    パブリック
    レジストリ
    コンテナを
    ダウンロード
    アプリ開発者
    サービス運用
    技術者

    View Slide

  21. k8sの要点 階層構造
    • Node - デプロイメント - ポッド - コンテナ の階層構造の上で、コンテナ化したアプリを運用
    • ポッドは複数のコンテナが動作でき、一つの内部IPアドレスを持つ、一つの仮想マシンの様な存在
    • しかし、ポッド単位で起動と破棄され、永続データは保持できない一時的な存在
    アプリ
    コンテナ
    ポッド
    デプロイメント
    Webサーバ
    コンテナ
    ポッド ポッド
    デプロイの基本単位
    クラスタ・ネットワーク上に
    IPアドレスを持つ
    実行単位
    dockerやrktなど
    コンテナ
    Worker
    Node
    Worker
    Node
    Worker
    Node
    Nodeに分散してデプロイ
    ポッドの
    レプリカによって
    高可用性構成
    ポッド数を維持
    その他資源との
    接続を制御
    コンテナ
    レジストリから
    取得したイメージ
    仮想サーバー
    ベアメタル

    View Slide

  22. • Podは、なんの短縮形?
    k8sうんちく

    View Slide

  23. k8sの要点 クラスタ内部ネットワーク
    • ポッドはクラスタ・ネットワークに、ポッドが接続され、Worker Nodeの境界を越えて通信できるノード横断ネット
    • しかし、ポッドのIPアドレスでは外側と通信はできない内部専用、ポッド作成ごとにIPアドレスを自動付与
    Node #1
    User Private VLAN
    User Public VLAN
    Node #2 Node #3
    Docker
    Container
    Pod 8c8lj
    Docker
    Container
    Pod dqbr2
    Docker
    Container
    Pod t7jfh
    クラスタ・ネットワーク
    Node IP:
    10.132.253.38
    Node IP:
    10.132.253.30
    Node IP:
    10.132.253.17
    Pod IP: 172.30.11.51 Pod IP: 172.30.180.147 Pod IP: 172.30.170.233
    ReplicaSet ID:
    7f868cb77d
    パブリックは
    IBM Cloudの実装で
    他社では異なる構造です

    View Slide

  24. k8sの要点 内部ロードバランサー
    • k8sは、ポッドのクラスタの代表IPを作り要求を分配するサービスを提供
    • kubectl コマンドからYAMLを投入して”サービス”を定義する
    • サービス作成時に、kube-dnsにサービス名を登録、クライアントからDNS名で参照可能
    • フロントエンドの接続先バックエンドは、YAMLの定義 “セレクタ”で指定
    Container
    express1:1.0
    ポッド
    Pod IP: 172.30.11.58
    ポッド
    Pod IP: 172.30.180.239
    ポッド
    Pod IP: 172.30.170.159
    Container
    ポッド
    Pod IP: 172.30.11.46
    アプリケーション(デプロイメント)
    クライアント
    (クラスタ内)
    クラスタの代表IP
    Cluster IP:
    172.21.127.174
    Port: 3000
    name: express-app-svc
    すべて、Cluster-NetworkのIPアドレスです。
    Container
    express1:1.0
    Container
    express1:1.0
    デプロイメント
    レプリカ数 3
    他のコンテナから要求
    をポッド分散する
    フロントエンド バックエンド
    サービス
    • ポッドは起動と破棄で再起
    動が無い
    • 起動時にIPアドレスが付与
    • 起動のたびにIPが変わる
    サービスが必須な理由

    View Slide

  25. • Kube-proxyはリクエストの振分け先を固定できるの? (答えはNo)
    k8sうんちく
    pod pod
    kube-proxy
    pod pod
    kube-proxy
    pod pod
    kube-proxy
    Worker Node #1 Worker Node #2 Worker Node #3
    リクエストはランダムにポッドへ割振られる
    PHPのアプリでセッションを維持するケースでは
    キャッシュやDBにセッション情報を保持する必要がある
    デフォルト kube-proxy mode: iptables のケース

    View Slide

  26. k8sの要点 外部公開ロードバランサー
    • k8sクラスタから外へ公開するロードバランサのサービスを提供
    • NodePort ノードのポート番号で公開、KubeProxyと連携して複数のポッドへアクセスを分配します
    • LoadBalancer クラウドプロバイダのロードバランサを使用して外部にサービスを公開
    • Ingress 各社クラウドの実装でロードバランサーとHTTPSなどの機能で公開
    ポッド
    外部向け代表IP
    Container
    nginx
    インターネット上 フロントエンド
    サービス
    ポッド
    Container
    nginx
    ポッド
    Container
    nginx
    バックエンド
    内部クラスタの代表IP
    Cluster IP:
    172.21.127.174
    Port: 3000
    name: express-app-svc
    サービス
    Container
    express1:1.0
    ポッド
    Pod IP: 172.30.11.58
    ポッド
    Pod IP: 172.30.180.239
    ポッド
    Pod IP: 172.30.170.159
    Container
    express1:1.0
    Container
    express1:1.0
    NodePort
    LoadBalancer
    Ingress
    SW名で例えば
    ウェブサーバ nginx
    アプリ PHP + FPM
    Redis, MySQLなど
    キャッシュやデータベース
    デプロイメント
    デプロイメント

    View Slide

  27. k8sの要点 オートスケール
    • CPUの使用率の閾値越えで、ポッド数を増加して処理能力を増強
    • 反対に閑散な状態となれば、ポッド数を縮小
    • ノードの増強は手動のケースありに注意、ノードは余裕をもって運用は必須
    デプロイメント
    Worker
    Node
    Worker
    Node
    Worker
    Node
    デプロイメント
    Worker
    Node
    Worker
    Node
    Worker
    Node
    ポッド ポッド
    ポッドのCPU使用率
    が閾値を超えると
    レプリカ数
    を増やして増強
    ポッド ポッド ポッド
    コンテナ コンテナ コンテナ コンテナ コンテナ
    追加

    View Slide

  28. k8sの要点 自己回復
    ノード障害に対して、サービスは無停止で継続可能
    • ワーカーノードの障害に対して、必要数のポッドを起動して処理能力を補う
    • N+1構成の様に能力的に余裕もった設計が必要であるが、ポッドの再配置は自動
    デプロイメント
    Worker
    Node
    Worker
    Node
    Worker
    Node
    デプロイメント
    Worker
    Node
    Worker
    Node
    Worker
    Node
    ポッド ポッド ポッド ポッド
    コンテナ コンテナ コンテナ コンテナ
    起動
    喪失
    障害
    停止
    障害
    停止

    View Slide

  29. k8sの要点 無停止ロールアウト (アプリ更新)
    • 無停止で安全にアプリケーションの更新(ロールアウト)を実行できる
    • ロールアウト 現行でサービスしているサービスの新バージョンをリリース
    • ロールオーバ 複数の更新を要求するケースで、無駄なステップを省く
    • ロールバック 何らかの理由でデプロイしたアプリを前のバージョンに戻す
    • スケール ポッドのCPU使用率の閾値超えでレプリカの数を増加
    終了中 終了中
    終了中
    終了中
    起動中
    起動中
    本番中
    起動中
    本番中
    本番中
    本番中
    本番中
    本番中
    本番中
    終了中
    終了中
    本番中
    本番中
    本番中
    本番中
    本番中
    時間の流れ
    ポッド
    レプリカ数
    アプリv1からアプリv2へ
    ロールアウトする時の
    k8sクラスタ内の動き
    本番中のポッド数2個をキープしながら切替を進行
    アプリ
    Ver 1.0
    のポッド
    アプリ
    Ver 2.0
    のポッド
    ポッドの中にコンテナの
    セットが格納されます

    View Slide

  30. k8sに関する資料を読むと、稼働中のコンテナを更新する意味で、Rolling update と
    書いてあることが多いのですが、Rolloutは間違いではありませんか?
    • Rolling update (ローリング・アップデート)
    • ReplicationControllerとPodで更新を実行しますが、現在は Deployment の利用が推奨されています。
    • kubectl rolling update
    • Rollout (ロールアウト)
    • Deploymentは現在推奨される方法で、ローリング・アップデートが完了した後でも、以前のリビジョ
    ンへ、ロールバックできるなどの優れた機能があります。
    • kubectl apply –f deploy.yaml
    • kubectl rollout status
    k8sうんちく
    おすすめ
    (kubectl rolloutコマンドは無い)
    https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
    https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/

    View Slide

  31. k8sの要点 永続ストレージの利用
    • K8sのコンテナ環境ではデータをストレージに永続的に保管できます。
    • クラウド・プロバイダのストレージ・サービスを利用できます。
    • YAMLファイルに、”kind: PersistentVolume” や “kind: PersistentVolumeClaim” とすることで、既存
    ボリュームをマッピングしたり、新規に作成するなどの永続ストレージの利用ができます。
    • クラウド・プロバイダや既存ストレージ系プロトコルのための複数のプラグインが提供されています。
    Master
    Node Worker
    Node
    Cloud
    Service API
    Storage
    Service
    ポッド
    Worker
    Node
    DBサービス
    コンテナ
    ポッド
    k8sクラスタ制御
    kubectlコマンド
    User
    参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes
    DBサービス
    コンテナ

    View Slide

  32. k8sの要点 名前空間を利用したクラスタの区分利用
    • ネームスペースを利用して、無停止で大幅なシステム更改ができます。
    • 従来では無停止切替のために、同じ処理能力の環境を構築して、スイッチしていた。
    • K8sはクラスタ内をネームスペースで分割できるので、無停止切替のコストや工数を大幅に削減
    • アプリの更新だけであれば、ロールアウト/ロールバック機能を利用して安全に無停止切替
    Worker
    Node
    Worker
    Node
    Worker
    Node
    仮想
    サーバ
    仮想
    サーバ
    (仮想サーバ) (仮想サーバ) (仮想サーバ)
    本番機
    Aグループ
    本番機
    Bグループ
    仮想化 Hypervisor
    ロード
    バランサ
    スイッチ
    スイッチ
    Name Space : Blue Name Space : Green
    従来の
    無停止切替
    k8sの
    無停止切替
    リクエスト
    リクエスト
    ワーカーノードの一時的な増強、ポッドの片寄せ可能

    View Slide

  33. k8sの要点 外部資源の名前空間別の割当て
    • IBM Cloud の マネージドDBサービスやWatson APIサービスを利用する場合
    • コンテナのレベルでは、環境変数として、接続先や認証情報を提供(起動順序制約あり)
    • ポッドのレベルでは、ボリュームとして接続先情報が読み取り可能
    • k8sクラスタの外にあるサービスを利用する場合
    • External サービスを定義することで、DNSでアドレス解決が可能
    Worker
    Node
    Worker
    Node
    Worker
    Node
    (仮想サーバ) (仮想サーバ) (仮想サーバ)
    スイッチ
    Name Space : Blue Name Space : Green
    リクエスト
    新環境用外部サービス
    Watson API
    インスタンス
    マネージド
    データベース
    インスタンス
    Watson API
    インスタンス
    マネージド
    データベース
    インスタンス
    Bare metal
    Server
    GP-GPU Optane
    外部
    リソース
    現用外部サービス
    Bare metal
    Server
    GP-GPU Optane
    外部
    リソース
    アプリコードと
    外部サービスの
    対応を
    名前空間で変更

    View Slide

  34. • ダウンタイムを最小にする技術
    k8sうんちく
    https://martinfowler.com/bliki/BlueGreenDeployment.html
    ソフトウェアをテストの最終段階からプロダクションへともって
    いくカットオーバーそれ自体にある。
    通常はこの作業を迅速に行うことで、ダウンタイムを最小化しな
    ければならない。blue-green deploymentはこれを、可能な限り同
    じにした2つの本番環境によって確実に行うようにしている。
    http://www.publickey1.jp/blog/14/blue-green_deployment.html
    Blue-Greenデプロイ
    https://martinfowler.com/bliki/CanaryRelease.html
    カナリア・リリース
    https://www.asahi.com/articles/ASK3Q4DBZK3QUZOB004.html
    サリン事件
    カナリアを
    手にする
    捜査員
    一部にリリースして様子を確認しながら段階的に範
    囲を拡大するリリース手法で、変更に伴う様々なリ
    スクを軽減する。
    流量の割合で決める方法、クライアントの種類で限
    定する方法など、目的に沿った使い分けがある。
    鳥は効率良く酸素を吸収
    できるので、微量な
    毒ガスでも敏感に反応する

    View Slide

  35. k8sの要点 ジョブ
    • Kubernetes はスケジューラとも呼ばれるが、ジョブネットは書けない。
    • YAMLで定義してバッチ処理を実行
    • K8sはスケジューラーと言われるが、ジョブ・スケジューラの様なジョブネットは作れない
    • ジョブのタイプ
    • 一個のポッドで順次に業務ステップを実行するバッチはポッド内で動くシェルで実現
    • 並列度を大きくして、一度に複数のポッドで並列処理はYAMLで定義
    • でもMPIの様なタイプには不向き
    • ジョブの終了
    • シェルやコマンドが終了コード0以外は異常終了とみなす
    • 異常終了時の取り扱いは選択できる
    • 成功するまで繰り返す
    • どれか一個でも成功したら成功として完了する
    • 指定回数だけリトライして、閾値を超えたら失敗とする
    • ポッドが終了後もジョブは残り続けログを保持し参照できる。
    • リトライのタイプ
    • 失敗したポッドを破棄して、ポッドを作成する方法
    • ポッドは維持しながら、コンテナだけを再実行する方法

    View Slide

  36. k8sの要点
    分散環境のモニタリングと洞察
    • 大量のポッドを運用するには、モニタリングが課題
    • 二つのレベルの監視
    • アプリケーション・レベル
    • Kubernetes クラスタ・レベル
    時系列データベース
    可視化ツール
    全文検索エンジン
    通知ツール
    アプリケーション
    Node
    Cloud
    Master
    Node / Deployment / Pod / Service
    情報発生源
    監視対象
    メトリクス・コレクタ
    把握&洞察
    発報
    コンテナ・クラスタ監視
    基本的アーキテクチャ

    View Slide

  37. k8sの要点 分散環境のモニタリングと洞察
    • 主流となっている分散システムのモニタリング・ツール
    telegraf
    Diamond
    Python-daemon
    influxdb-python
    mtail
    node_exporter
    opentsdb-goclient
    td-agent
    リアルに近い
    モニタリング
    ログ分析
    と監視
    時系列データベース
    メトリクス・コレクタ 可視化ツール
    可視化ツール
    全文検索エンジン
    情報
    発生源

    View Slide

  38. • KibanaとGrafanaはブラウザで閲覧する視覚化ツール
    k8sうんちく
    Kibana Grafana
    ・Elasticsearchの視覚化ツール
    ・ログ分析など、対話的に操作しながらの発見に向く
    ・豊かな表現形式に対応
    ・時系列DB (time series database)の視覚化ツール
    influxDB, Prometheus, Graphiteなどの時系列データを視覚化
    ・設定を保存して繰り返し利用するダッシュボードに向く
    ・シンプルな操作
    特徴 特徴

    View Slide

  39. k8sの要点 分散環境のモニタリングと洞察
    • k8sクラスタ・レベルのモニタリング
    リアルに近い
    モニタリング
    ログ分析
    と監視
    時系列データベース
    メトリクス・コレクタ
    可視化ツール
    可視化ツール
    全文検索エンジン
    Master
    Node
    Worker Node
    Heapster
    kubelet
    cAdvisor
    kubelet
    cAdvisor
    kube-state-metrics

    View Slide

  40. k8sの要点 分散環境のモニタリングと洞察
    • Kubernetesのアプリケーション・レベルのモニタリング
    アプリ
    コンテナ
    ポッド
    デプロイメント
    コレクタ用
    コンテナ
    Worker
    Node
    Worker
    Node
    Worker
    Node
    リアルに近い
    モニタリング
    ログ分析
    と監視
    時系列データベース
    可視化ツール
    可視化ツール
    全文検索エンジン
    共有ボリューム
    Sidecar
    ✓ 監視項目を収集して転送するためのコン
    テナを同一ポッド上で稼働させる
    ✓ このコンテナはサイドカーと呼ばれる
    レプリカセット

    View Slide

  41. k8sの要点 分散環境のモニタリングと洞察
    Web UI (Dashboard)
    • K8sクラスタ状態を把握
    • 異常停止のポッド発見
    • 名前空間
    • CPU,RAM利用状態
    • クラスタ状態
    • デプロイメント
    • ポッド/レプリカ
    • サービス
    • ジョブ
    • ストレージなど
    • 全クラウドで共通なユーザーI/F
    • GCP/AWS/Azure/IBM

    View Slide

  42. k8sの要点 PCで動作するミニ環境 minikube
    Minikubeは、ローカル環境で動作するKubernetesクラスタ
    Kubernetesプロジェクトの元で提供され、最新バージョン
    https://github.com/kubernetes/minikube
    動作要件
    • kubectlコマンド
    • Operating System
    • macOS
    Hyperkit driver, xhyve driver, VirtualBox, or VMware Fusion
    • Linux
    VirtualBox or KVM
    • Windows
    VirtualBox or Hyper-V
    • VT-x/AMD-v virtualization must be enabled in BIOS
    • Internet connection on first run
    1Nodeのクラスタを作成
    学習、検証、開発、実験などに利用できる
    minikube のロゴ
    Minikube uses libmachine for provisioning
    VMs, and localkube (originally written and
    donated to this project by Redspread) for
    running the cluster.

    View Slide

  43. まとめ

    View Slide

  44. まとめ
    • Kubernetes は、
    • コンテナ・オーケストレーションのOSS
    • CNCFがプロジェクト運営
    • 2017年 メガ・クラウド各社がKubernetesに対応
    • 様々なOSSツールと組み合わせて高効率運用を実現できる
    • 解決する課題
    • コンテナ本番環境、クラスタ化、冗長化、オートスケール
    • クラウド各社&オンプレで共通オペレーション、IT基盤を抽象化して共通化
    • アプリ無停止のロールアウト&ロールバックを提供
    • CD/CI、DevOpsの実践環境
    • モノシリックなアプリでも、コンテナ化することで、k8sの価値に与れる

    View Slide

  45. 本講演および資料は、セッション発表者によって準備され、独自の見解を反映したものです。それらは情報提供の目的のみで提供されてお
    り、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。
    本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にか
    かわらずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかな
    る損害が生じた場合も、IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセ
    ンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条
    項を変更することを意図したものでもなく、またそのような結果を生むものでもありません。
    本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であ
    ることを暗示するものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づい
    てIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約するこ
    とを意図したものではありません。本講演資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、または
    その他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。 パフォーマ
    ンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスルー
    プットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処
    理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているも
    のと同様の結果を得られると確約するものではありません。
    記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例と
    して示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。
    IBM、IBM ロゴ、ibm.com、 Bluemix、およびIBM Watsonは、世界の多くの国で登録されたInternational Business Machines Corporationの
    商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストにつ
    いては、www.ibm.com/legal/copytrade.shtmlをご覧ください。
    おことわり

    View Slide