megaease/easemesh

Support native Deployment of Kubernetes

xxx7xxxx opened this issue · 1 comments

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 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.

Reference

[1] https://github.com/megaease/easemesh/blob/main/docs/user_manual.md#meshdeployment

#51 Fixed