I got a question on how we can restrict access to certain external endpoints on a per namespace basis. There was an idea to use Istio’s egress gateway to control access to external endpoints, though I’m not convinced that’s a valid use case for an egress gateway today. So I went off to do some investigation, and found some options: Specifying which namespaces can access certain hosts defined in the ServiceEntry Specifying which endpoints can be accessed from a namespace But before that, a bit of back story of how we got here…

In this post, we will be testing Istio’s ServiceEntry by accessing a PostgreDB database hosted externally from the Kubernetes cluster. Setup “External” PostgresDB service Since we are running the Kubernetes cluster locally in Docker containers using k3d, we can create an “external” service by running a PostgresDB Docker container on the same host and expose its ports to localhost. Create a local PostgresDB container database using Docker docker run --name postgres --restart always -e POSTGRES_PASSWORD=password -d -p 5432:5432 postgres Create a test database app_db

In the previous post, we deployed the Bookinfo application on a k3s cluster with Istio enabled. In this post, we will explore the features on Istio Ingress. Kubernetes Ingress Istio should handle Kubernetes Ingress resource just fine as documented here. Here we create a Kubernetes Ingress to access the Bookinfo application. Note the additional annotation kubernetes.io/ingress.class: istio: kubectl -n bookinfo apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.

In this series, we will be testing out several features in Istio with a local Kubernetes (k3s) cluster. Deploy k3s cluster First step is to deploy the k8s cluster with k3d - a wrapper to run k3s in docker. Start by creating a k3d config file: # k3d-istio.yaml apiVersion: k3d.io/v1alpha2 kind: Simple name: istio servers: 1 agents: 2 ports: # for exposing Istio ingress on localhost - port: 8080:80 nodeFilters: - loadbalancer - port: 8443:443 nodeFilters: - loadbalancer options: k3s: extraServerArgs: - --no-deploy=traefik # we will be using Istio ingress instead Deploy the cluster with k3d

In this article, I will be using the process of building a house as an example to explain how Kubernetes Custom Resources work. Imagine building a custom home, which is a highly detailed and laborious work, that you decided to just hire a home builder. The builder gives you a form to fill out details such as: how many rooms do you need and what size should they be?