Producer and Consumer policies

With namespace scoped policies in Kuma you can have fine-grained control over policies and how they apply to your workloads. Moreover, this empowers app owners to take advantage of Kubernetes RBAC for policy configuration.

To fully utilize power of namespace scoped policies we need to get familiar with producer consumer model. This guide will help you get comfortable with producer consumer model.

Prerequisites

  • Completed quickstart to set up a zone control plane with demo application

Basic setup

In order to be able to fully utilize namespace scoped policies you need to use MeshService. To make sure that traffic works in our examples let’s configure MeshTrafficPermission to allow all traffic:

  1. echo "apiVersion: kuma.io/v1alpha1
  2. kind: MeshTrafficPermission
  3. metadata:
  4.   namespace: kuma-demo
  5.   name: mtp
  6. spec:
  7.   targetRef:
  8.     kind: Mesh
  9.   from:
  10.     - targetRef:
  11.         kind: Mesh
  12.       default:
  13.         action: Allow" | kubectl apply -f -

To finish the setup we need to create two additional namespaces with sidecar injection for clients we will be using to communicate with our demo-app:

  1. echo "apiVersion: v1
  2. kind: Namespace
  3. metadata:
  4.   name: first-consumer
  5.   labels:
  6.     kuma.io/sidecar-injection: enabled
  7. ---
  8. apiVersion: v1
  9. kind: Namespace
  10. metadata:
  11.   name: second-consumer
  12.   labels:
  13.     kuma.io/sidecar-injection: enabled" | kubectl apply -f -

Now we can create deployment we will be using to communicate with our demo-app from a first-consumer namespace:

  1. kubectl run consumer --image nicolaka/netshoot -n first-consumer --command -- /bin/bash -c "ping -i 60 localhost"

and from the second-consumer namespace:

  1. kubectl run consumer --image nicolaka/netshoot -n second-consumer --command -- /bin/bash -c "ping -i 60 localhost"

You can make now make a couple of requests to our demo app to check if everything is working:

  1. kubectl exec -n first-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment

You should see something similar to:

  1. {"counter":"1","zone":"local","err":null}

At this moment our setup looks like this:

  2. flowchart LR
  4. subgraph first-consumer-ns
  5.   first-consumer
  6. end
  8. subgraph second-consumer-ns
  9.   second-consumer
  10. end
  12. subgraph kuma-demo-ns
  13.   kuma-demo
  14.   redis
  15. end
  17. kuma-demo --> redis
  18. first-consumer --> kuma-demo
  19. second-consumer --> kuma-demo

Namespace scoped policies

Now that we have our setup we can start playing with policies. Let’s create a simple MeshTimeout policy in kuma-demo namespace:

  1. echo "apiVersion: kuma.io/v1alpha1
  2. kind: MeshTimeout
  3. metadata:
  4.   name: producer-timeout
  5.   namespace: kuma-demo
  6.   labels:
  7.     kuma.io/mesh: default
  8.     kuma.io/origin: zone
  9. spec:
  10.   to:
  11.     - targetRef:
  12.         kind: MeshService
  13.         name: demo-app
  14.       default:
  15.         http:
  16.           requestTimeout: 1s" | kubectl apply -f -

We can now inspect applied policy labels:

  1. kubectl get meshtimeout -n kuma-demo producer-timeout -o jsonpath='{.metadata.labels}'

We should see output like:

  1. {
  2.   "k8s.kuma.io/namespace": "kuma-demo",
  3.   "kuma.io/env": "kubernetes",
  4.   "kuma.io/mesh": "default",
  5.   "kuma.io/origin": "zone",
  6.   "kuma.io/policy-role": "producer",
  7.   "kuma.io/zone": "default"
  8. }

Kuma is adding custom labels to our policy. The one that interests us most at the moment is kuma.io/policy-role. This label indicates the policy role. Possible values of this label are:

  • system - policies applied in system namespace
  • workload-owner - policies that don’t specify spec.from and spec.to sections or specify only spec.from section
  • consumer - policies targeting MeshServices from different namespace in spec.to section or targeting MeshService by labels
  • producer - policies defined in the same namespace as the MeshService they are targeting in their spec.to[].

Producer consumer model

With namespace scoped policies we’ve introduced a producer/consumer model for policies.

A producer is someone who authors and operates a service. A producer can create policies that will be applied by default to any communication with their services. Producer policies will be created in the same namespace as MeshService they target. Producer policies will be synced to other zones.

A consumer is the client of a service. Consumer policies will be applied in the consumer namespace and may target MeshService from different namespaces. Consumer policies take effect only in the consumer namespace. Consumer policies will override producer policies.

Testing producer policy

To test MeshTimeout that we’ve applied in previous steps we need to simulate delays on our requests. To do this we need add header x-set-response-delay-ms to our requests.

We can now make few requests to our demo-app, and we should see timeouts:

  1. kubectl exec -n first-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

Example output:

  1. upstream request timeout

We should see the same results when making requests from second-consumer namespace:

  1. kubectl exec -n second-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

Output:

  1. upstream request timeout

Producer policy will be applied on all traffic to kuma-demo as we can see on this diagram:

  2. flowchart LR
  4. subgraph first-consumer-ns
  5. first-consumer
  6. end
  8. subgraph second-consumer-ns
  9. second-consumer
  10. end
  12. subgraph kuma-demo-ns
  13. kuma-demo
  14. redis
  15. end
  17. kuma-demo --> redis
  18. first-consumer --producer-timeout--> kuma-demo
  19. second-consumer --producer-timeout--> kuma-demo

Utilizing consumer policy

Until now, we were relying on producer policy created previously. Let’s assume that we don’t mind waiting a little longer for the response from demo-app, and we would like to override the timeout just for our namespace. To do so we need to create new policy:

  1. echo "apiVersion: kuma.io/v1alpha1
  2. kind: MeshTimeout
  3. metadata:
  4.   name: consumer-timeout
  5.   namespace: first-consumer
  6.   labels:
  7.     kuma.io/mesh: default
  8.     kuma.io/origin: zone
  9. spec:
  10.   to:
  11.     - targetRef:
  12.         kind: MeshService
  13.         labels:
  14.           k8s.kuma.io/service-name: demo-app
  15.       default:
  16.         http:
  17.           requestTimeout: 3s" | kubectl apply -f -

When we now make requests from the first-consumer namespace all the requests should succeed, but they will take longer:

  1. kubectl exec -n first-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

We have just applied a consumer policy. The timeout will only be applied in the first-consumer namespace. We can test this by making requests from our second-consumer namespace:

  1. kubectl exec -n second-consumer consumer -- curl -s -XPOST demo-app.kuma-demo:5000/increment -H "x-set-response-delay-ms: 2000"

We should still see timeouts:

  1. upstream request timeout

To better visualize this we can look again at our diagram and see that only traffic from first-consumer will be affected.

  2. flowchart LR
  4. subgraph first-consumer-ns
  5. first-consumer
  6. end
  8. subgraph second-consumer-ns
  9. second-consumer
  10. end
  12. subgraph kuma-demo-ns
  13. kuma-demo
  14. redis
  15. end
  17. kuma-demo --> redis
  18. first-consumer --consumer-timeout--> kuma-demo
  19. second-consumer --producer-timeout--> kuma-demo

What we’ve learnt?

  • How to apply policy on a namespace
  • What are policy roles and what types can you encounter
  • What are producer and consumer policies
  • How producer and consumer policies interact with each other

Next steps