Requirements for Pods and Services
To be a part of the service mesh, pods and services in a Kubernetes cluster must satisfy the following requirements:
Named ports: Service ports must be named. The port names must be of the form
<protocol>[-<suffix>]with http, http2, grpc, mongo, or redis as the
<protocol>in order to take advantage of Istio’s routing features. For example,
name: httpare valid port names, but
name: http2foois not. If the port name does not begin with a recognized prefix or if the port is unnamed, traffic on the port will be treated as plain TCP traffic (unless the port explicitly uses
Protocol: UDPto signify a UDP port).
Service association: If a pod belongs to multiple Kubernetes services, the services cannot use the same port number for different protocols, for instance HTTP and TCP.
Deployments with app and version labels: It is recommended that pods deployed using the Kubernetes
Deploymenthave an explicit
versionlabel in the deployment specification. Each deployment specification should have a distinct
applabel with a value indicating something meaningful, with
versionindicating the version of the app that the particular deployment corresponds to. The
applabel is used to add contextual information in distributed tracing. The
versionlabels are also used to add contextual information in the metric telemetry collected by Istio.
Instructions for installing the Istio sidecar in application pods automatically using the sidecar injector webhook or manually using istioctl CLI.
Instructions to setup a Google Kubernetes Engine cluster for Istio.
Example multicluster between IBM Cloud Kubernetes Service & IBM Cloud Private.
Install minimal Istio using Helm.
Example multicluster IBM Cloud Private install of Istio.
Instructions for integrating VMs and bare metal hosts into an Istio mesh deployed on Kubernetes.