Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

lahabana
Copy link
Contributor

@lahabana lahabana commented Oct 10, 2024

Have a central concepts page to link from there to different other pages.

Change pages to make policies intro docs simpler

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>
@lahabana lahabana requested a review from a team as a code owner October 10, 2024 14:59
@lahabana lahabana requested review from Automaat and bartsmykla and removed request for a team October 10, 2024 14:59
Copy link

netlify bot commented Oct 10, 2024

Deploy Preview for kuma ready!

Name Link
🔨 Latest commit 4ffae7e
🔍 Latest deploy log https://app.netlify.com/sites/kuma/deploys/67092448cf89ed0008415b31
😎 Deploy Preview https://deploy-preview-1956--kuma.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 89 (🟢 up 6 from production)
Accessibility: 90 (no change from production)
Best Practices: 100 (no change from production)
SEO: 85 (no change from production)
PWA: 80 (no change from production)
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

Signed-off-by: Charly Molter <charly.molter@konghq.com>
Signed-off-by: Charly Molter <charly.molter@konghq.com>

In this page we will introduce concepts that are core to understanding Kuma.

## Control-Plane
Copy link
Contributor

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.
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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).
Copy link
Contributor

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
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants