Console
    Contact Us Start free

    Onboard Kubernetes workloads

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

    Deploy Kubernetes services

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

    • Create Kubernetes Services for all containers. All Deployments should have a Kubernetes service attached.

    • Name your service ports. Although GKE lets you define unnamed service ports, Cloud Service Mesh requires that you provide a name for a port that matches the port's protocol.

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

    The following example deployment and service illustrate these requirements:

      apiVersion 
 : 
  
 apps/v1 
 kind 
 : 
  
 Deployment 
 metadata 
 : 
  
 name 
 : 
  
 helloserver 
 spec 
 : 
  
 replicas 
 : 
  
 1 
  
 selector 
 : 
  
 matchLabels 
 : 
  
 app 
 : 
  
 helloserver 
  
 template 
 : 
  
 metadata 
 : 
  
 labels 
 : 
  
 app 
 : 
  
 helloserver 
  
 spec 
 : 
  
 containers 
 : 
  
 - 
  
 image 
 : 
  
 gcr.io/google-samples/istio/helloserver:v0.0.1 
  
 imagePullPolicy 
 : 
  
 Always 
  
 name 
 : 
  
 main 
  
 restartPolicy 
 : 
  
 Always 
  
 terminationGracePeriodSeconds 
 : 
  
 5 
 

      apiVersion 
 : 
  
 v1 
 kind 
 : 
  
 Service 
 metadata 
 : 
  
 name 
 : 
  
 hellosvc 
 spec 
 : 
  
 ports 
 : 
  
 - 
  
 name 
 : 
  
 http 
  
 port 
 : 
  
 80 
  
 targetPort 
 : 
  
 8080 
  
 selector 
 : 
  
 app 
 : 
  
 helloserver 
  
 type 
 : 
  
 LoadBalancer

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

    Example: Deploy the Online Boutique sample

    The Online Boutique sample application in the anthos-service-mesh-packages repository is modified from the original set of manifests in the microservices-demo repository. Following best practices, each service is deployed in a separate namespace 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 created
namespace/cart created
namespace/checkout created
namespace/currency created
namespace/email created
namespace/frontend created
namespace/loadgenerator created
namespace/payment created
namespace/product-catalog created
namespace/recommendation created
namespace/shipping created

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

      Managed (TD)

      Apply the default injection label to the namespace:

        for 
  
ns  
 in 
  
ad  
cart  
checkout  
currency  
email  
frontend  
loadgenerator  
payment  
product-catalog  
recommendation  
shipping ; 
  
 do 
  
kubectl  
label  
namespace  
 $ns 
  
 \ 
  
istio.io/rev-  
istio-injection = 
enabled  
--overwrite done 
 ;

      Managed (Istiod)

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

         
 for 
  
ns  
 in 
  
ad  
cart  
checkout  
currency  
email  
frontend  
loadgenerator  
payment  
product-catalog  
recommendation  
shipping ; 
  
 do 
  
kubectl  
label  
namespace  
 $ns 
  
 \ 
  
istio.io/rev-  
istio-injection = 
enabled  
--overwrite  
 done 
 ;

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

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

         kubectl  
-n  
istio-system  
get  
controlplanerevision

        The output is similar to the following:

         NAME                AGE
asm-managed-rapid   6d7h

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

      2. Apply the revision label to the namespace:

          for 
  
ns  
 in 
  
ad  
cart  
checkout  
currency  
email  
frontend  
loadgenerator  
payment  
product-catalog  
recommendation  
shipping ; 
  
 do 
  
kubectl  
label  
namespace  
 $ns 
  
 \ 
  
istio-injection-  
istio.io/rev = 
 REVISION_LABEL 
  
--overwrite done 
 ;

      In-cluster

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

         
 for 
  
ns  
 in 
  
ad  
cart  
checkout  
currency  
email  
frontend  
loadgenerator  
payment  
product-catalog  
recommendation  
shipping ; 
  
 do 
  
kubectl  
label  
namespace  
 $ns 
  
 \ 
  
istio.io/rev-  
istio-injection = 
enabled  
--overwrite  
 done 
 ;

      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 on istiod :

         kubectl  
get  
deploy  
-n  
istio-system  
-l  
 app 
 = 
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 the istiod revision label that you noted in the previous step.

          for 
  
ns  
 in 
  
ad  
cart  
checkout  
currency  
email  
frontend  
loadgenerator  
payment  
product-catalog  
recommendation  
shipping ; 
  
 do 
  
kubectl  
label  
namespace  
 $ns 
  
 \ 
  
istio-injection-  
istio.io/rev = 
 REVISION_LABEL 
  
--overwrite done 
 ;

    3. Deploy the sample application to the cluster.

      1. Create the service accounts and deployments:

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

        Expected output:

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

      2. Create the services:

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

        Expected output:

         service/adservice created
service/cartservice created
service/checkoutservice created
service/currencyservice created
service/emailservice created
service/frontend created
service/frontend-external created
service/paymentservice created
service/productcatalogservice created
service/recommendationservice created
service/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 created
serviceentry.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 must include the port's protocol, for example:

    apiVersion: v1
kind: Service
metadata:
  name: ratings
  labels:
    app: ratings
    service: ratings
spec:
  ports:
  - port: 9080 name: 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 a dash, for example:

    kind: Service
metadata:
  name: myservice
spec:
  ports:
  - number: 3306
    name: mysql
  - number: 80 name: http-web

    For metrics to be displayed in the Google Cloud console, the service ports must be named with one of the following protocols: http , http2 , or grpc . Service ports named with the https protocol are treated as tcp , and metrics aren't displayed for those services.

    Inject sidecar proxies

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

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

    Enabling automatic sidecar injection

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

      Managed (TD)

      1. Apply the default injection label to the namespace:
       kubectl  
label  
namespace  
 NAMESPACE 
  
istio.io/rev-  
istio-injection = 
enabled  
--overwrite

      Managed (Istiod)

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

         
kubectl  
label  
namespace  
 NAMESPACE 
  
 \ 
  
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 is supported. Use the following instructions:

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

         kubectl  
-n  
istio-system  
get  
controlplanerevision

        The output is similar to the following:

         NAME                AGE
asm-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 the NAME column is the revision label that corresponds to the available release channel for the Cloud Service Mesh version.

      2. Apply the revision label to the namespace:

         kubectl  
label  
namespace  
 NAMESPACE 
  
 \ 
  
istio-injection-  
istio.io/rev = 
 REVISION_LABEL 
  
--overwrite

      In-cluster

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

         
kubectl  
label  
namespace  
 NAMESPACE 
  
 \ 
  
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 on istiod :

         kubectl  
get  
deploy  
-n  
istio-system  
-l  
 app 
 = 
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 the istiod revision label that you noted in the previous step.

         kubectl  
label  
namespace  
 NAMESPACE 
  
 \ 
  
istio-injection-  
istio.io/rev = 
 REVISION_LABEL 
  
--overwrite

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

    3. Annotate the demo namespace as follows:

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

    Restart Pods to update sidecar proxies

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

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

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

      kubectl rollout restart deployment -n NAMESPACE

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

      kubectl delete pod -n NAMESPACE 
--all

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

      kubectl get pod -n NAMESPACE

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

      NAME                    READY   STATUS    RESTARTS   AGE WORKLOAD 
2/2     Running   0          20s
...
    Create a Mobile Website
    View Site in Mobile | Classic
    Share by: