Managing Service Mesh with OCI APIs vs kubectl

A mesh resource is managed using either of the two approaches. However, if you choose to manage a resource with Kubernetes CLI, the resource cannot be modified using the OCI APIs. After a resource is created using Kubernetes, the Kubernetes Operator becomes the source of truth for that resource's configuration. Any modifications to the resource must be done through the Kubernetes CLI only.

Resources created through the OCI APIs exist only in the Service Mesh control plane. The resources don't have corresponding custom resources in Kubernetes and hence the Kubernetes Operator does not manage them.

Update/Synchronization behavior

The only way to change Kubernetes CLI (kubectl) managed resources is by running a kubectl command. Changes done using the OCI APIs (OCI console, CLI, SDK, Terraform Provider) cannot be synced to the Kubernetes Operator and are automatically reverted. The Kubernetes Operator runs a reconciliation loop, for example every hour. Any resources changed using the OCI APIs are reverted to match the configuration stored in the custom resources managed by the OCI Service Operator for Kubernetes.

Scenarios

The following scenarios describe the update/synchronization behaviors in Service Mesh. All these scenarios assume that the mesh resource exists.

• Changes are made to a kubectl created ingress gateway's configuration from the console or CLI.
  • After the operator's reconciliation process runs, the changes are automatically reverted to their initial state.
• Changes are made to a virtual deployment using kubectl.
  • Changes made through kubectl update the operator and are immediately reflected in the OCI APIs.