Onboard Kubernetes workloads

This page shows you how to onboard Kubernetes workloads withCloud Service Mesh.

Deploy Kubernetes services

To deploy Kubernetes services to clusters with Cloud Service Mesh, you mustdo the following:

• CreateKubernetes Servicesfor all containers. AllDeployments should have a Kubernetes service attached.

• Name your service ports. Although GKE lets you define unnamedservice ports, Cloud Service Mesh requires that you provide aname for a port that matches the port'sprotocol.

• Label your deployments. This lets you use Cloud Service Mesh trafficmanagement features such as splitting traffic between versions of the sameservice.

The following example deployment and service illustrate these requirements:

apiVersion:apps/v1kind:Deploymentmetadata:name:helloserverspec:replicas:1selector:matchLabels:app:helloservertemplate:metadata:labels:app:helloserverspec:containers:-image:gcr.io/google-samples/istio/helloserver:v0.0.1imagePullPolicy:Alwaysname:mainrestartPolicy:AlwaysterminationGracePeriodSeconds:5

apiVersion:v1kind:Servicemetadata:name:hellosvcspec:ports:-name:httpport:80targetPort:8080selector:app:helloservertype:LoadBalancer

After deploying your services on a cluster with Cloud Service Mesh, be sure toinject sidecar proxies.

Example: Deploy the Online Boutique sample

The Online Boutique sample application in theanthos-service-mesh-packagesrepository is modified from the original set of manifests in themicroservices-demorepository. Following best practices, each service is deployed in a separatenamespace with a unique service account.

1. Create the namespaces for the application:

   kubectl apply -f \DIR_PATH/samples/online-boutique/kubernetes-manifests/namespaces

   Expected output:

   namespace/ad creatednamespace/cart creatednamespace/checkout creatednamespace/currency creatednamespace/email creatednamespace/frontend creatednamespace/loadgenerator creatednamespace/payment creatednamespace/product-catalog creatednamespace/recommendation creatednamespace/shipping created

2. Enable the namespaces for injection. The steps depend on yourcontrol plane implementation.

   Managed (TD)

   Apply the default injection label to the namespace:

   fornsinadcartcheckoutcurrencyemailfrontendloadgeneratorpaymentproduct-catalogrecommendationshipping;dokubectllabelnamespace$ns\istio.io/rev-istio-injection=enabled--overwritedone;

   Managed (Istiod)

   Recommended: Run the following command to apply the default injection label to the namespace:

   fornsinadcartcheckoutcurrencyemailfrontendloadgeneratorpaymentproduct-catalogrecommendationshipping;dokubectllabelnamespace$ns\istio.io/rev-istio-injection=enabled--overwritedone;

   If you are an existing user with the Managed Istiod control plane:We recommend that you use default injection, but revision-based injection issupported. Use the following instructions:

   1. Run the following command to locate the available release channels:

      kubectl-nistio-systemgetcontrolplanerevision

      The output is similar to the following:

      NAME                AGEasm-managed-rapid   6d7h

      Note: If two control plane revisions appear in the earlier list, remove one. Having multiple control plane channels in the cluster is not supported.

      In the output, the value under theNAME column is the revision label that corresponds to the availablerelease channel for the Cloud Service Mesh version.

   2. Apply the revision label to the namespace:

      fornsinadcartcheckoutcurrencyemailfrontendloadgeneratorpaymentproduct-catalogrecommendationshipping;dokubectllabelnamespace$ns\istio-injection-istio.io/rev=REVISION_LABEL--overwritedone;

   In-cluster

   Recommended: Run the following command to apply the default injection label to the namespace:

   fornsinadcartcheckoutcurrencyemailfrontendloadgeneratorpaymentproduct-catalogrecommendationshipping;dokubectllabelnamespace$ns\istio.io/rev-istio-injection=enabled--overwritedone;

   We recommend that you use default injection, but revision-based injection is supported:Use the following instructions:

   1. Use the following command to locate the revision label onistiod:

      kubectlgetdeploy-nistio-system-lapp=istiod-o\jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

   2. Apply the revision label to the namespace. In the following command,REVISION_LABEL is the value of theistiod revisionlabel that you noted in the previous step.

      fornsinadcartcheckoutcurrencyemailfrontendloadgeneratorpaymentproduct-catalogrecommendationshipping;dokubectllabelnamespace$ns\istio-injection-istio.io/rev=REVISION_LABEL--overwritedone;

3. Deploy the sample application to the cluster.

   1. Create the service accounts and deployments:

      kubectlapply-f\DIR_PATH/samples/online-boutique/kubernetes-manifests/deployments

      Expected output:

      serviceaccount/ad createddeployment.apps/adservice createdserviceaccount/cart createddeployment.apps/cartservice createdserviceaccount/checkout createddeployment.apps/checkoutservice createdserviceaccount/currency createddeployment.apps/currencyservice createdserviceaccount/email createddeployment.apps/emailservice createdserviceaccount/frontend createddeployment.apps/frontend createdserviceaccount/loadgenerator createddeployment.apps/loadgenerator createdserviceaccount/payment createddeployment.apps/paymentservice createdserviceaccount/product-catalog createddeployment.apps/productcatalogservice createdserviceaccount/recommendation createddeployment.apps/recommendationservice createdserviceaccount/shipping createddeployment.apps/shippingservice created

   2. Create the services:

      kubectl apply -f \DIR_PATH/samples/online-boutique/kubernetes-manifests/services

      Expected output:

      service/adservice createdservice/cartservice createdservice/checkoutservice createdservice/currencyservice createdservice/emailservice createdservice/frontend createdservice/frontend-external createdservice/paymentservice createdservice/productcatalogservice createdservice/recommendationservice createdservice/shippingservice created

   3. Create the service entries:

      kubectl apply -f \DIR_PATH/samples/online-boutique/istio-manifests/allow-egress-googleapis.yaml

      Expected output:

      serviceentry.networking.istio.io/allow-egress-googleapis createdserviceentry.networking.istio.io/allow-egress-google-metadata created

Name service ports

To be included in Cloud Service Mesh, service ports must be named, and the name mustinclude the port's protocol, for example:

apiVersion: v1kind: Servicemetadata:  name: ratings  labels:    app: ratings    service: ratingsspec:  ports:  - port: 9080name: http

The service port name can include a suffix in the following syntax:name:protocol[-suffix]where the square brackets indicate an optional suffix that must start with adash, for example:

kind: Servicemetadata:  name: myservicespec:  ports:  - number: 3306    name: mysql  - number: 80name: http-web

For metrics to be displayed in the Google Cloud console, the service portsmust be named with one of the following protocols:http,http2, orgrpc.Service ports named with thehttps protocol are treated astcp, and metricsaren't displayed for those services.

Inject sidecar proxies

This section covers how to configure sidecar proxy injection withCloud Service Mesh to enhance network security, reliability, andobservability. These functions are abstracted away from the application'sprimary container and implemented in a common out-of-process proxy (the sidecar),delivered as a separate container in the same Pod. You can useCloud Service Mesh's features without redesigningyour production applications to participate in a service mesh.

Automatic sidecar proxy injection (auto-injection) occurs whenCloud Service Mesh detects a namespace label you configure for the workload'sPod. The proxy intercepts all inbound and outbound traffic to the workloads andcommunicates with Cloud Service Mesh.

Enabling automatic sidecar injection

1. Enable the namespace for injection. The steps depend on yourcontrol plane implementation.

   Managed (TD)

   1. Apply the default injection label to the namespace:

   kubectllabelnamespaceNAMESPACEistio.io/rev-istio-injection=enabled--overwrite

   Managed (Istiod)

   Recommended: Run the following command to apply the default injection label to the namespace:

   kubectllabelnamespaceNAMESPACE\istio.io/rev-istio-injection=enabled--overwrite

   If you are an existing user with the Managed Istiod control plane:We recommend that you use default injection, but revision-based injection issupported. Use the following instructions:

   1. Run the following command to locate the available release channels:

      kubectl-nistio-systemgetcontrolplanerevision

      The output is similar to the following:

      NAME                AGEasm-managed-rapid   6d7h

      NOTE: If two control plane revisions appear in the list above, remove one. Having multiple control plane channels in the cluster is not supported.

      In the output, the value under theNAME column is the revision label that corresponds to the availablerelease channel for the Cloud Service Mesh version.

   2. Apply the revision label to the namespace:

      kubectllabelnamespaceNAMESPACE\istio-injection-istio.io/rev=REVISION_LABEL--overwrite

   In-cluster

   Recommended: Run the following command to apply the default injection label to the namespace:

   kubectllabelnamespaceNAMESPACE\istio.io/rev-istio-injection=enabled--overwrite

   We recommend that you use default injection, but revision-based injection is supported:Use the following instructions:

   1. Use the following command to locate the revision label onistiod:

      kubectlgetdeploy-nistio-system-lapp=istiod-o\jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

   2. Apply the revision label to the namespace. In the following command,REVISION_LABEL is the value of theistiod revisionlabel that you noted in the previous step.

      kubectllabelnamespaceNAMESPACE\istio-injection-istio.io/rev=REVISION_LABEL--overwrite

2. Restart the affected pods, using the steps in the next section.

3. Annotate thedemo namespace as follows:

   kubectl annotate --overwrite namespaceNAMESPACE \mesh.cloud.google.com/proxy='{"managed":"true"}'

Restart Pods to update sidecar proxies

With automatic sidecar injection, you can update the sidecars for existing Podswith a Pod restart:

How you restart Pods depends on whether they were created as part of aDeployment.

1. If you used a Deployment, restart the Deployment, which restarts all Podswith sidecars:

   kubectl rollout restart deployment -nNAMESPACE

   If you didn't use a Deployment, delete the Pods, and they are automaticallyrecreated with sidecars:

   kubectl delete pod -nNAMESPACE --all

2. Check that all the Pods in the namespace have sidecars injected:

   kubectl get pod -nNAMESPACE

   In the following example output from the previous command, notice that theREADY column indicates there are two containers for each of yourworkloads: the primary container and the container for the sidecar proxy.

   NAME                    READY   STATUS    RESTARTS   AGEWORKLOAD           2/2     Running   0          20s...