istio

GCP: Cloud Run/Function to handle requests to GKE cluster during maintenance

At some point, there will be a system change significant enough that a maintenance window needs to be scheduled with customers.   But that doesn’t mean the end-user traffic or client integrations will stop requesting the services. What we need to present to end-users is a maintenance page during this outage to indicate the overall solution GCP: Cloud Run/Function to handle requests to GKE cluster during maintenance

GCP: Enable HttpLoadBalancing feature on Cluster to avoid errors when applying BackEndConfig

If you are configuring Istio/ASM ingress gateways with a BackendConfig for specifying health checks, timeouts, or Cloud Armor policies, then you need to ensure that your GKE cluster has the HttpLoadBalancing feature enabled. If this feature is not enabled, you will see an error message like below when attempting to apply the BackendConfig manifest: unable GCP: Enable HttpLoadBalancing feature on Cluster to avoid errors when applying BackEndConfig

Istio: Canary upgrade of Operator from Istio 1.8 directly to 1.10

Istio announced it will support upgrades jumping directly from 1.8 to 1.10, instead of forcing an intermediate upgrade through 1.9. In this article, I will show you how to do a canary upgrade from a 1.8 operator to 1.10 operator without affecting end user traffic.  We will incorporate the new 1.10 concept of revision tags Istio: Canary upgrade of Operator from Istio 1.8 directly to 1.10

Istio: Upgrading from Istio 1.7 operator without revision to fully revisioned control plane

Istio 1.7 has the ability to do canary upgrades for revisioned control planes and operators, but if you did your initial installation without the ‘revision’ flag, then you’ll need to apply these settings. In this article, I will show you how to go from an non-revisioned 1.7.5 Istio operator and control plane to a 1.7.5 Istio: Upgrading from Istio 1.7 operator without revision to fully revisioned control plane

Istio: Upgrading from Istio 1.6 operator without revision to 1.7 fully revisioned control plane

Istio has the ability to do canary upgrades for revisioned control planes, but it was only in 1.7 that the Operator itself got  support for the ‘revision’ flag. In this article, I will show you how to go from an non-revisioned 1.6.6 Istio operator and control plane to a 1.7 revisioned operator and control plane Istio: Upgrading from Istio 1.6 operator without revision to 1.7 fully revisioned control plane

Kubernetes: K3s with multiple Istio ingress gateways

By default, K3s uses the Traefik ingress controller and Klipper service load balancer to expose services.  But this can be replaced with a MetalLB load balancer and Istio ingress controller. K3s is perfectly capable of handling Istio operators, gateways, and virtual services if you want the advanced policy, security, and observability offered by Istio. In Kubernetes: K3s with multiple Istio ingress gateways

Kubernetes: microk8s with multiple Istio ingress gateways

microk8s has convenient out-of-the-box support for MetalLB and an NGINX ingress controller.  But microk8s is also perfectly capable of handling Istio operators, gateways, and virtual services if you want the advanced policy, security, and observability offered by Istio. In this article, we will install the Istio Operator, and allow it to create the Istio Ingress Kubernetes: microk8s with multiple Istio ingress gateways

Kubernetes: testing pod communication directly from istio sidecar proxy

Once you introduce an istio sidecar proxy into your deployment, it becomes another point at which you might need to troubleshoot network connectivity to the primary container. Assuming you have deployed a pod with an app label “helloworld” in the default namespace listening on port 5000, you can use a command like the following to Kubernetes: testing pod communication directly from istio sidecar proxy

Kubernetes: istio Gateway in a different namespace than VirtualService

If your istio ingress Gateway is in a different namespace than your VirtualService, then you need to make sure you prefix the gateway reference with that namespace. For example, if your istio ingress Gateway is in the ‘default’ namespace, yet your Deployment, Service, and VirtualService are in the namespace ‘helloworld’. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: Kubernetes: istio Gateway in a different namespace than VirtualService