Skip to content

Magic City DevOps

FQDN Field Validation with Pydantic

The Problem

Customers were configuring egress entries for external services using incorrect syntax. This would lead to validation errors from Istio when deploying microservice CRDs, so the controller that manages the CRD's owned resources would then begin generating errors when attempting to update resources that Istio's validatingwebhook would reject:

microserviceDeployment.yaml
...
DeploymentStrategy:
  ServiceDependencies:
    egress:
    - hosts:
      - external/some-external-serviceentry # (1)
...
  1. When the CRD is applied, various Istio resources are generated. Istio's DestinationRule resource expects host values that reference ServiceEntry resources to be formatted as namespace/service-entry-name.namespace.svc.cluster.local.

The microservice pipeline would validate that the field contained a list of strings:

src/service_dependency_schema.py
from pydantic import BaseModel, parse_obj_as
from Faker import Faker
from faker.providers import python
import pytest

class Egress(BaseModel, extra="forbid"):
    port: Optional[Port]
    hosts: list[str]


fake = Faker()
fake.add_provider(python)


@pytest.fixture
def egress_data():
    return {"hosts": [pystr()]}


def test_egress_schema(egress_data):
    # when
    parsed = parse_obj_as(Egress, egress_data)

    # then
    assert isinstance(parsed.hosts, list)
    assert isinstance(parsed.hosts[0], str)

GitOps with Istio and ArgoCD

Managing Istio can be tough. Some years ago Istio 1.4.x was deployable via Helm, but was hard to manage desired state because of the massive microservice sprawl. Later on, Istio packaged the control plane services into a single istiod instance, and even provided support for Operator style deployments and an easy to use cli tool called istioctl. As of the time of this writing, Istio has deprecated Operator based deployments due to issues with webhook configurations that improperly register with the control plane.

Exploring Canary Upgrades with Istio Ambient Mesh

Ambient Mesh leverages eBPF to reduce resource usage of Istio's data plane components. It eliminates the need for sidecar proxies because eBPF leverages the kernel network layer of worker nodes for mesh traffic management. The goal of this guide is to answer the following:

  1. What are the core components of Ambient Mesh?
  2. Which components are scoped to the kernel network layer
  3. Which components are scoped to the Kubernetes network layer?
  4. How does a canary upgrade of the Istio control plane work with Ambient Mesh?