「Machine Config Operatorのちょっとイイかもしれない話」@ OpenShift.run (12/21 更新)
登壇資料
Red Hat にてソリューションアーキテクトをしております荒木です。OpenShift アドベントカレンダー20日目は、本日(12月20日に)開催されましたOpenShift.runの講演資料の紹介をさせて頂こうと思います。
登壇では、OpenShift 4 より、Operator として実装されました、Machine Config Opearator について話してみました。
SlideShare : Machine Config Operator のちょっとイイかもしれない話 講演資料の共有
要約：OpenShift 4 では、Operator にフォーカスした機能の実現や拡張が行われています。その機能の一つとして、nodeの管理を提供するMachine Config Operator(MCO)を取り上げます。MCOによって、大規模な環境において煩雑になりがちな、nodeの維持管理に関する様々な操作に自動化が促されます。従来のシステムインフラの場合、それぞれのOSに対して、個別に設定変更や構成変更を行うというのが通常のアプローチだったのではないかと思いますが、OpenShiftでは、MCO があることによって、そういった操作のドライバーとなる機構を構築し、Machine APIや、Cluster Version Opeator を介して、操作の簡易化や、自動化が実現されています。
観点をMachine API に向けます。OpenShift 4 のここまでのリリースで実現されている、node auto-scale in / out や、Over-The-Air Update 等、自動化が深く関連する機能群は、幾つかの前提条件を伴うため、今のところ、いずれの環境下、前提条件において、全て期待出来る訳ではありません。
環境の維持管理／運用の計画に関する要件を整理し、機能面と競合する事項を慎重に解決していく必要があるポイントかと思います。
個人的に認識しているMachine APIによる自動化に関する制約事項について、以下に列記します。
- Machine API による自動化の制限 ( version 4.2 時点 )
- 最も高度な自動化を期待する場合は、Installer Provisioned Infrastructure (IPI)で構築されている必要がある
- この場合、ノードのOSは必然的に、CoreOS となる。
- User Provisioned Infrastructure で構築している場合、採用するOS(RHEL or CoreOS)によって自動化の度合いが異る。
- RHELの場合、パッケージのアップデート操作は手動で実施することとなる
- Machine Controller が対応するIaaS用ドライバ(cluser-api-provider)が提供されている必要がある(※開発状況)
- Cloud Provider によって自動化の範囲が異る。(Network / DNS / External LB の扱いや対応状況には差がある)
- Bare metal や、仮想化環境についても同様の仕組みのための開発が展開されている
- Machine のAuto Healing 機能は、まだ実装中。4.2 では、ヘルスチェックのみTP
- 最も高度な自動化を期待する場合は、Installer Provisioned Infrastructure (IPI)で構築されている必要がある
Machine API は、アップストリームにおける、Cluster API の機能拡張／整備したものとなりますが、現在も盛んに機能開発が行われています。大きな方向性としては、OpenShift(kubernetes)クラスタ環境そのものの維持管理を、Kube-Native に行えるようにする為の機能の実現を目標としています。発展途上ではありますが、その方向性において、とても魅力的なプロジェクトではないかなと思います。
OpenShift インストーラのコンソール実行ログ
公演中、その裏側で、openshift-installer によって、aws 上に、IPI 構成で、インストールを実施して、公演中に完了するのか？というデモを実施致しました。実行した際のコンソールログがありますので、改めて紹介させていただきます。
[toaraki-redhat.com@clientvm 130 ~]$ date ; time openshift-install create cluster --dir ***************************
Fri Dec 20 05:20:27 UTC 2019
INFO Consuming "Install Config" from target directory
INFO Creating infrastructure resources...
INFO Waiting up to 30m0s for the Kubernetes API at https://api.**********************.opentlc.com:6443...
INFO API v1.14.6+17b1cc6 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO Destroying the bootstrap resources...
INFO Waiting up to 30m0s for the cluster at https://api.********.com:6443 to initialize...
INFO Waiting up to 10m0s for the openshift-console route to be created...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=****************************************'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.*******.com
INFO Login to the console with user: kubeadmin, password: ***********
real 33m4.454s
user 0m29.313s
sys 0m1.720s
[toaraki-redhat.com@clientvm 0 ~]$
もともと、この試みの意図としては、OpenShift Installerが、全自動で動作した場合、どの程度の時間でClusterを展開できるのかを示したかったわけですが、内部的な動きとして、MachineAPIおよびMCOが提供するものに通ずる動作をしており（それが果たしてそのものなのか、部分的な機能なのかという点については未だ調査できていません。）、興味深いです。
結果的に、今回、master x 3 , worker x 2 の構成でのデプロイを実施致しました。概ね、この規模だと、30分前後でデプロイすることが可能です。ただし、この処理時間については、リージョンによって異なるのか、台数によってことなるか等、細かい点についてはまだ把握できていないので、今後、このあたりもじっくり素振りしていきたいなと思います。