简要概述

容器本地化日@Oracle云计算日研讨会系列
3/8@Oracle青山
日本的Oracle云计算日
容器本地化日

Kubernetes以及相关技术的最新发展趋势和未来展望

• twitter@hhiroshell

 

• 歴史１　Docker登場

Dockerがもたらしたもの

優れた開発者エクスペリエンス
Immutable Infrastructure

可搬性・再利用性
同等の環境を、簡単に構築

Docker登場当時のユースケース

ローカル環境開発
テスト環境
CI/CDツール

歴史２　コンテナ・オーケストレーション

課題

様々な運用・管理のオペレーションを大量のコンテナに対して行う必要がある
プロダクション規模のコンテナ群を扱うには、物理サーバや従来型仮想化の運用方法では対応できない

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

複数コンテナのデプロイ・スケーリング等を自動管理するプラットフォーム
Kubernetesがデファクトになりつつある

Kubernetesは他と何が違うか

機能の拡張が柔軟に可能。様々な用途に適用できる

運用効率化

詳細なメトリック監視と可視化
コンテナのログの転送収集
ネットワークトラフィックの制御

適用領域の拡大

機械学習プラットフォーム
分散ストレージ
分散型データベース

OSSのエコシステム確立

本格的な宣言的オペレーションとInfrastructure as Codeを実現可能

クラスタ上にデプロイするシステムの構成をコードによって定義

manifestファイル(yaml)をKubernetesに適用することで可能

2016 Kubernetes/Cloud Native元年

GoogleによるBorgの論文発表
Kubernetes　V1.0
Cloud Native Computing Foundation(CNCF),Open Container Project(OCP)発足

OCPは現在のOpen Container Initiative(OCI)

CNCFがサポートするプロジェクト　－　ほとんどの技術領域がOSSでカバーされる

2017 Kubernetesがデファクト確立

DockerがKubernetesサポート

2018 Cloud Nativeのキャズム越え

主要クラウドベンダーのManaged Kubernetes Serviceが出そろう
Operatorによる運用自動化のアプローチが知られるように
Prometheus
Grafana
IstioとEnvoy　サービスメッシュの実装のひとつ

マイクロサービス間の通信の問題を解決

Operator

運用管理者の業務をソフトウェア・エンジニアリングに置き換える

ソフトウェア固有の考慮事項を含めて運用タスクを自動実行するツール
運用管理者の業務の一部がOperatorの実装、メンテナンス作業に置き換わる

KubernetesとCloud Nativeスタックがもたらした変化

新たなITシステム開発のパラダイム

Kubernetesを中心としたOSSのエコシステムの成立
DevOpsカルチャーの発展

Cloud Nativeの今後

OperatorHub　ー　Operatorの運用をより一般的に

新たな課題

人員不足　エンジニアの不足
複雑なCloud Nativeスタック　運用管理の複雑化

OKE和Oracle容器平台

• ペースレイヤーモデル

新しいビジネスに対応するにはアプリケーションを高頻度で更新する必要がある

高頻度リリースを実現するための開発トレンド

マイクロサービス・アーキテクチャ
継続的インテグレーション、デリバリー

コンテナが注目を浴びているのはなぜ？

コンテナにより、小容量、低オーバーヘッドの仮想的環境を実現

多数のサービスを稼働させるマイクロサービスにコンテナが適する

アプリケーションの実行環境をコンテナとしてパッケージ化　CI/CDに寄与

より円滑に、自動化されたリリースサイクルの構築、実践が可能

Kubernetes利用環境の全体像

大きく分けてKubernetesクラスタ、kubectl、コンテナレジストリで構成

OracleマネージドKubernetesサービス

Oracle Container Engine for Kubernetes(OKE)

マネージドKubernetesとしての基本をしっかりカバー

ピュアKubernetes実装

Oracle Cloud Infrastructure Registry(OCIR)

プライベートリポジトリの提供
Docker　V2対応のコンテナレジストリサービス

コンテナベース開発とCI/CD

Container Pipeline / Wercker

コンテナベース開発に対応するCI/CDサービス

（东京煤气i网络有限公司）在聊天机器人系统中利用Oracle容器引擎来进行Kubernetes的案例。

• Line ←→　エントリーポイント　←→　チャットボット　→　会話ログ　←　分析

エントリーポイントをコンテナ化

スケールイン・アウトが容易
Web APIでシステム連携することが前提
アプリの機能を独立して作れる
機能によって適した言語・環境で作れる
ポータビリティが高い
自動化容易

コンテナ化だけすればよい？

問い合わせの増加・社内外サービスとの連携

コンテナ増で対応

ビジネス要件の実現に注力したい→メンテナンスに手間をかけたくない
コンテナオーケストレーターの導入

OCIの利用

概念の理解

クラウド利用初めてのサービス　従来はオンプレ
OCI特有の概念　コンパートメント、グループ、ポリシー
解決：ドキュメント、問い合わせ

オンボーディングセミナー
寺子屋Oracle Cloud

命名ルール

解決：ドキュメント参照、自分のセンス

OKEを利用してみて

簡単に/早くクラスタを作れる

GUIで数クリック
生Kubernetes：自分たちでやることがたくさんあって、難易度高い

リソースの追加が容易

ほしいコンテナ数をyamlファイルに記述、コマンド一発

Kubernetesの標準機能をそのまま使える

他社からOKEに移っても、アプリの実装を変更せずに移植できる

アプリ開発に注力できる

アプリで意識しなくてはいけなかったことが解決できる（OS環境変数、ネットワークの構成）
環境に依存しない

監視ツール（OMC）との連携

わかりやすい　管理画面、ログパーサーが優秀
コンテナにエージェントを仕込んで起動すれば監視対象となる

OKEでつまづいた例

ネットワークの設定ミス

ドキュメントはちゃんと読むこと（英語版のほうがよい）

OMCでnodeのログを監視していなかった

アプリ（コンテナ）のログだけでは足りなかった

開発者の感想

Masterノードの用意が一切不要 → etcdのことを全く知らなくてもKubernetesの機能利用可能

今後の展開

Terraformでの環境自動構築
Oracle Container PipelineでのCI/CD
コンテナで動かすことを前提としたアプリ開発
Oracle Analytics Cloudによるビッグデータ解析

最後に

アプリ屋さん、インフラ屋さんというマインドセットを変えていく必要がある
今後クラウド環境の活用は必須 → インフラ屋さん、アプリ屋さん関わらず両方の知識が必要

我已经尝试从AWS迁移到Oracle Cloud，可以提供OKE评估报告（由Atmitech提供）。

• Cloudii twitter@Cloudii_jp

 

• Jmeter on Container

プラグインープログラムを変更したときなどに配布するのが大変　コンテナ化して楽になった

DEMO楽しかった
詳細はブログに書いてくれるらしいので割愛（楽しみ）

Cloudii blog
(3/25追記）ブログがアップされていました

OKE（Oracle Container Engine for Kubernetes）でJMeterクラスター環境構築_その１
OKE（Oracle Container Engine for Kubernetes）でJMeterクラスター環境構築_その２

Kubernetes的应用策略和使用案例

• twitter@cotoc88

 

• Cloud Nativeなアプリケーションであるとは？

ビジネスに求められるスピードと柔軟性、拡張性

コンポーネント単位のサービス
頻繁にスケールを変更
継続的に更新を繰り返す
プラットフォームの変更を意識しない
ビルドと連携された自動テスト

既存アプリケーションシステムのリファクタリング

コスト削減
機会損失を最適化
モバイルアプリSNSなどの外部連携に適用

柔軟性・拡張性のあるシステムに最適なアーキテクチャ

サービス単位で拡張しやすいマイクロサービス・アーキテクチャ

複数の小さなアプリケーション同士をAPIで連携させシステムを実装
サービス同士の境界管理が複雑化しがち
RESTで呼び合う形：サービスメッシュ

モノリシック　堅牢・安定　柔軟性・変更容易性に欠ける　頻繁な更新やスケールアウトが困難

既存システムのCloud Nativeへのアプローチ

既存システムのLift & Shift
フロントエンドの分離・API化

フロントエンドの高頻度リリース
他システムとの連携

システム全体のマイクロサービス化

既存資産をCloud Nativeにする際の考慮する事項

変更することによるリスク
リスクを洗い出すための時間・コスト
変更のコストを受け入れられるか
運用の変化に対応できるか、体制を組めるか

現実解

あるものを使う

クラウドで提供されている機能を活用する
オンプレの既存資産は有効活用

できるだけ作らない

オンプレと同じ環境を同じ手法でクラウド上に作らない

Autonomous Database

自己稼働、自己保護、自己修復
管理、監視、チューニングを自動化
オンラインでスケール可能
機械学習を活用しデータベースを自動管理

API Gateway
Oracle Functions
活用戦略の勘所

素早く始めることこそCloud Native
フロントエンドはSoEの要　フロントエンドを分離
既存資産をCloudに移行することで管理性を高められ、性能、可用性も安心
Cloud Nativeサービスを使いこなし、簡単に作ってサービス展開