Minikube is a tool that lets you run Kubernetes locally on your machine. Istio is a service mesh that adds a lot of advanced networking features to Kubernetes, like traffic management, security, and observability. Installing Istio on Minikube means you can experiment with these powerful features without needing a full cloud Kubernetes cluster.
Here’s how to get Istio running on Minikube.
First, you need to install Minikube itself. You can download it from the official Minikube website. Once installed, start a Minikube cluster with enough resources for Istio. Istio can be a bit resource-hungry, so allocating more CPU and memory is a good idea.
minikube start --cpus 4 --memory 8192 --disk-size 30g
This command starts a Minikube instance with 4 CPUs, 8GB of RAM, and a 30GB disk. The exact numbers might need tuning depending on your machine’s capabilities and what you plan to do with Istio.
Next, you need to enable the necessary Kubernetes features for Istio. The most important one is the Ingress controller. Istio relies on an Ingress controller to manage external access to your services. Minikube has a built-in Ingress controller that you can enable.
minikube addons enable ingress
After enabling the Ingress addon, you need to ensure your kubectl context is pointing to your Minikube cluster. If you just started Minikube, this is usually handled automatically. You can verify by running:
kubectl config current-context
It should show something like minikube.
Now, you’re ready to install Istio. The easiest way to do this locally is by using istioctl, Istio’s command-line tool. You can download istioctl from the Istio documentation. Once downloaded, you can install Istio with a profile that’s suitable for local development. The demo profile is often a good choice as it includes many Istio components and is configured for ease of use.
istioctl install --set profile=demo
This command downloads the Istio configuration and applies it to your Minikube cluster. It will deploy various Istio components, such as the Istio control plane (Istiod) and the Envoy sidecar proxies. This process can take a few minutes as all the necessary pods are created and started.
After the installation completes, you’ll want to verify that all Istio components are running correctly. You can do this by checking the pods in the istio-system namespace.
kubectl get pods -n istio-system
You should see pods like istiod, istio-ingressgateway, and others related to telemetry and policy, all in a Running state. If any pods are not running, you can check their logs for clues:
kubectl logs <pod-name> -n istio-system
To actually use Istio, you need to "inject" the Istio sidecar proxy into your application pods. This is typically done by labeling the namespace where your application will run. Let’s create a sample namespace for your applications and label it.
kubectl create namespace my-app
kubectl label namespace my-app istio-injection=enabled
This label tells Istio to automatically inject the Envoy sidecar proxy into any new pods created within the my-app namespace. When you deploy an application (e.g., a simple web server) into this namespace, Istio will automatically attach the sidecar, allowing you to manage its traffic.
Now you can deploy a sample application. For instance, a simple HTTP server.
# sample-app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: httpbin
namespace: my-app
spec:
replicas: 1
selector:
matchLabels:
app: httpbin
template:
metadata:
labels:
app: httpbin
spec:
containers:
- name: httpbin
image: kennethreitz/httpbin
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: httpbin
namespace: my-app
spec:
ports:
- port: 8000
targetPort: 80
selector:
app: httpbin
Apply this to your cluster:
kubectl apply -f sample-app.yaml
Because the my-app namespace is labeled for Istio injection, the httpbin pod will be created with both the httpbin container and the Istio Envoy sidecar container. You can verify this by describing the pod:
kubectl get pods -n my-app -o wide
You should see two containers listed for your httpbin pod.
To access your application from outside the cluster, you’ll use the Istio Ingress Gateway. First, get the external IP address of the Minikube Ingress controller.
kubectl get svc istio-ingressgateway -n istio-system
You’ll see an output with an EXTERNAL-IP. If it’s <pending>, run minikube tunnel in a separate terminal. This command keeps a tunnel open to your Minikube cluster, making external IPs accessible. Once you have an IP, you can access your httpbin service.
curl http://<ingress-gateway-ip>:8000/ip
Replace <ingress-gateway-ip> with the actual IP you obtained. This request will go through the Istio Ingress Gateway, then to your httpbin service, and you should receive a response showing the IP address of the Ingress Gateway.
The real power of Istio comes into play when you start configuring its traffic management features. For example, you can define VirtualService and DestinationRule resources to control how traffic is routed to your services, implement canary deployments, or add fault injection.
Consider this VirtualService which routes traffic to httpbin:
# httpbin-vs.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin
namespace: my-app
spec:
hosts:
- httpbin.example.com # This is a virtual host, not tied to DNS
gateways:
- istio-ingressgateway # Link to the Istio Ingress Gateway
http:
- match:
- uri:
prefix: /
route:
- destination:
host: httpbin
port:
number: 8000
Apply it:
kubectl apply -f httpbin-vs.yaml
Now, you can access your httpbin service using the virtual host name httpbin.example.com via the Ingress Gateway IP:
curl -H "Host: httpbin.example.com" http://<ingress-gateway-ip>:8000/headers
This shows how Istio intercepts traffic at the gateway and routes it based on the defined VirtualService. You’re no longer directly hitting the service’s ClusterIP or NodePort; you’re going through Istio’s managed ingress.
The next step you’ll likely encounter is needing to configure more advanced traffic routing rules, such as splitting traffic between different versions of your application, or implementing fault injection for testing resilience.