-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(policies): rework intro page and add concepts #1956
base: master
Are you sure you want to change the base?
Conversation
Have a central concepts page to link from there to different other pages. Change pages to make policies intro docs simpler Signed-off-by: Charly Molter <charly.molter@konghq.com>
✅ Deploy Preview for kuma ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Charly Molter <charly.molter@konghq.com>
|
||
In this page we will introduce concepts that are core to understanding Kuma. | ||
|
||
## Control-Plane |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no reason to use a hyphen here
|
||
The data-plane handles traffic between services. | ||
It connects to the control-plane which computes a configuration specific to it. | ||
The Data-Plane proxy or Sidecar is the instance of Envoy running alongside the data-plane which will send and receive traffic from the rest of the service mesh. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or capitalize these words
|
||
Like all [resources](/docs/{{ page.version }}/introduction/concepts#resource) in {{ site.mesh_product_name }}, there are two parts to a policy: | ||
|
||
1. The metadata |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo this list while reading is very bold and grabs your eye for relatively little information content. I think it can be an inline sentence and then we have the sections.
``` | ||
|
||
{% warning %} | ||
Policies are namespaced scope and currently the namespace must be the one the control-plane is running in `{{site.mesh_namespace}}` by default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Policies are namespaced scope and currently the namespace must be the one the control-plane is running in `{{site.mesh_namespace}}` by default. | |
Policies are namespace-scoped and currently the namespace must be the one the control-plane is running in. This is `{{site.mesh_namespace}}` by default. |
Some policies apply to only a subset of the configuration of the proxy. | ||
|
||
- **Inbound policies** apply only to incoming traffic. The `spec.from[].targetRef` field defines the subset of clients that are going to be impacted by this policy. | ||
- **Outbound policies** apply only to outgoing traffic. The `spec.to[].targetRef` field defines the outbounds that are going to be impacted by this policy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"outbounds" as a concept IMO isn't widely defined, we should use "destinations" or similar, like "clients" in the line above.
- **Inbound policies** apply only to incoming traffic. The `spec.from[].targetRef` field defines the subset of clients that are going to be impacted by this policy. | ||
- **Outbound policies** apply only to outgoing traffic. The `spec.to[].targetRef` field defines the outbounds that are going to be impacted by this policy | ||
|
||
The actual configuration is defined in a `default` map. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The actual configuration is defined in a `default` map. | |
The actual configuration is defined under the `default` field. |
|
||
## Writing a `targetRef` | ||
|
||
`targetRef` is a concept borrowed from [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) its usage is fully defined in [MADR 005](https://github.com/kumahq/kuma/blob/master/docs/madr/decisions/005-policy-matching.md). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this MADR useful/even up to date to link here?
name: "my-name" # For kinds MeshService, and MeshGateway a name has to be defined | ||
tags: | ||
key: value # For kinds MeshSubset and MeshGateway a list of matching tags can be used | ||
proxyTypes: ["Sidecar", "Gateway"] # For kinds Mesh and MeshSubset a list of matching Dataplanes types can be used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
labels
is missing
The `spec.from[].targetRef` section enables logging for any traffic coming from _anywhere_ in the `Mesh`. | ||
|
||
### Omitting `targetRef` | ||
When a `targetRef` is not present. It is semantically equivalent to: `targetRef.kind: Mesh` meaning everything inside the mesh. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a `targetRef` is not present. It is semantically equivalent to: `targetRef.kind: Mesh` meaning everything inside the mesh. | |
When a `targetRef` is not present. It is semantically equivalent to `targetRef.kind: Mesh`, meaning everything inside the `Mesh`. |
``` | ||
|
||
There is however, one exception to this when using `MeshService` with **outbound** policies (policies with `spec.to[].targetRef`). | ||
In this case, if you define a policy in the same namespace as the `MeshService` it is defined in a policy will be considered to be a **producer** policy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, if you define a policy in the same namespace as the `MeshService` it is defined in a policy will be considered to be a **producer** policy. | |
In this case, if you define a policy in the same namespace as the `MeshService` it is defined in, that policy will be considered a **producer** policy. |
Have a central concepts page to link from there to different other pages.
Change pages to make policies intro docs simpler