- kubectl v1.21+ with cluster administrator privileges
- An existing Kubernetes v1.19+ cluster
- A running Grey Matter operator within your cluster
- A configured Mesh custom resource that includes the
defaultnamespace in its
The operator is capable of assisting deployments by optionally injecting, and (independently optionally) configuring that sidecar to be accessible through the default edge gateway. If you add the necessary annotations to your Deployment or StatefulSet, (and they are deployed into a "watched" namespace according to the operator's core CUE configuration) the operator will respond accordingly.
To get started, create a new file called
workload.yaml with the following contents:
# workload.yaml apiVersion: apps/v1 kind: Deployment metadata: name: simple-server spec: selector: matchLabels: app: simple-server template: metadata: labels: app: simple-server annotations: greymatter.io/inject-sidecar-to: "3000" greymatter.io/configure-sidecar: "true" spec: containers: - name: server image: python:3 command: ["python"] args: ["-m", "http.server", "3000"]
kubectl apply -f workload.yaml
Creating a Deployment or StatefulSet in a namespace specified in a Mesh custom resource's
watch_namespaces array will signal to the operator to include its resulting pods in the mesh network. This occurs in three steps:
- The operator will edit the Deployment/StatefulSet by adding some labels to its nested Pod template spec based on its
spec: selector: matchLabels: app: simple-server # This label specifies the unique ID of a service a Grey Matter mesh. greymatter.io/cluster: simple-server # This label specifies the secure workload identity for mutual TLS. # Note: `mesh-sample` refers to the Mesh this service is a part of. greymatter.io/workload: mesh-sample.simple-server template: metadata: labels: app: simple-server greymatter.io/cluster: simple-server
- The operator will then inject the resulting Pod(s) with a data plane container that is a part of the mesh network. This configuration is generated by the operator from the Mesh custom resource:
# spec.template.spec.containers: - name: sidecar image: docker.greymatter.io/development/gm-proxy:latest imagePullPolicy: IfNotPresent env: - name: ENVOY_ADMIN_LOG_PATH value: /dev/stdout - name: PROXY_DYNAMIC value: "true" - name: XDS_HOST value: control.greymatter.svc.cluster.local - name: XDS_PORT value: "50000" - name: XDS_ZONE value: default-zone - name: XDS_CLUSTER value: simple-server - name: SPIRE_PATH value: /run/spire/socket/agent.sock ports: - name: proxy containerPort: 10808 protocol: TCP - name: metrics containerPort: 8081 protocol: TCP
- The operator will bootstrap the mesh configurations needed for the data plane container to receive traffic from the
edgedata plane and proxy it to other containers in the same pod.
After the operator configures the data plane container and control plane mesh configurations, you can connect to your service through the mesh via the
edge data plane at an address that matches the format
edge-address will vary based on how your Kubernetes cluster is exposed to the internet.
In the case of our
sample-server deployment, we can access the service through edge and the injected sidecar at: