OCI StreamingのためのKubernetesサービスオペレーター - ファーストステップ (2021/10/31)
OCI StreamingのためのKubernetesサービスオペレーター - ファーストステップ (2021/10/31)
投稿者：Fernando Harris
Oracle Cloud Infrastructureのエコシステムはオープンでユビキタスであり、サービス間の統合を促進するさまざまな標準化されたアプローチを利用でき、開発者やクラウドアーキテクトの生活をよりシンプルにします。
https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengaddingosok.htm
OCI Service Broker for Kubernetesは、Oracle Container EngineとKubernetesをOCIと対話させるための事実上のアプローチでした。しかし現在、オラクルはKubernetes APIとKubernetesツールを使ってOracle Cloud Infrastructureサービスと対話するために、OCI Service Operator for Kubernetesの使用を推奨しています。まずはこちらのドキュメントをご覧ください。その前に、コーヒーか紅茶を用意して、この記事を10分ほど読んでいただければ、もう大丈夫です。
まあ、大体はそうでしょう。このブログは、あなたが知るべきことがすべて含まれているGithubプロジェクトを補完するものです。私がここで提供するものは、単なるスタート地点に過ぎません :) .
この記事では、Oracle Container Engine aka OKEとOCI Streamingサービスを安全な方法で接続することを試みます。OCI Streamingサービスは、開発者やデータサイエンティストのための、リアルタイムでサーバーレスなApache Kafka互換のイベントストリーミングプラットフォームです。
OSOKは、自動化されたスケーラブルな方法でオペレーターを管理するためのオープンソースのツールキットである「Operator Framework」をベースにしています。
基本的なコンセプトやコンポーネントは、オペレーターです。
https://sdk.operatorframework.io/
オペレータSDKで何ができますか？
Operator SDKは、Operatorを構築、テスト、およびパッケージ化するためのツールを提供します。当初、SDKは、アプリケーションのビジネスロジック（例えば、スケール、アップグレード、バックアップの方法）と、それらの操作を実行するKubernetes APIとの連携を容易にします。将来的には、このSDKによってエンジニアはアプリケーションをよりスマートにし、クラウドサービスのようなユーザーエクスペリエンスを得ることができます。オペレーター間で共有されているリーディングプラクティスやコードパターンがSDKに含まれているため、車輪の再発明を防ぐことができます。
Operator SDKは、コントローラ・ランタイム・ライブラリを使用したフレームワークで、以下を提供することでオペレーターの作成を容易にします。
- オペレータのロジックを直感的に記述するための高レベルAPIと抽象化
- 新しいプロジェクトを迅速に立ち上げるための、足場とコード生成のためのツール
- オペレータの一般的なユースケースをカバーする拡張機能
https://olm.operatorframework.io/
もう一つの重要なコンセプトはOperator Lifecycle Managerで、"Kubernetesのネイティブアプリケーションを自動的に最新の状態に保つための豊富なメカニズムを提供する "というものです。
まず始めよう。
Kubernetes APIに対してkubectlコマンドを実行して、OEクラスタとそのクラスタへの適切なアクセスがあることを確認します。例：kubectl get nodes
OCI Service Brokerと混同しないでください。
OCI Service Broker for Kubernetesの代わりに、オラクルはOCI Service Operator for Kubernetesを使用して、Kubernetes APIとKubernetesツールを使用してOracle Cloud Infrastructureサービスと対話することを推奨しています。
インストールの詳細な手順は、GithubリポジトリのOCI Service Operator for Kubernetesのドキュメントに記載されています。要約すると、3つの連続したステップを踏むことになります。
- OCI Service Operator for Kubernetesをインストール
- OCI Service Operator for Kubernetesのセキュリティを確保
- 必要なOracle Cloud Infrastructureサービスをプロビジョニングし、バインド
ドキュメントやGithubに沿って、順を追ってやっていきます。
パート1：OCI Service Operator for Kubernetesのインストール
Operator SDKをインストール
https://sdk.operatorframework.io/docs/installation/
私の場合は、Macを使用しています。
Homebrew (macOS)からのインストール
brew install operator-sdk
brew install operator-sdk
2. Operator Lifecycle Manager（OLM）をインストール
$operator-sdk olm install
$operator-sdk olm status
OLM install OK
OLM resources created in K8 cluster
これにより、olmとoperatorsという2つの新しい名前空間の作成を含む、たくさんの新しいリソースがクラスタにインストールされます。
それでは、OCI Service Operator for Kubernetesをデプロイしてみましょう。
まず最初に、K8クラスタのノードプールで動作しているインスタンスからOCIDを取得しましょう。これは、OCIコンソールでクラスタの詳細にアクセスし、ResourcesのNodesをクリックすることでできるはずです。
instances running in OKE Cluster node pool
各インスタンスをクリックして、そのOCIDをメモ帳にコピーする。
getting instances OCID
前述したように、この最後の手順をノードプールで動作している他の2つのインスタンスに対して繰り返します。最終的には以下のようになるはずです。
ワーカーノード1:
ocid1.instance.oc1.eu-frankfurt-1.antheljsmfkspnqcffjxhmiej2xrrwnjkj2r6wkesxwzg3ucij4v373ckaja
ワーカーノード2:
ocid1.instance.oc1.eu-frankfurt-1.antheljsmfkspnqcirlw72wfoczulmjfgr5kls3imqloep2nrxgkakebtboq
ワーカーノード3:
ocid1.instance.oc1.eu-frankfurt-1.antheljsmfkspnqcaxsh7br556fgkbeujszymladyntevk4ojiy7cakapllq
これは、OCIクライアントとSDKによる典型的な認証プロセスを実行することなく、Kubernetesクラスタ内のノードプールが他のOCIサービスと対話できる方法が必要だからです。OCIクライアントやSDKなどでOCIに対する認証を管理する手間をかけずに、適切なサービスの相互作用を実現したいのです。
OCIでの標準的な方法は、インスタンス・プリンシパルと動的グループを使用することです。ドキュメントによると、動的グループを使うと、Oracle Cloud Infrastructureのコンピュート・インスタンスを「プリンシパル」アクター（ユーザー・グループに似ている）としてグループ化することができます。そして、インスタンスがOracle Cloud Infrastructureサービスに対してAPIコールを行うことを許可するポリシーを作成することができます。動的グループを作成する際には、グループにメンバーを明示的に追加するのではなく、グループメンバーを定義するための一連のマッチングルールを定義します。たとえば、特定のコンパートメントのすべてのインスタンスが動的グループのメンバーであることをルールで指定することができます。メンバーは、そのコンパートメントでインスタンスが起動したり終了したりすることで、動的に変更することができます。
コンソールを使用して動的グループを作成するには、以下の手順に従います。
- ナビゲーションメニューを開き、[Identity & Security] をクリックします。Identity] の [Dynamic Groups] をクリック
- [Create Dynamic Group] をクリック
- 次のように入力
- Name（名前）：グループの一意の名前です。この名前は、テナント内のすべてのグループ（動的グループとユーザーグループ）で一意である必要があります。これは後から変更できません。機密情報の入力は避けてください。
- 説明：親しみやすい説明
- マッチングルールを入力：ルールの基準を満たすリソースは、グループのメンバーとなります。
ルールは、上で取得したkubernetesのワーカーインスタンスのocidや、ワーカーインスタンスが動作しているコンパートメントにマッチします。
このようなものが作れるはずです。
Rules for new Dynamic Group
Any {instance.id = ‘ocid1.instance.oc1.eu-frankfurt-1.antheljsmfkspnqcffjxhmiej2xrrwnjkj2r6wkesxwzg3ucij4v373ckaja’, instance.id = ‘ocid1.instance.oc1.eu-frankfurt-1.antheljsmfkspnqcirlw72wfoczulmjfgr5kls3imqloep2nrxgkakebtboq’, instance.id = ‘ocid1.instance.oc1.eu-frankfurt-1.antheljsmfkspnqcaxsh7br556fgkbeujszymladyntevk4ojiy7cakapllq’, instance.compartment.id = ‘ocid1.compartment.oc1..aaaaaaaaupdkb2xhrcm3vk422rqq5wt4uc5hhywwxsyaw7ay2qciohrjcjbq’}
Creating a Dynamic Group in OCI
次に、動的グループに必要なパーミッションを与えるために、ポリシーを書く必要があります。ポリシーは、テナント全体、または上記で作成した動的グループのコンパートメントにある必要があります。
Githubのドキュメントから、いくつかの例を挙げることができます。
Policies examples in Github
例題の<OCI_SERVICE_1>、<OCI_SERVICE_2>などの参照は、「autonomous-database-family」、「instance_family」などのOCIサービスを表しています。この記事を書いている時点では、3つのOCIサービスがオペレータによってサポートされていることを覚えておいてください。「Autonomous Database」「MySQL PaaS」「OCI Streaming」です。
今回の例では、OCI Streamingを使用します。
OCI Policy Builderは、これらのポリシーを構築するための非常に直感的なツールです。OCIのサービスにアクセスするためのポリシーについての詳細は、以下のリンクをご覧ください。
https://docs.oracle.com/en-us/iaas/Content/Identity/Tasks/callingservicesfrominstances.htm
Policy builder in OCI Console
ポリシーステートメント
動的グループokeoperatordynamicgroupによるコンパートメントokeSharedCompartment内のストリームの管理を許可する。
テナンシーレベルでも、同様のポリシーを作成することを忘れないでください。
これで終わりです。それでは後編に移り、OCI Service Operatorのセキュリティを確保していきましょう。
PART2：Kubernetes用OCIサービスオペレーターの安全性確保
OCI Service Operator for Kubernetesのベストプラクティスでは、OCIサービスやリソースをプロビジョニングして管理するためのOCIユーザー認証情報の詳細をテナント内で要求しています。
OSOK は oci-service-operator-system 名前空間にデプロイされます。ユーザープリンシパルを有効にするには、デプロイメントの前に名前空間を作成する必要があります。
以下の例で yaml ファイルを作成します。
yaml to create operator
わたしの場合
$ kubectl apply -f serviceoperatorokenamespace.yml
ユーザーは以下のようにKubernetesのシークレットを作成する必要があります。
そのためには、Kubernetesのシークレットを作成するためのOCIユーザーの認証情報を取得します。ここでは自分のOCIユーザーを使いますが、理論的にはUser Principleを有効にするための特定のユーザーを使うべきです。
OCI Credentials for my user
Description for credentials from documentation
シークレットの名前は OSOK デプロイメントの一部として作成される osokConfig コンフィグマップに渡されます。デフォルトでは、ユーザークレデンシャルシークレットの名前は ocicredentials です。また、シークレットは oci-service-operator-system 名前空間に作成する必要があります。
create secret with kubectl for my user credentials
上記のクレデンシャルを所有するOCIユーザーは、IAMグループosok-operator-groupに追加する必要があります。また、OCIサービスを管理するために、テナント全体またはコンパートメント内にOCIポリシーを作成する必要があります。
Policies examples
### Tenancy based OCI Policy for user
Allow group <OSOK_OPERATOR_GROUP> to manage <OCI_SERVICE_1> in tenancy### Compartment based OCI Policy for user
Allow group <OSOK_OPERATOR_GROUP> to manage <OCI_SERVICE_1> in compartment <NAME_OF_THE_COMPARTMENT>
Create IAM Group
Create Policy for the Group a tenancy level
Allow group osok-operator-group to manage streams in tenancy interactivetech (root)
create policy for the group at compartment level
最終的には、以下のプリントスクリーン**に記載されているようなポリシーのセットになるはずです。
テナンシーレベルで再開されるポリシー
Policies resume at Tenancy Level
ポリシーはコンパートメントレベルで再開されます。
Policies resume at Compartment level
OSOKをK8にデプロイ
OCI側の準備が整ったところで、OperatorとKubernetesの話に戻りましょう。バンドルは以下のコマンドでdockerイメージとしてダウンロードできます。この手順はよく知っていると思いますが、Dockerエンジンが起動していることを確認してください🏃♀️ 🏃♂️ ...私はいつも忘れます.... ;)
OCI Service Operator for Kubernetesは、Kubernetesクラスタへのインストールを容易にするため、Operator Lifecycle Manager (OLM) Bundleとしてパッケージ化されています。バンドルは、以下のコマンドでdockerイメージとしてダウンロードできます。
$ docker pull iad.ocir.io/oracle/oci-service-operator-bundle:1.0.0
docker pull service operator docker image
OSOK OLMバンドルには、CRD、RBAC、コンフィグマップ、デプロイメントなど、必要なKubernetesリソースがすべて含まれており、OSOXをKubernetesクラスタにインストールすることができます。
以下のコマンドを実行して、クラスタへのリソースのインストールを開始します。
$ operator-sdk run bundle iad.ocir.io/oracle/oci-service-operator-bundle:1.0.0
Part 3: プロビジョニングと必要なOCIサービスへのバインド
最後の第3ステップはここからで、基本的には以下のようなことを行います。
- サービス・プロビジョニング・リクエスト・パラメーターを提供
- サービス・バインディング・リクエスト・パラメーターを提供
- サービス・バインディング・レスポンス・クレデンシャルを提供
ここをクリックして、ドキュメントの例をざっと見て確認してください。これらの例はそれほど詳細ではありませんが、OCIサービス（Autonomous Database、MySQL PaaS、OCI Streamingなど）とのバインディングを作成するためのダイナミックな方法を理解するのに十分なシンプルさです。
Oracle Streaming Service と OSOK
ここでは、OCI Streamingサービスのサンプルを実装する方法について、より詳細な情報を提供しています。
まずは、既存のストリームを使ってバインディングを作成してみましょう。OCIの「Analytics & AI」から「Streaming」を選択します。
コンパートメント内のアクティブなストリームのリストをご覧ください。
curiositionsdummyのストリームと結合したいと思います。そのためには、ストリームのOCIDが必要です。次に、K8 クラスタに送信する yaml マニフェストを準備します。CR_OSOK_BindExistingStream.yamlという名前にして、その内容は以下の通りです。
yaml to bind to an existing stream with OCID
run $kubectl apply -f CR_OSOK_BindExistingStream.yaml
run
$kubectl get stream curiositypointsdummy -o wide
クリックして、バインディングの詳細を確認してください。
それでは、新しいストリームを作成してみましょう。
以下の例のようなyamlテンプレートを用意します。
私の場合は、CR_OSOK_CreateStream.yamlという名前にしました。実行
$ kubectl apply -f CR_OSOK_CreateStream.yaml
run :
$ kubectl get stream createstreamarticle -o wide
これで、新しいストリームが作成され、そのOCIDが有効になったことがわかります。
このリソースの詳細を知るには次のように実行します。
$ kubectl describe stream createstreamarticle
New Stream, details 1.2
New Stream, details 2.2
OCI Consoleで検証
List of existing streams in the compartment
New stream created
予想通り、StreamDummyCROperatorArticleという新しいストリームが作成されました。
私の経験から、最後にいくつかの注意点と推奨事項があります。
パーミッション、ポリシー、グループ、動的グループを確認してください。404が表示される場合は、これらのステップのいずれかで何か間違ったことをしている可能性が高いです。この種のイベントのトラブルシューティングには、kubectl describeコマンドが欠かせません。
kubectl describeを実行して、イベントのリストが更新されていないような場合は、OCIが新しいストリームの作成を許可していない、または解放していないことが原因である可能性があります。また、パーティションの上限に達している可能性もあります。私の場合、多くのパーティションを持つストリームを削除した後、新しいストリームの作成がすぐに見られるようになりました。このような動作は、既存のストリームに結合しようとしている場合には起こりません。
OCI Streamingのリンク先には、OCIで作成されたより多くのポリシーが掲載されています。上で紹介した、必要なポリシーのまとめとしての印刷画面**は、すでに反映されています。
その他の参考文献
Mickey Boxellのブログには、MySQLサービスで同様の演習を行うための非常に素晴らしい記事があります。
https://blogs.oracle.com/cloud-infrastructure/post/oci-service-operator-for-kubernetes
同じトピックのKuassi Mensahのブログ記事も非常に興味深いです。
https://kuassimensah.medium.com/making-oracle-database-kubernetes-native-401233c02780
お疲れ様でした。
お楽しみに
Fernando
コメント
コメントを投稿