Oracle Code Tokyo19 k8s Operator

Copyright © 2019, Oracle and/or its affiliates. All rights reserved.
| Kubernetesで実現する運用自動化の新しいアプローチとは日本オラクル株式会社ソリューション・エンジニアリング統括セールスコンサルタント May 17, 2019 茂こと @cotoc88 #codetokyo19B2 B-2-2

| 本日のキーワード： Kubernetes Operator Kubernetesを拡張し、システムの運用自動化を実現するソフトウェア 2

| システムに求められることイントロダクション 3

| システムに求められること • ビジネスにもとめられる進化のスピードと品質 ✓サービスの早期リリース ✓市場の動向/反応を早期フィードバックして対応 ✓サービス停止による機会損失をなくす • システムは変化するビジネス要件に短い時間で対応（リリース）できることが求められるように ✓アプリの変更をすぐに本番環境に適用 ✓変化を許容できるシステムを構築 ✓停止時間の短縮と運用作業の効率化 4 社内業務の効率化から新ビジネスの創造へ

| システム開発のライフサイクル 5 ビジネスのスピードに合わせて、頻繁にライフサイクルを回す要件・計画開発運用・保守

| システム開発フェーズで求められること 6 アプリ開発・リリースサイクルの短縮・アプリ品質の向上 CI/CD - テスト、ビルドの自動化 - プロビジョニングの自動化基盤構築・環境構築時間の短縮・構築した基盤の品質向上 Infrastructure as code - 自動化 - イミュータブル求められること実現方法

| システム運用・保守フェーズで求められること 7 運用・性能と可用性の維持・運用品質のキープ運用タスクの自動化 - 稼働中の構成変更・維持保守・リリースリスクの低減 Blue Greenデプロイメントカナリアリリース求められること実現方法

| コンテナ/コンテナ・オーケストレーター • コンテナ – アプリケーションの実行環境をコンテナとしてパッケージ化 – アプリケーションが安定して稼働する環境を、高速かつ簡単に構築できる ✓環境構築に必要な情報をコードとして管理できるので、いつでも同じ環境ができる（イミュータブル） ✓自動化されたリリースサイクルの構築、実践が可能（CI/CD） • コンテナ・オーケストレーター – 大量のコンテナの管理を自動化し、停止時間の短縮や運用作業の効率化が可能 ✓クラスターに配備する要素を全てコードによって定義（イミュータブル） ✓スケーリング、自動復旧など、構成変更、維持を自動化（運用自動化） 8 より効率的な実現が可能に

| Kubernetes コンテナ・オーケストレーター 9

| Kubernetesとは • コンテナ・オーケストレーターとは複数コンテナを自動管理するプラットフォーム大量のコンテナを管理・運用を自動化するコンテナ・オーケストレーター 10 –リソースの抽象化自動分散配置 –手動／自動でスケーリング –複数コンテナをまとめて制御 –障害時のコンテナ再立ち上げ –クラスター内／外のネットワークアクセスの管理

| Kubernetesの宣言的オペレーション • クラスターに配備する要素を全てmanifestファイル（＝コード）によって定義 – 環境構成の変更内容をバージョン管理し、追跡可能にする – 運用オペレーションはコードの変更によって実施し、作業を簡素化する – 複数Kubernetesクラスターでの相互運用を実現する 11 Kubernetesクラスター manifestファイル ✓ アプリ x 3 ✓ データストア x 2 ✓ ネットワークはアプリ→ データストアを許可 ✓ …etc Kubernetesに適用アプリケーションが動作するコンテナデータストアが動作するコンテナ

| Kubernetesの操作 • Kubernetesの操作はkubectlコマンドラインツールを使用 • kubectlはAPI Server経由でetcdの操作を行う – etcd：Kubernetesのデータが保存される高信頼性データベース – API Server：etcdへの読み込み、書き込みを行うAPIサーバー 12 Kubernetesクラスター >_ kubectl（コマンドラインツール） etcd API Server Pod Container

| Kubernetes上でコンテナが動作する様子 • Kubernetesでコンテナが動作する最も基本的な構成 – Pod / Container – Deployment / Deployment Controller 13 Dc Deployment Controller etcd API Server D Deployment Pod Container >_

| Kubernetes上でコンテナが動作する様子 • Pod: – 複数のコンテナを束ねる単位（下の図ではひとつのPodにひとつのコンテナ） • Container: – コンテナそのもの。アプリケーションのワークロードの実態 14 Dc Deployment Controller etcd API Server D Deployment Pod Container >_

| Kubernetes上でコンテナが動作する様子 • Deployment: – Podの状態（レプリカ数、コンテナイメージなど）を定義するデータ kubectlから投入する • Deployment Controller: – Deploymentの内容に合うようにPodの状態を制御するプロセス 15 Dc Deployment Controller etcd API Server D Deployment Pod Container >_

| KubernetesのController Observe Analyze Act 16 ControllerはReconciliation Loop（突き合わせループ）により宣言した状態を維持するアプリケーションの現在の状態を確認するアプリケーションの現在の状態と期待する状態を比較する状態を一致させるために必要な処理を行う

| Kubernetes上でコンテナが作成されるまでの流れ 1. Deploymentマニフェストの適用 2. Deployment が作成される 3. Deployment Controllerが検知して、Podが作成される 17 Dc Deployment Controller etcd API Server D Deployment Pod Container >_ manifest アプリ x 3 をたてたい！

| Kubernetesとは • コンテナ・オーケストレーターとは複数コンテナを自動管理するプラットフォーム • ・・・・でも大量のコンテナを管理・運用を自動化するコンテナ・オーケストレーター –リソースの抽象化自動分散配置 –手動／自動でスケーリング –複数コンテナをまとめて制御 –障害時のコンテナ再立ち上げ –クラスター内／外のネットワークアクセスの管理エンタープライズシステムの運用自動化のために機能は足りている？ 18

| Kubernetesの標準機能だけでは実現できないこと • コンテナで動作するソフトウェアが状態やデータをもつような場合には手作業で運用タスクを行う必要がある – ミドルウェアのクラスタリングを構成 – バックアップ・リストア – 異なる設定をもつPod毎の障害復旧 19 • 例：データベース – マスター・スレーブ構成のDBをスケールアウトするときにはリードレプリカとして設定した上で立ち上げなければならない – バックアップ・リストアにはデータベース固有の操作が必要 • 例：アプリケーション・サーバー – クラスターには、役割の異なるクラスターメンバーが存在（管理サーバー/管理対象サーバー）それぞれ適切なオペレーションを行う必要がある ? ? ? ?

| Kubernetes Operatorとは • Kubernetes上に展開してソフトウェア固有の運用タスクを自動実行するソフトウェアをKubernetes Operatorと呼ぶ – Operatorはサードパーティやユーザーが実装し、Podとしてクラスターに配備する – インスタンス生成／設定／管理を運用管理者に代わって行う運用知識をソフトウェアに入れみ、運用管理者の代わりに動作 Op Operator 21 SRE

| Kubernetes Operatorの仕組み Operatorは以下のコンポーネントから成り立つ • Custom Resource – ユーザーが独自に定義したリソース – Custom Resource Definition（CRD）はKubernetes APIを拡張する（APIを拡張することでCustom Resourceが取り扱える状態） • Custom Controller – ユーザーが独自に作成するコントローラー • Custom Resourceの内容をKubernetesに作成する Operatorを作成するためのSDKが提供されている（Operator Framework） 22 独自に設定した定義とコントローラーから成り立つ https://github.com/operator-framework/operator-sdk

| Kubernetes Operatorの一般的な動作イメージ • 1. マニフェストの適用（Custom Resource） • 2. Operatorが検知して、Kubernetesのリソースを作成する • 3. リソースのControllerが検知して、オブジェクトが作成される D Operator etcd C Custom Resource Pod Container O D API Server >_ manifest 23

| 様々なソフトウェアでKubernetes Operatorの開発が進む • Kubernetes OperatorはCoreOS社(現Red Hat社)によって2016年に提唱された • KubeCon + CloudNativeCon North America 2018 ではキーノートや様々なセッションで繰り返し登場するなど、注目度があがっている 24 • etcd • Elasticsearch • Envoy • Istio • Kafka • Redis • Memchched • MongoDB • PostgreSQL • MySQL • Tomcat • WebLogic Server • Tensorflow • Rook • Prometheus • Jaeger And more… Kubernetes Operator in the Wild（2019/5 現在 96サービス登録） https://github.com/operator-framework/awesome-operatorsから抜粋

| OracleがGitHubで公開しているOperator 25 MySQL Operator WebLogic Server Operator https://github.com/oracle/weblogic-kubernetes-operator https://github.com/oracle/mysql-operator

| MySQL Operator 26

| MySQL Operator • 2018年前半にリリース • 現在(2019/05) Ver.0.3.0 アルファ版 – MySQL 8.0 対応、Enterprise Edition 対応 • 提供する運用自動化機能 – 単一コマンドでKubernetes上にMySQL InnoDB Clusterを作成/スケール/削除可能 – MySQL InnoDB Clusterの自己修復（自動障害検出、自動回復） – データのバックアップ（オンデマンド、スケジューリング）及び復元 27 Kubernetes上のMySQL InnoDB Clusterの運用を自動化 https://github.com/oracle/mysql-operator

| MySQL InnoDB Clusterとは？ • 特徴 – MySQLネイティブの高可用性構成を構築可能(クラスタリングソフト等は不要) – DBレイヤーのフェイルオーバーだけでなく、アプリ接続先まで自動フェイルオーバー可能 – デフォルトはシングルプライマリーモードだが、マルチプライマリーモードでの動作も可能 • シングルプライマリーモード：1台のサーバーのみが更新処理可能、残りのサーバーは読み取り専用 – プライマリノードに障害発生時は、自動的に別のインスタンスが新プライマリに昇格 • マルチプライマリーモード：全台で更新処理可能 – MySQL側でのフェイルオーバー処理が不要になる 28 エンタープライズシステムで使用されるMySQLの高可用性フレームワーク https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-userguide.html

| MySQL InnoDB Clusterアーキテクチャー MySQLの高可用性機能自動フェールオーバー & リカバリ、矛盾検知 M M M MySQL Connector Application MySQL Router MySQL Connector Application MySQL Router MySQL Shell HA Group Replication アプリケーションはMySQL Routerに接続 Group Replicationによる高可用性グループとメタデータの管理 MySQL Shellで設定管理が可能 +-------------------------------+ | Database | +-------------------------------+ | information_schema | | mysql | | mysql_innodb_cluster_metadata | | performance_schema | | sys | +-------------------------------+ mysql_innodb_cluster_metadata.* performance_schema.replication_group_members performance_schema.replication_group_member_stats 29

| MySQL OperatorによるMySQL InnoDB Clusterの管理 MySQL Operator Op M M M Group Replication (Single or Multi Primary) Load Balancer etcd API Server CR Custom Resource Application （Container） MySQL Router （Container） Request MySQL （Container） >_ manifest 30

| 1コマンドで簡単にMySQL Operatorをインストール可能・・ RESOURCES: ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE mysql-operator-65475db5-8292w 0/1 ContainerCreating 0 1s ==> v1/ServiceAccount NAME SECRETS AGE mysql-agent 1 2s mysql-operator 1 2s ==> v1beta1/ClusterRole NAME AGE mysql-agent 2s mysql-operator 2s ==> v1beta1/ClusterRoleBinding NAME AGE mysql-agent 1s mysql-operator 1s ==> v1beta1/CustomResourceDefinition NAME AGE mysqlbackups.mysql.oracle.com 2s mysqlbackupschedules.mysql.oracle.com 2s mysqlclusters.mysql.oracle.com 2s mysqlrestores.mysql.oracle.com 2s ==> v1beta1/Deployment NAME READY UP-TO-DATE AVAILABLE AGE mysql-operator 1/1 1 0 1s 31 $ helm install--name mysql-operator mysql-operator

| MySQL InnoDB Clusterの作成 32 multi-master-cluster.yaml $ kubectl apply -f multi-master-cluster.yaml cluster.mysql.oracle.com/mysql created $ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-0 2/2 Running 0 119s mysql-1 2/2 Running 0 82s mysql-2 2/2 Running 0 35s kind: Cluster metadata: name: mysql spec: multiMaster: true members: 3 ※Clusterリソースを作成すると下位リースに StatefulSet、Headless service が作成されるデータを保持するボリュームは Kubernetes の Storage リソース（Persistent Volume等）を別途定義する Clusterリソースには Persistent Volume Claim、StorageClass または volumeClaimTemplate を定義可能詳しい方への捕捉

| WebLogic Server Operator 33

| WebLogic Server Kubernetes Operator • 2018年5月にバージョン 1.0 をリリース – 現在最新バージョン 2.1、 2.0.1～ OpenShift 対応 • WebLogicドメインを表現するCustomer Resourceを監視し、その記述に合うようにWebLogic Server固有の管理タスクを実行する WebLogic ServerのKubernetes上での運用を自動化するためのOperator Wo WebLogic Operator etcd API Server Do Domain WebLogic Cluster Admin Server Managed Server 34

| • 高いサービスレベル – アプリケーションの無停止更新 – アプリケーション機能全域に渡る冗長化とフェイルオーバー – 処理の優先順位や流量の制御 • 充実した運用・管理機能 – 自動チューニング – 詳細なプロファイリングデータの常時収集 – 管理ダッシュボードやツール群を標準装備 35 • Oracle DBとの親和性 – RACとの連携による、DB障害時の高速フェイルオーバー – DBインスタンスの稼働状況に応じた動的負荷分散 Oracle WebLogic Server エンタプライズの要求に応える、Java EEアプリケーション・サーバー

| • 可用性 – アプリケーションフェイルオーバーやサービス移行によるサービス継続 • 拡張性 – 新規ノードの追加による処理能力の向上 36 • 管理性 – クラスタ・グループに対する一括管理 WebLogic Serverクラスタ機能クラスタリングによる可用性・拡張性・管理性の向上 WebLogic ドメイン Cluster Managed Server Managed Server Managed Server Web Server Proxy Plug-in フェイルオーバー WebLogic ドメイン Clueter Managed Server Managed Server Managed Server Web Server Proxy Plug-in ノード追加 WebLogic ドメイン Cluster Managed Server Managed Server Managed Server アプリケーションパッチ Admin Server

| WebLogic Server Kubernetes Operatorが提供する機能 • WebLogic Server Podの障害時自動復旧 • Kubernetesの構成を考慮して高可用性構成を自動で構築 • WebLogicクラスターの自動スケーリング • Prometheus/Grafanaによるモニタリング • Elasticsearch/Kibanaを用いた、WebLogic ServerおよびOperator自身のログ分析 • Kubernetesリソース、カスタム・リソース（Domainオブジェクト）の作成を支援するスクリプトの提供（…他多数） 37 Kubernetesの能力を活かすことで高可用性と高度な運用を実現

| 詳細なドキュメントが作成されている 38 https://oracle.github.io/weblogic-kubernetes-operator/

| 1コマンドで簡単にWebLogic Operatorをインストール可能 39 ・・・ RESOURCES: ==> v1/ClusterRole NAME AGE default-weblogic-operator-clusterrole-domain-admin 3s default-weblogic-operator-clusterrole-general 3s default-weblogic-operator-clusterrole-namespace 3s default-weblogic-operator-clusterrole-nonresource 3s default-weblogic-operator-clusterrole-operator-admin 3s ==> v1/ClusterRoleBinding ・・・（略） ==> v1/ConfigMap NAME DATA AGE weblogic-operator-cm 2 3s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE weblogic-operator-8569c6cb4f-fwwfs 1/1 Running 0 2s ==> v1/Role NAME AGE weblogic-operator-role 3s ==> v1/RoleBinding NAME AGE weblogic-operator-rolebinding 3s weblogic-operator-rolebinding-namespace 3s ==> v1/Secret NAME TYPE DATA AGE weblogic-operator-secrets Opaque 0 4s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE internal-weblogic-operator-svc ClusterIP 10.96.46.40 <none> 8082/TCP 2s ==> v1beta1/Deployment NAME READY UP-TO-DATE AVAILABLE AGE weblogic-operator 1/1 1 1 2s $ helm install weblogic-operator/weblogic-operator --name weblogic-operator

| WebLogic Server Podの障害時自動復旧 • WebLogic OperatorはDomainカスタムリソースに定義された構成を常に維持しようとする • 障害等でPodが減少すると、それを検知して自動再作成を行う – Operatorが障害を検知、Podをステートを持った状態で立ち上げ 40 オペレーション不要でコンテナ障害時から自動復旧 WebLogic Operator Managed Server W Admin Server WebLogic Cluster etcd API Server D Domain keep Pod x 2の状態を維持

| メトリック収集 WebLogic Serverクラスタの自動スケーリング • Prometheusアラートアクションを使用した自動スケーリング – PrometheusがWebLogic Serverのメトリックデータ（MBean）を監視し、指定した条件を超えた場合にスケーリングする 41 運用・管理コストの削減／可用性の向上 WebLogic Operator Managed Server W Prometheus Admin Server webhook Server Prometheus Alert manger Pa WebLogic Cluster new WebLogic Monitoring Exporter

| Demo WebLogic Serverクラスタの動的スケールアウト 42

| CERN（欧州原子核研究機構）で検証利用されている 43

| まとめ 44

| まとめ • KubernetesとOperatorの併用により、アプリケーションまで含めた運用の自動化を実現することができる – Kubernetesの登場により、大量のコンテナの管理を自動化し、停止時間の短縮や運用作業の効率化が可能 – OperatorはKubernetesの標準機能だけでは実現できないソフトウェア固有の運用作業 (バックアップ・リストア、クラスタの作成等) を自動化するソフトウェアエンタープライズシステムを運用自動化し、ビジネスに求められるスピード、品質を実現する 45

| 47

| Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, timing, and pricing of any features or functionality described for Oracle’s products may change and remains at the sole discretion of Oracle Corporation. 48

Oracle Code Tokyo19 k8s Operator

Oracle Code Tokyo19 k8s Operator

More Decks by cotoc

Other Decks in Technology

Featured

Transcript