Skip to main content
Version: 1.51

Configure Divert in Your Cluster

Divert needs a service mesh in each Shared Namespace and a few Okteto Helm values. The service mesh routes the calls between the services of the Shared Namespace, and sends the requests that carry a divert header to the overlay services. Once the cluster is configured with a service mesh, developers can use Divert from their Okteto Manifests, as described in Overlay Namespace.

Talk to us

Service meshes, gateway controllers, and network policies are configured differently in every cluster, and their setup can add steps to enabling Divert. This guide covers the common setups, but we encourage you to talk to us to guide you through the configuration of your cluster.

Requirements​

  • A service mesh that routes east-west traffic, the calls between services, by the baggage header. The cluster gateway controller routes the requests that enter through the endpoints of the Shared Namespace, but it doesn't see the calls between services inside it. Meshes that implement GAMMA, the Gateway API support for service meshes, such as Linkerd and Istio, route those calls with the same HTTPRoute resources
  • The service mesh enabled in each Shared Namespace, with sidecar injection or in sidecar-less mode. Overlay Namespaces don't need it, and you don't need to configure anything for them: Okteto automatically adds the Shared Namespace to the DNS search list of the pods it deploys in an Overlay Namespace. Kubernetes resolves a service name in the pod's own namespace first, so a call by service name reaches the overlay service if it's deployed in the Overlay Namespace, and the shared service otherwise

Drivers​

Okteto supports two drivers to route the requests with a divert header to the overlay services. Choose the one that matches your service mesh:

  • Gateway API: for service meshes that implement the Gateway API, such as Linkerd. Okteto creates the routing rules as Gateway API HTTPRoute resources.
  • VirtualServices: for clusters that use Istio and applications that define their routing with VirtualServices. Okteto adds the routing rules to those VirtualServices.

Gateway API​

The Gateway API driver works with any service mesh that implements GAMMA, the Gateway API support for east-west traffic, such as Linkerd. For each overlay service, Okteto creates an HTTPRoute in the Shared Namespace that sends the requests with the divert header of the Overlay Namespace to the overlay service, and every other request to the shared service. Enable it in your Okteto Helm values:

divert:
enabled: true

The Gateway API CRDs (v1) must be installed in the cluster. Okteto doesn't install them: install them before enabling Divert, following the Gateway API installation guide or the instructions of your service mesh. It's the default driver, so developers don't set any driver in their Okteto Manifest.

VirtualServices​

The VirtualServices driver works with clusters that use Istio, when your applications define their routing with VirtualServices. Okteto adds rules to the VirtualServices of the Shared Namespace that send the requests with the divert header of the Overlay Namespace to the overlay services. Enable it in your Okteto Helm values, instead of divert:

virtualServices:
enabled: true

Developers set driver: istio and the VirtualServices to divert in their Okteto Manifest.

Network Policies​

Divert needs traffic in both directions between a Shared Namespace and its Overlay Namespaces:

  • From the Overlay Namespace to the Shared Namespace: your overlay services call the shared services they don't deploy.
  • From the Shared Namespace to the Overlay Namespace: the service mesh sends requests with your divert header from the shared services to your overlay services.

If you enable networkPolicies in your Okteto Helm values, Okteto applies the rules in networkPolicies.ingress to every Namespace it manages. Add a rule that allows ingress from every Okteto Namespace, which are labeled dev.okteto.com: "true":

networkPolicies:
enabled: true
ingress:
- from:
- namespaceSelector:
matchLabels:
dev.okteto.com: "true"

Because the rule is applied to both the Shared Namespace and the Overlay Namespaces, it allows traffic in both directions.

Shared Namespaces Outside Okteto​

A Shared Namespace can be a namespace that Okteto doesn't manage, in the same cluster. Enable the service mesh in it, as in any Shared Namespace, and configure the following settings. The examples use a namespace named staging.

Access for Developers​

Developers need access to the objects of the Shared Namespace that Divert uses. Create a ClusterRole with access to them:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: okteto-divert-shared
rules:
- apiGroups: [""]
resources: ["services"]
verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
resources: ["ingresses"]
verbs: ["get", "list", "watch"]
- apiGroups: ["gateway.networking.k8s.io"]
resources: ["httproutes", "grpcroutes"]
verbs: ["get", "list", "watch"]
- apiGroups: ["networking.istio.io"]
resources: ["virtualservices"]
verbs: ["get", "list", "watch", "update", "patch"]

Then bind it to every Okteto user in the Shared Namespace with serviceAccounts.extraRoleBindings in your Okteto Helm values:

serviceAccounts:
extraRoleBindings:
staging:
- okteto-divert-shared

Network Policies​

Okteto doesn't apply its network policies to a namespace it doesn't manage, so allow ingress on both sides.

In the Okteto Helm values, allow ingress from the Shared Namespace into the Overlay Namespaces:

networkPolicies:
enabled: true
ingress:
- from:
- namespaceSelector:
matchLabels:
dev.okteto.com: "true"
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: staging

In the Shared Namespace, add a NetworkPolicy that allows ingress from the Okteto Namespaces:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-okteto-namespaces
namespace: staging
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
dev.okteto.com: "true"

Istio VirtualServices​

With Istio VirtualServices, also select the Shared Namespace with virtualServices.namespaceSelector in your Okteto Helm values. Okteto's mutating webhook only receives events from the namespaces it manages, and this setting adds the Shared Namespace, so Okteto can respond to changes in its VirtualServices:

virtualServices:
enabled: true
namespaceSelector:
kubernetes.io/metadata.name: staging