mirror of
https://github.com/kyverno/kyverno.git
synced 2024-12-14 11:57:48 +00:00
Minor changes in dev docs (#11266)
Signed-off-by: Aditya Kumar <aditya.kumar60@infosys.com>
This commit is contained in:
parent
1af0fc5244
commit
bdeb172a7e
5 changed files with 14 additions and 14 deletions
|
@ -39,7 +39,7 @@ Attributes cannot be deleted in a version. They should be marked for deprecation
|
|||
|
||||
## Modifying an attribute
|
||||
|
||||
Attributes cannot be modified in a version. The existing attribute should be marked for deprecation and a new attribute should be added following version compatibity guidelines.
|
||||
Attributes cannot be modified in a version. The existing attribute should be marked for deprecation and a new attribute should be added following version compatibility guidelines.
|
||||
|
||||
|
||||
## Stable References
|
||||
|
|
|
@ -69,7 +69,7 @@ The policy controller processes all adds, deletes, and updates to all installed
|
|||
|
||||
### Reports Controller
|
||||
|
||||
The report controller is responsible for creation of policy reports from both admission requests and background scans and requires leader election. It track resources that need to be processed in the background and generates background scan reports (when policy/resource change). It also aggregates these and the intermediary admission reports into the final policy report resources `PolicyReport` and `ClusterPolicyReport`.
|
||||
The report controller is responsible for creation of policy reports from both admission requests and background scans and requires leader election. It tracks resources that need to be processed in the background and generates background scan reports (when policy/resource change). It also aggregates these and the intermediary admission reports into the final policy report resources `PolicyReport` and `ClusterPolicyReport`.
|
||||
|
||||
#### Background Scan Controller
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ There are several ways to enable/disable features in Golang:
|
|||
2. Container arguments
|
||||
|
||||
## Feature Flags
|
||||
The `toggle` package exists in pkg/toggle can be used to define and manage a feature toggle for a new feature in Kyverno. Lets say we need to introduce a new feature toggle to enable/disable deferred loading. We can do it as follows:
|
||||
The `toggle` package exists in pkg/toggle can be used to define and manage a feature toggle for a new feature in Kyverno. Let's say we need to introduce a new feature toggle to enable/disable deferred loading. We can do it as follows:
|
||||
1. Define a flag name, description, environment variable and a default value for this new feature in the `toggle` package:
|
||||
```
|
||||
EnableDeferredLoadingFlagName = "enableDeferredLoading"
|
||||
|
@ -46,7 +46,7 @@ The `toggle` package exists in pkg/toggle can be used to define and manage a fea
|
|||
environment variable `FLAG_ENABLE_DEFERRED_LOADING=0`
|
||||
|
||||
## Container Arguments
|
||||
Container arguments can be used directly in the controller. Lets say we want to add a new container flag `--enable-feature`, we can do it as follows:
|
||||
Container arguments can be used directly in the controller. Let's say we want to add a new container flag `--enable-feature`, we can do it as follows:
|
||||
1. Create a variable for this new flag:
|
||||
```
|
||||
var(
|
||||
|
|
|
@ -94,7 +94,7 @@ To reduce the computation power needed, especially when resources change frequen
|
|||
- When the worker gets the namespace from the queue it lists all admission reports and background scan reports for that particular namespace, aggregates them together and reconciles the existing policy reports
|
||||
|
||||
This process can have a significant impact on the number of API calls and the memory footprint, especially when we have large reports.
|
||||
To mitigate this we use LIST api calls with pagination and reports are aggregated before loading the next page.
|
||||
To mitigate this, we use LIST api calls with pagination and reports are aggregated before loading the next page.
|
||||
|
||||
|
||||
```mermaid
|
||||
|
@ -164,7 +164,7 @@ For policy reports it's different, the number of policy reports will depend on t
|
|||
- one report per policy for clustered resources (10 policies -> 10 reports)
|
||||
|
||||
Policy reports and cluster policy reports are usually much larger, depending on the number of resources in the cluster/namespace.
|
||||
Sometimes they are too big to be stored in etcd and we split them into multiple reports containing a configurable number entries (`1000` by default).
|
||||
Sometimes they are too big to be stored in etcd and we split them into multiple reports containing a configurable number of entries (`1000` by default).
|
||||
|
||||
### Reports deletion
|
||||
|
||||
|
@ -457,13 +457,13 @@ If you have 1000 pods in a cluster, it gives:
|
|||
|
||||
With autogen you have to account for `Deployment`, `StatefulSet`, `Job`, `CronJob`, `ReplicaSet` too (reports for them will be approximately the same size).
|
||||
|
||||
And of course ephemeral admission reports consume space too, even if they should be cleaned up quickly.
|
||||
And of course, ephemeral admission reports consume space too, even if they should be cleaned up quickly.
|
||||
|
||||
Finally you need to take policy reports into account too.
|
||||
Basically they should consume approximately the same disk space as background scan reports (approximately because if some policies don't run in the background, results will come from aggregated admission reports).
|
||||
Finally, you need to take policy reports into account too.
|
||||
Basically, they should consume approximately the same disk space as background scan reports (approximately because if some policies don't run in the background, results will come from aggregated admission reports).
|
||||
|
||||
The number of policy reports is usually inferior to the number of other reports but they are bigger in size.
|
||||
The number of policy reports is usually inferior to the number of other reports, but they are bigger in size.
|
||||
|
||||
In the end, to use PSS policies (with `restricted` profile) on a 1000 pods cluster, you should budget around 25MB of etcd storage, spread across ~2000 reports.
|
||||
|
||||
In comparison, an average `Pod` is around 5KB (at least for a pod with a single container). The storage for 1000 pods is around 5MB. We can see that reports has a significant storage impact. Fortunately ETCD stores data on disk and associated cost should be negligible.
|
||||
In comparison, an average `Pod` is around 5KB (at least for a pod with a single container). The storage for 1000 pods is around 5MB. We can see that reports has a significant storage impact. Fortunately, ETCD stores data on disk and associated cost should be negligible.
|
|
@ -4,9 +4,9 @@ This document contains scripts to help troubleshooting reports issues.
|
|||
|
||||
## Getting reports detailed information
|
||||
|
||||
When querying reports you can add `-o wide` to get a more detailed output.
|
||||
When querying reports, you can add `-o wide` to get a more detailed output.
|
||||
|
||||
This will show infos about the resource associated with the report.
|
||||
This will show information about the resource associated with the report.
|
||||
|
||||
It can be useful to determine if a particular resource kind is responsible for creating too many reports.
|
||||
|
||||
|
@ -99,7 +99,7 @@ Listing existing reports can take a long time when there is a high number of rep
|
|||
|
||||
With `--watch-only` you only get an output for reports that are created, updated or deleted.
|
||||
|
||||
This is useful to determine if particular resource kind is reponsible for creating too many reports.
|
||||
This is useful to determine if a particular resource kind is responsible for creating too many reports.
|
||||
|
||||
```console
|
||||
# watch changing cluster admission reports
|
||||
|
|
Loading…
Reference in a new issue