Currently, we leveraged a dedicated CRD whose kind is MeshDeployment[1] to creat the service entity running in k8s. It totally contains the spec of standard Deployment plus EaseMesh specific information. As it is a CustomResourceDefinitions, it brings some barrier to migrate deployments in existed system. So we decide to support management of native Deployment of k8s.
Proposal
Overall even though we support native deployment, we need to know the necessary information of the mesh service. Therefore we decide to use the idiomatic annotations, e,g:
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service # We use metadata.name to be service name by default.
labels: # We use standard metadata.labels to be service labels.
app: order-service
version: v1
phrase: production
annotations:
mesh.megaease.com/enable: true # If not true, the deployment is not a mesh service.
mesh.megaease.com/service-name: order-service # If empty, we use metadata.name.
mesh.megaease.com/app-container-name: order-service # If empty, we choose the first container.
mesh.megaease.com/application-port: 8080 # If empty, we choose the first container port.
mesh.megaease.com/alive-probe-url: http://localhost:8080/healthz # Currently, we only support method GET.
spec:
# ...
When the mesh.megaease.com/enable is true, we will modify the deployment spec by injecting a new sidecar container.
When the mesh.megaease.com/enable turned from true to false, we will eliminate the sidecar container too.
The operator support both MeshDeployment and Deployment, so it's the users's responsibility to guarantee that the service name is not conflict.
Background
Currently, we leveraged a dedicated CRD whose kind is
MeshDeployment
[1] to creat the service entity running in k8s. It totally contains the spec of standardDeployment
plus EaseMesh specific information. As it is aCustomResourceDefinitions
, it brings some barrier to migrate deployments in existed system. So we decide to support management of nativeDeployment
of k8s.Proposal
Overall even though we support native deployment, we need to know the necessary information of the mesh service. Therefore we decide to use the idiomatic annotations, e,g:
When the
mesh.megaease.com/enable
istrue
, we will modify the deployment spec by injecting a new sidecar container. When themesh.megaease.com/enable
turned fromtrue
tofalse
, we will eliminate the sidecar container too.The operator support both
MeshDeployment
andDeployment
, so it's the users's responsibility to guarantee that the service name is not conflict.Reference
[1] https://github.com/megaease/easemesh/blob/main/docs/user_manual.md#meshdeployment