{"componentChunkName":"component---src-templates-tag-js","path":"/tags/service-mesh/","result":{"data":{"site":{"siteMetadata":{"title":"LoginRadius Blog"}},"allMarkdownRemark":{"totalCount":3,"edges":[{"node":{"fields":{"slug":"/engineering/istio-installation-and-service-configuration/"},"html":"

An infrastructure layer that allows you to manage communication between the microservices of your application is a service mesh. As more developers work with microservices, by consolidating common management and administrative tasks in a distributed setup, service meshes have developed to make the job easier and more effective.

\n

To know more about Istio, you can read this article on Istio service mesh to understand the basic terminology, In this tutorial, will explain how to install and configure Istio. Let's get started.

\n

Installing Istio

\n

Get the latest Istio release:

\n
curl -L https://istio.io/downloadIstio | sh -
\n

Extract the archive and export the bin directory in the environment path.

\n

This will also install istioctl, a command-line tool to manage Istio service mesh.

\n

Configuration Profiles

\n

Istio provides various built-in configuration profiles, a set of pre-defined configs related to data and control plane. We can customize the configs according to our needs.

\n

For testing locally or trying it ou, you can use a demo profile. For dev and other environments, we will be using the default configuration profile.

\n
istioctl install --set profile=demo
\n

Customizing configs

\n

Run:

\n
istioctl profile dump default
\n

to see the various configurations. We can change those flag using istioctl commands and --set flag.

\n

For development purpose, we can enabled/changes following flags:

\n
istioctl install --set addonComponents.kiali.enabled=true \\ \n--set components.telemetry.enabled=true \\ \n--set components.citadel.enabled=true \\ \n--set values.global.proxy.privileged=true \\ \n--set addonComponents.tracing.enabled=true \\ \n--set values.pilot.traceSampling=100.0 \\ \n--set values.global.proxy.tracer=datadog
\n

The path value of --set flag is the YAML path, which you can see in the profile dump command.

\n
\n

While changing any config, make sure to pass all the previous flags with the new ones. For example, if first time, you enabled istioctl install --set addonComponents.kiali.enabled=true and now let’s say, you want to enable citadel, then you have to pass both flags like this: istioctl install --set addonComponents.kiali.enabled=true --set components.telemetry.enabled=true.\nFailing to add any previously enabled variable will revert the config to its default values.\nOne way to store the dump in a file and do istioctl apply or use helm charts for Istio.

\n
\n

Sidecar injection

\n

For Istio to work properly, a sidecar Envoy proxy needs to be enabled for the services. By default, the Istio control plane will not enable any sidecar to any services. To enable sidecar, we have to add labels at the namespace level.

\n
kubectl label namespace dsl-test istio-injection=enabled
\n

You need to have this label even if you do not want to add a sidecar to all your services.

\n

You need to restart the pods.

\n

For services, which do not require sidecar, we need to add the following annotation in the deployment template:

\n
# Pod Annotations \npodAnnotations: \n\tsidecar.istio.io/inject: "false"
\n

Configuring Services

\n

For demonstration, we will take two demo services demo-1 and demo-2, and configure both services with Istio, and will try to call demo-2 service from demo-1. Make sure there is an env variable in demo-1, which we will configure with demo-2 internal DNS url. The programming language for the two services does not matter here.

\n

A service configuration requires a VirtualService, DestinationRule, PeerAuthentication, and optionally a Gateway configuration.

\n

Gateway

\n
apiVersion: networking.istio.io/v1alpha3 \nkind: Gateway \nmetadata: \n\tname: demo-1\nspec: \n\tselector: \n\t\tistio: ingressgateway \n\tservers: \n\t- port: \n\t\tnumber: 80 \n\t\tname: http \n\t\tprotocol: HTTP \n\t- hosts: \n\t\t- "demo-1.example.com"
\n

Gateway is used when we want to access the services from the public network.

\n

Here we are using the default gateway provided by the Istio. We can also create multiple gateways and assign the proper name here.

\n

The above gateway configuration enables both HTTP and HTTPS communication. In the case of HTTPS, we have to supply the secret containing the CA certs and key.

\n
spec:\n\tservers: \n\t- port: \n\t\tnumber: 443\n\t\tname: http \n\t\tprotocol: HTTP\n\t  tls: \n\t\tmode: SIMPLE \n\t\tcredentialName: div4-dev-certs\n\t  hosts: \n\t\t- "demo-1.example.com"
\n

We can apply the same gateway for demo-2. We just have to update the hosts and metadata name. Since we will demo-2 internally from demo-1, there is no need for an external gateway for demo-2 here.

\n

VirtualServices

\n
---\napiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n  name: demo-1\nspec:\n  hosts:\n  - "demo-1.test.svc.cluster.local"\n  - "demo-1.example.com"\n  gateways:\n    - demo-1\n  http:\n  - route:\n    - destination:\n        host: demo-1.test.svc.cluster.local\n        port:\n          number: 80
\n

spec.hosts: Specifies the URL which the caller of the service will use. Here, dsl-es.pbdp.svc.cluster.local will be used by the services calling internally. The endpoint demo-1.example.com will be exposed publicly, and it should match the spec.servers.hosts value in Gateway config.

\n

spec.gateways: In order for the gateways configured above to reach the service, we need to define the gateway metadata name here.

\n

http.route.destination.host: This value should be the actual service FQDN.

\n

DestinationRule

\n

After the virtualservice decides the destination hosts, DestinationRule defines the configuration on the actual service. DestinationRule is optional and is needed only in case we want to override the default behavior.

\n
---\napiVersion: networking.istio.io/v1alpha3\nkind: DestinationRule\nmetadata:\n  name: demo-1\nspec:\n  host: "demo-1.test.svc.cluster.local"\n  trafficPolicy:\n    loadBalancer:\n      simple: ROUND_ROBIN\n    tls:\n      mode: ISTIO_MUTUAL
\n

spec.host: specifies service FQDN

\n

spec.trafficPolicy: Specifies policy on the traffic. Here we can specify load balancing algorithms, TLS mode, circuit breaking policies.

\n

spec.trafficPolicy.tls.mode: ISTIO_MUTUAL mode is a TLS mode where we will use the certificates generated by the Istio.

\n

A configuration like circuit breakers, outlier detection comes under the Destination Rule.

\n

PeerAuthentication

\n

This configuration defines how the other services will connect.

\n
---\napiVersion: security.istio.io/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: demo-1\nspec:\n  selector:\n    matchLabels:\n      app: demo-1\n  mtls:\n    mode: STRICT
\n

spec.selector.matchLabels.app: Specify the deployment label on which this configuration will be applied.

\n

spec.mtls.mode: TLS mode. STRICT being the connection will always be mutual tls.

\n

PeerAuthentication can be applied to a whole namespace. This is useful when all the services in the namespace are part of the mesh.

\n
\n

Apply the same configuration for virutalservice, destination, and peerauthentication by replacing demo-1 with demo-2 assuming both services are in the same namespace.

\n
\n
kubectl apply -f <file>.yaml -n test
\n

Access the objects:

\n
kubectl get virtualservices -n pbdp\nkubectl get gateways -n pbdp\nkubectl get destinationrule -n pbdp\nkubectl get peerauthentication -n pbdp
\n

Now update the env for demo-2 with demo-2.test.svc.cluster.local in demo-1 service.

\n","frontmatter":{"date":"January 22, 2021","updated_date":null,"title":"How to Install and Configure Istio","tags":["Istio","Service Mesh"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/ee604/Istio.png","srcSet":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/69585/Istio.png 200w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/497c6/Istio.png 400w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/ee604/Istio.png 800w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/db955/Istio.png 900w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Piyush Kumar","github":"kpiyush17","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/istio-service-mesh/"},"html":"

What is Istio?

\n

Istio is an Open Source service mesh (developed in partnership between teams from Google, IBM, and Lyft), providing a dedicated infrastructure layer for creating service-to-service communication that is safe, fast, and reliable. Having such a fanatical communication layer can provide various advantages, like providing observability into communications, providing secure connections, or automating retries and backoff for failed requests.

\n

A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

\n

Istio does this by adding a sidecar proxy which intercepts all network communication between microservices, then configures and manages Istio using its control plane functionality, which incorporates:

\n
    \n
  1. Granular control over the service-to-service communication and its routing with the additional functionality of retries, fault injection, circuit breakers.
    2. \n
  2. Providing secure mTLS without any changes in the application code.
    3. \n
  3. Cluster to cluster communication using ingress and egress gateways.
    4. \n
\n

Istio Architecture

\n

An Istio service mesh is logically split into a data plane and a control plane.

\n

The data plane is composed of Envoy proxy deployed as sidecars. Envoy itself is an L7 proxy and communication bus designed for modern microservices-based architecture. These proxies intercept and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.

\n

The control plane manages and configures the proxies to route traffic.

\n

\"Istio

\n

Istio Core Components

\n

Pilot

\n

Istio Pilot manages and configures all the Envoy proxy instances deployed. It takes the rules for traffic behavior provided by the control plane and converts them into configurations applied by Envoy.

\n

Citadel

\n

Responsible for controlling the authentication and identity management between services. Allow developers to build a zero-trust network based on service identity.

\n

Mixer

\n

Responsible for enforcing access control and usage policies across the service mesh and collects telemetry data from the Envoy proxy and other services.

\n

Istio Features

\n

Traffic Management

\n

It is the basic feature of Istio, which facilitates the routing between services. Istio simplifies the configuration of service-level properties like circuit breakers, timeouts, and retries.\nAll traffic that your mesh services send and receive (data plane traffic) is proxied through Envoy, making it easy to direct and control traffic around your mesh without making any changes to your services.

\n

For discovering all the services in the ecosystem, Istio connects to the Service discovery System and populates its service registry. The Envoy sidecar proxy then uses this registry to route traffic to the correct service.

\n

Here are a few resources you can add for your deployment apart from the basic service discovery and load balancing:

\n

Virtual Services

\n

Virtual services play a key role in making Istio's traffic management flexible and powerful. They do this by strongly decoupling where clients send their requests from the destination workloads that actually implement them.
\nSo, instead of sending requests directly to a service data plane, you send traffic through this virtual service. Using virtual service, you can route requests to different versions of the same service or different hostnames based on particular endpoints. This helps us to do various other things like A/B testing or doing canary rollouts.

\n

A typical example:

\n
apiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n  name: bookinfo\nspec:\n  hosts:\n    - bookinfo.com\n  http:\n  - match:\n    - uri:\n        prefix: /reviews\n    route:\n    - destination:\n        host: reviews  <-- Resolves to reviews.<namespace>.svc.cluster.local\n  - match:\n    - uri:\n        prefix: /ratings\n    route:\n    - destination:\n        host: ratings
\n

Destination Rule

\n

We use destination rules to configure what happens to traffic for that destination. Destination rules are applied after virtual service routing rules are evaluated, so they apply to the traffic's real destination.
\nUsing destination rules, we specify the subsets of the service using labels, which are then used by the virtual service to route requests to a particular subset. In addition to that, we can also customize traffic policy, load balancing policy, connection pool settings, mTLS, etc.

\n
apiVersion: networking.istio.io/v1alpha3\nkind: DestinationRule\nmetadata:\n  name: my-destination-rule\nspec:\n  host: my-svc\n  trafficPolicy:\n    loadBalancer:\n      simple: RANDOM\n  subsets:\n  #### This will work only if we have defined version label in the deployment\n  - name: v1\n    labels:\n      version: v1\n  - name: v2\n    labels:\n      version: v2\n    trafficPolicy:\n      loadBalancer:\n        simple: ROUND_ROBIN\n  - name: v3\n    labels:\n      version: v3
\n

Here we have defined destination rule for service my-svc and defined subsets and traffic policy global and per subset.

\n

Gateway

\n

It is used to manage inbound and outbound traffic for your mesh, letting you specify which traffic you want to enter or leave the mesh. Gateway configurations are applied to standalone Envoy proxies running at the edge of the mesh, rather than sidecar Envoy proxies running alongside your service workloads. Using this, we can expose our services to the internet.

\n

A typical example would be:

\n
apiVersion: networking.istio.io/v1alpha3\nkind: Gateway\nmetadata:\n  name: my-svc-gateway\n  namespace: test\nspec:\n  selector:\n    istio: ingressgateway\n  servers:\n  - port:\n      number: 80\n      name: http\n      protocol: HTTP\n    hosts:\n    - my-svc.example.com
\n

istio: ingressgateway is the gateway which is enabled by default after installation. We can create our custom gateway. Here, the hosts my-svc.example.com will resolve to the load balancer provided by the Istio by default. To use this gateway, one has to add config in the virtual service like for example:

\n
apiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n  name: my-svc\nspec:\n  hosts:\n  - my-svc\n  - my-svc.example.com   <-- The host should match\n  gateways:               <--- gateway config\n    - my-svc-gateway\n  http:\n  - route:\n    - destination:\n        host: my-svc.test.svc.cluster.local\n        port:\n          number: 80
\n

Network Resilience

\n

This feature provides network configuration dynamically at runtime, which includes retries, fault injection, circuit breakers, and timeouts.

\n

Service Entries

\n

This object is used to add an external service as part of the service mesh, including a service running in a VM or other K8s cluster in case of multi-cluster installation.

\n

A typical example would be connecting a service to a database cluster that is not part of the mesh.

\n
apiVersion: networking.istio.io/v1alpha3\nkind: ServiceEntry\nmetadata:\n  name: elasticsearch\n  namespace: test\nspec:\n  hosts:\n  - elasticsearch.elasticsearch.svc.cluster.local\n  location: MESH_INTERNAL\n  ports:\n  - name: https\n    number: 9200\n    protocol: TCP\n  resolution: DNS
\n

The Service Entry should be in the same namespace as that of the calling service. This is helpful, especially in the case where the service is not exposed to a public endpoint and can be accessed using internal service DNS like the above example.

\n

Security

\n

Istio provides security features that will help us to establish a zero-trust network. Istio enables security by default and provides various authentication and authorization policy to regulate security.

\n

For example:

\n
apiVersion: security.istio.io/v1beta1\nkind: PeerAuthentication\nmetadata:\n  name: dsl-es\n  namespace: pdp-test\nspec:\n  selector:\n    matchLabels:\n      app: dsl-es\n  mtls:\n    mode: STRICT
\n

Here we define a peer authentication object for a service labeled my-svc, which tells that any service that needs to talk to my-svc will communicate using mtls. The service will accept only TLS connection. By default, Istio enables PERMISSIVE mode, which accepts both plaintext and encrypted communication.

\n

We can define peer authentication on the mesh, namespace, and pod level.

\n

That is all for the introduction to Istio. In the next part, we will look at installing Istio and configuring services to use Istio.

\n","frontmatter":{"date":"December 07, 2020","updated_date":null,"title":"Istio Service Mesh: A Beginners Guide","tags":["Istio","Service Mesh"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/ee604/Istio.png","srcSet":"/static/452f4d9f7cb358e3d6224ed3aba3d5d6/69585/Istio.png 200w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/497c6/Istio.png 400w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/ee604/Istio.png 800w,\n/static/452f4d9f7cb358e3d6224ed3aba3d5d6/db955/Istio.png 900w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Piyush Kumar","github":"kpiyush17","avatar":null}}}},{"node":{"fields":{"slug":"/engineering/service-mesh-with-envoy/"},"html":"

This post will cover a demo working setup of a service mesh architecture using Envoy using a demo application. In this service mesh architecture, we will be using Envoy proxy for both control and data plane. The setup is deployed in a Kubernetes cluster using Amazon EKS.

\n

Pre-requisites

\n

We will be deploying an echo-grpc test application provided by Google in their article related to gRPC load balancing and was used as a reference to test the service mesh setup with Envoy. The article covers setting up Envoy as an edge proxy only.\nThis is a simple gRPC application that exposes a unary method that takes a string in the content request field and responds with the content unaltered.\nRepo: grpc-gke-nlb-tutorial

\n\n

Sidecar Deployment

\n

Configuration of envoy for the sidecar deployment:

\n

envoy-echo.yaml:

\n
apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: envoy-echo\ndata:\n  envoy.yaml: |\n    static_resources:\n      listeners:\n      - address:\n          socket_address:\n            address: 0.0.0.0\n            port_value: 8786\n        filter_chains:\n        - filters:\n          - name: envoy.http_connection_manager\n            config:\n              access_log:\n              - name: envoy.file_access_log\n                config:\n                  path: "/dev/stdout"\n              codec_type: AUTO\n              stat_prefix: ingress_https\n              route_config:\n                name: local_route\n                virtual_hosts:\n                - name: https\n                  domains:\n                  - "*"\n                  routes:\n                  - match:\n                      prefix: "/api.Echo/"\n                    route:\n                      cluster: echo-grpc\n              http_filters:\n              - name: envoy.health_check\n                config:\n                  pass_through_mode: false\n                  headers:\n                  - name: ":path"\n                    exact_match: "/healthz"\n                  - name: "x-envoy-livenessprobe"\n                    exact_match: "healthz"\n              - name: envoy.router\n                config: {}\n      clusters:\n      - name: echo-grpc\n        connect_timeout: 0.5s\n        type: STATIC\n        lb_policy: ROUND_ROBIN\n        http2_protocol_options: {}\n        load_assignment:\n          cluster_name: echo-grpc\n          endpoints:\n          - lb_endpoints:\n            - endpoint:\n                address:\n                  socket_address:\n                    address: "127.0.0.1"\n                    port_value: 8081\n        health_checks:\n          timeout: 1s\n          interval: 10s\n          unhealthy_threshold: 2\n          healthy_threshold: 2\n          grpc_health_check: {}\n    admin:\n      access_log_path: "/dev/stdout"\n      address:\n        socket_address:\n          address: 127.0.0.1\n          port_value: 8090
\n

A couple things to note here.

\n\n

Run:\nkubectl apply -f envoy-echo.yaml -n envoy

\n

Deployment of echo-grpc application with 3 replicas. The config contains two containers, one for application and another being the Envoy image.

\n
apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: echo-grpc\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: echo-grpc\n  template:\n    metadata:\n      labels:\n        app: echo-grpc\n    spec:\n      containers:\n      - name: echo-grpc\n        image: <hub-username>/echo-grpc\n        imagePullPolicy: Always\n        resources: {}\n        env:\n        - name: "PORT"\n          value: "8081"\n        ports:\n        - containerPort: 8081\n        readinessProbe:\n          exec:\n            command: ["/bin/grpc_health_probe", "-addr=:8081"]\n          initialDelaySeconds: 1\n        livenessProbe:\n          exec:\n            command: ["/bin/grpc_health_probe", "-addr=:8081"]\n          initialDelaySeconds: 1\n      - name: envoy\n        image: envoyproxy/envoy:v1.9.1\n        resources: {}\n        ports:\n        - name: https\n          containerPort: 443\n        volumeMounts:\n        - name: config\n          mountPath: /etc/envoy\n      volumes:\n        - name: config\n          configMap:\n            name: envoy-echo
\n

Here, echo-grpc is test application and envoy is being deployed in the same pod. Config volumes are mounted so that the envoy can read the configmaps.

\n

Run:\nkubectl apply -f echo-deployment.yaml -n envoy

\n

Headless Service Configuration

\n

We are using headless service for echo-grpc. Using service as headless will expose the Pods IP to the DNS server of kubernetes which will be used by Envoy to do service discovery for the pods.

\n

echo-service.yaml

\n
apiVersion: v1\nkind: Service\nmetadata:\n  name: echo-grpc\nspec:\n  type: ClusterIP\n  clusterIP: None\n  selector:\n    app: echo-grpc\n  ports:\n  - name: http2-echo\n    protocol: TCP\n    port: 8786\n  - name: http2-service\n    protocol: TCP\n    port: 8081
\n

In the above config file, we are exposing two ports, one for envoy sidecar (this is the same port we mentioned in the config map of sidecar envoy) and one for the service itself.

\n

Run:\nkubectl apply -f echo-service.yaml -n envoy

\n

Front Envoy Configuration

\n

Creating a service of type LoadBalancer so that client can access the backend service.

\n

envoy-service.yaml:

\n
apiVersion: v1\nkind: Service\nmetadata:\n  name: envoy\nspec:\n  type: LoadBalancer\n  selector:\n    app: envoy\n  ports:\n  - name: https\n    protocol: TCP\n    port: 443\n    targetPort: 443
\n

Creating self-signed certificates

\n

Run:\nkubectl apply -f envoy-service.yaml -n envoy

\n

Since we are deploying front envoy LoadBalancer on port 443, we have to create a self-signed certificate to make it terminate SSL/TLS connection.

\n\n

Edge Envoy configuration

\n

Configuration for the edge Envoy:

\n

envoy-configmap.yaml

\n
apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: envoy-conf\ndata:\n  envoy.yaml: |\n    static_resources:\n      listeners:\n      - address:\n          socket_address:\n            address: 0.0.0.0\n            port_value: 443\n        filter_chains:\n        - filters:\n          - name: envoy.http_connection_manager\n            config:\n              access_log:\n              - name: envoy.file_access_log\n                config:\n                  path: "/dev/stdout"\n              codec_type: AUTO\n              stat_prefix: ingress_https\n              route_config:\n                name: local_route\n                virtual_hosts:\n                - name: https\n                  domains:\n                  - "*"\n                  routes:\n                  - match:\n                      prefix: "/api.Echo/"\n                    route:\n                      cluster: echo-grpc\n              http_filters:\n              - name: envoy.health_check\n                config:\n                  pass_through_mode: false\n                  headers:\n                  - name: ":path"\n                    exact_match: "/healthz"\n                  - name: "x-envoy-livenessprobe"\n                    exact_match: "healthz"\n              - name: envoy.router\n                config: {}\n          tls_context:\n            common_tls_context:\n              tls_certificates:\n              - certificate_chain:\n                  filename: "/etc/ssl/envoy/tls.crt"\n                private_key:\n                  filename: "/etc/ssl/envoy/tls.key"\n      clusters:\n      - name: echo-grpc\n        connect_timeout: 0.5s\n        type: STRICT_DNS\n        lb_policy: ROUND_ROBIN\n        http2_protocol_options: {}\n        load_assignment:\n          cluster_name: echo-grpc\n          endpoints:\n          - lb_endpoints:\n            - endpoint:\n                address:\n                  socket_address:\n                    address: echo-grpc.envoy.svc.cluster.local\n                    port_value: 8786\n        health_checks:\n          timeout: 1s\n          interval: 10s\n          unhealthy_threshold: 2\n          healthy_threshold: 2\n          grpc_health_check: {}\n    admin:\n      access_log_path: "/dev/stdout"\n      address:\n        socket_address:\n          address: 127.0.0.1\n          port_value: 8090
\n

Since we will be offloading HTTPS, we are using port_value of 443. Most of the configurations are same as of sidecar envoy except for three things:

\n\n

Run:\nkubectl apply -f envoy-configmap.yaml -n envoy

\n

Deployment Configuration

\n

envoy-deployment.yaml

\n
apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: envoy\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      app: envoy\n  template:\n    metadata:\n      labels:\n        app: envoy\n    spec:\n      containers:\n      - name: envoy\n        image: envoyproxy/envoy:v1.9.1\n        resources: {}\n        ports:\n        - name: https\n          containerPort: 443\n        volumeMounts:\n        - name: config\n          mountPath: /etc/envoy\n        - name: certs\n          mountPath: /etc/ssl/envoy\n        readinessProbe:\n          httpGet:\n            scheme: HTTPS\n            path: /healthz\n            httpHeaders:\n            - name: x-envoy-livenessprobe\n              value: healthz\n            port: 443\n          initialDelaySeconds: 3\n        livenessProbe:\n          httpGet:\n            scheme: HTTPS\n            path: /healthz\n            httpHeaders:\n            - name: x-envoy-livenessprobe\n              value: healthz\n            port: 443\n          initialDelaySeconds: 10\n      volumes:\n      - name: config\n        configMap:\n          name: envoy-conf\n      - name: certs\n        secret:\n          secretName: envoy-certs
\n

Run:\nkubectl apply -f envoy-deployment.yaml -n envoy

\n

Testing

\n

Proto file for the echo-grpc service:

\n

ccho.proto:

\n
syntax = "proto3";\n\npackage api;\n\nservice Echo {\n  rpc Echo (EchoRequest) returns (EchoResponse) {}\n}\n\nmessage EchoRequest {\n  string content = 1;\n}\n\nmessage EchoResponse {\n  string content = 1;\n}
\n

Run the following command to call the server:\ngrpcurl -d '{\"content\": \"echo\"}' -proto echo.proto -insecure -v <load_balancer_or_external_ip>:443 api.Echo/Echo

\n

The output will be similar to something like this:

\n
Resolved method descriptor:\nrpc Echo ( .api.EchoRequest ) returns ( .api.EchoResponse );\n\nRequest metadata to send:\n(empty)\n\nResponse headers received:\ncontent-type: application/grpc\ndate: Wed, 27 Feb 2019 04:40:19 GMT\nhostname: echo-grpc-5c4f59c578-wcsvr\nserver: envoy\nx-envoy-upstream-service-time: 0\n\nResponse contents:\n{\n  "content": "echo"\n}\n\nResponse trailers received:\n(empty)\nSent 1 request and received 1 response
\n

Run the above command multiple times and check the value of the hostname field every time which will contain the pod name of one of the 3 pods deployed.

\n

References

\n\n","frontmatter":{"date":"July 06, 2020","updated_date":null,"title":"Service Mesh with Envoy","tags":["Service Mesh","Envoy","Microservices"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.834862385321101,"src":"/static/f5fbebaefd091eb3f33c225fa71b0814/14b42/front-image.jpg","srcSet":"/static/f5fbebaefd091eb3f33c225fa71b0814/f836f/front-image.jpg 200w,\n/static/f5fbebaefd091eb3f33c225fa71b0814/2244e/front-image.jpg 400w,\n/static/f5fbebaefd091eb3f33c225fa71b0814/14b42/front-image.jpg 800w,\n/static/f5fbebaefd091eb3f33c225fa71b0814/47498/front-image.jpg 1200w,\n/static/f5fbebaefd091eb3f33c225fa71b0814/0e329/front-image.jpg 1600w,\n/static/f5fbebaefd091eb3f33c225fa71b0814/6ed45/front-image.jpg 2100w","sizes":"(max-width: 800px) 100vw, 800px"}}},"author":{"id":"Piyush Kumar","github":"kpiyush17","avatar":null}}}}]}},"pageContext":{"tag":"Service Mesh"}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}