Add profile specification to API docs
This commit is contained in:
stefanprodan
parent
00aff9c29f
commit
9c1ec256c1
11
README.md
11
README.md
|
|
@ -21,6 +21,7 @@ Features:
|
|||
* prunes the Kubernetes objects removed from source
|
||||
* checks the health of the deployed workloads
|
||||
* runs `Kustomizations` in a specific order, taking into account the depends-on relationship
|
||||
* reports on Slack or Discord whenever a `Kustomization` status changes
|
||||
|
||||
## Usage
|
||||
|
||||
|
|
@ -247,9 +248,9 @@ set in the Git repository manifest.
|
|||
|
||||
### Configure alerting
|
||||
|
||||
The kustomize controller can be configured to post message to Slack or Discord whenever a kustomization status changes.
|
||||
The kustomize controller can post message to Slack or Discord whenever a kustomization status changes.
|
||||
|
||||
Alerting can be configured by creating a profile that targets a list of kustomization:
|
||||
Alerting can be configured by creating a profile that targets a list of kustomizations:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
|
|
@ -269,7 +270,7 @@ spec:
|
|||
|
||||
The alert provider type can be: `slack` or `discord` and the verbosity can be set to `info` or `error`.
|
||||
|
||||
The `*` wildcard tells the controller to use this profile for all kustomization that are present
|
||||
The `*` wildcard tells the controller to use this profile for all kustomizations that are present
|
||||
in the same namespace as the profile.
|
||||
Multiple profiles can be used to send alerts to different channels or Slack organizations.
|
||||
|
||||
|
|
@ -280,9 +281,9 @@ health check failures.
|
|||
|
||||
|
||||
When the verbosity is set to `info`, the controller will alert if:
|
||||
* a kustomization apply has changed or created a Kubernetes object
|
||||
* a Kubernetes object was created, updated or deleted
|
||||
* heath checks are passing
|
||||
* a dependency is not ready
|
||||
* a dependency is delaying the execution
|
||||
* an error occurs
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 217 KiB After Width: | Height: | Size: 43 KiB |
|
|
@ -5,277 +5,15 @@ of Kubernetes objects generated with Kustomize.
|
|||
|
||||
## Specification
|
||||
|
||||
A **kustomization** object defines the source of Kubernetes manifests by referencing an object
|
||||
managed by [source-controller](https://github.com/fluxcd/source-controller),
|
||||
the path to the kustomization file within that source,
|
||||
and the interval at which the kustomize build output is applied on the cluster.
|
||||
- [Kustomization CRD](kustomization.md)
|
||||
+ [Source reference](kustomization.md#source-reference)
|
||||
+ [Reconciliation](kustomization.md#reconciliation)
|
||||
+ [Garbage collection](kustomization.md#garbage-collection)
|
||||
+ [Health assessment](kustomization.md#health-assessment)
|
||||
+ [Kustomization dependencies](kustomization.md#kustomization-dependencies)
|
||||
- [Profile CRD](profile.md)
|
||||
+ [Alerting configuration](profile.md#alerting)
|
||||
|
||||
```go
|
||||
type KustomizationSpec struct {
|
||||
// A list of kustomization that must be ready before this
|
||||
// kustomization can be applied.
|
||||
// +optional
|
||||
DependsOn []string `json:"dependsOn,omitempty"`
|
||||
## Implementation
|
||||
|
||||
// The interval at which to apply the kustomization.
|
||||
// +required
|
||||
Interval metav1.Duration `json:"interval"`
|
||||
|
||||
// Path to the directory containing the kustomization file.
|
||||
// +kubebuilder:validation:Pattern="^\\./"
|
||||
// +required
|
||||
Path string `json:"path"`
|
||||
|
||||
// Label selector used for garbage collection.
|
||||
// +kubebuilder:validation:Pattern="^.*=.*$"
|
||||
// +optional
|
||||
Prune string `json:"prune,omitempty"`
|
||||
|
||||
// A list of workloads (Deployments, DaemonSets and StatefulSets)
|
||||
// to be included in the health assessment.
|
||||
// +optional
|
||||
HealthChecks []WorkloadReference `json:"healthChecks,omitempty"`
|
||||
|
||||
// Reference of the source where the kustomization file is.
|
||||
// +required
|
||||
SourceRef corev1.TypedLocalObjectReference `json:"sourceRef"`
|
||||
|
||||
// This flag tells the controller to suspend subsequent kustomize executions,
|
||||
// it does not apply to already started executions. Defaults to false.
|
||||
// +optional
|
||||
Suspend bool `json:"suspend,omitempty"`
|
||||
|
||||
// Timeout for validation, apply and health checking operations.
|
||||
// Defaults to 'Interval' duration.
|
||||
// +optional
|
||||
Timeout *metav1.Duration `json:"timeout,omitempty"`
|
||||
|
||||
// Validate the Kubernetes objects before applying them on the cluster.
|
||||
// The validation strategy can be 'client' (local dry-run) or 'server' (APIServer dry-run).
|
||||
// +kubebuilder:validation:Enum=client;server
|
||||
// +optional
|
||||
Validation string `json:"validation,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
The status sub-resource describes the result of the last kustomization execution:
|
||||
|
||||
```go
|
||||
type KustomizationStatus struct {
|
||||
// +optional
|
||||
Conditions []Condition `json:"conditions,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
Status condition types:
|
||||
|
||||
```go
|
||||
const (
|
||||
// ReadyCondition represents the fact that a given kustomization has passed
|
||||
// validation and was successfully applied on the cluster.
|
||||
ReadyCondition string = "Ready"
|
||||
)
|
||||
```
|
||||
|
||||
Status condition reasons:
|
||||
|
||||
```go
|
||||
const (
|
||||
// ApplySucceedReason represents the fact that the kustomization apply succeed.
|
||||
ApplySucceedReason string = "ApplySucceed"
|
||||
|
||||
// ApplyFailedReason represents the fact that the kustomization apply failed.
|
||||
ApplyFailedReason string = "ApplyFailed"
|
||||
|
||||
// BuildFailedReason represents the fact that the kustomize build command failed.
|
||||
BuildFailedReason string = "BuildFailed"
|
||||
|
||||
// SuspendedReason represents the fact that the kustomization execution is suspended.
|
||||
SuspendedReason string = "Suspended"
|
||||
|
||||
// ValidationFailedReason represents the fact that the dry-run apply failed.
|
||||
ValidationFailedReason string = "ValidationFailed"
|
||||
|
||||
// ArtifactFailedReason represents the fact that the artifact acquisition failed.
|
||||
ArtifactFailedReason string = "ArtifactFailed"
|
||||
)
|
||||
```
|
||||
|
||||
## Kustomization source
|
||||
|
||||
The kustomization `spec.sourceRef` is a reference to an object managed by
|
||||
[source-controller](https://github.com/fluxcd/source-controller). When the source
|
||||
[revision](https://github.com/fluxcd/source-controller/blob/master/docs/spec/v1alpha1/common.md#source-status)
|
||||
changes, it generates a Kubernetes event that triggers a kustomize build and apply.
|
||||
|
||||
Source supported types:
|
||||
|
||||
* [GitRepository](https://github.com/fluxcd/source-controller/blob/master/docs/spec/v1alpha1/gitrepositories.md)
|
||||
|
||||
> **Note** that the source must contain the kustomization.yaml and all the Kubernetes manifests and configuration files
|
||||
> referenced in the kustomization.yaml.
|
||||
|
||||
## Kustomization execution
|
||||
|
||||
The kustomization `spec.interval` tells the controller at which interval to fetch the
|
||||
Kubernetes manifest for the source, build the kustomization and apply it on the cluster.
|
||||
The interval time units are `s`, `m` and `h` e.g. `interval: 5m`, the minimum value should be over 60 seconds.
|
||||
|
||||
The kustomization execution can be suspended by setting `spec.susped` to `true`.
|
||||
|
||||
The controller can be told to execute the kustomization outside of the specified interval
|
||||
by annotating the kustomization object with:
|
||||
|
||||
```go
|
||||
const (
|
||||
// SyncAtAnnotation is the annotation used for triggering a
|
||||
// sync outside of the specified schedule.
|
||||
SyncAtAnnotation string = "kustomize.fluxcd.io/syncAt"
|
||||
)
|
||||
```
|
||||
|
||||
On-demand execution example:
|
||||
|
||||
```bash
|
||||
kubectl annotate --overwrite kustomization/podinfo kustomize.fluxcd.io/syncAt="$(date +%s)"
|
||||
```
|
||||
|
||||
## Garbage collection
|
||||
|
||||
Garbage collection means that the Kubernetes objects that were previously applied on the cluster
|
||||
but are missing from the current apply, are removed from cluster automatically.
|
||||
Garbage collection is also performed when a Kustomization object is deleted,
|
||||
triggering a removal of all Kubernetes objects previously applied on the cluster.
|
||||
|
||||
Tpo enable garbage collection, all Kubernetes objects must have a common label that matches the `spec.prune`
|
||||
[label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
|
||||
|
||||
For example, `prune: env=dev,app=frontend` requires a `kustomization.yaml` with `commonLabels`:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.config.k8s.io/v1beta1
|
||||
kind: Kustomization
|
||||
commonLabels:
|
||||
env: dev
|
||||
app: frontend
|
||||
```
|
||||
|
||||
> **Note** that each kustomization must have a unique combination of labels values, otherwise the
|
||||
> garbage collection will remove resources outside of the kustomization scope.
|
||||
|
||||
## Health assessment
|
||||
|
||||
A kustomization can contain a series of health checks used to determine the
|
||||
[rollout status](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-status)
|
||||
of the deployed workloads. A health check entry can reference one of the following Kubernetes types:
|
||||
Deployment, DaemonSet or StatefulSet.
|
||||
|
||||
Assuming the kustomization source contains a Kubernetes Deployment named `backend`,
|
||||
a health check can be defined as follows:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
interval: 5m
|
||||
path: "./webapp/backend/"
|
||||
prune: "component=backend"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
healthChecks:
|
||||
- kind: Deployment
|
||||
name: backend
|
||||
namespace: dev
|
||||
timeout: 2m
|
||||
```
|
||||
|
||||
After applying the kustomize build output, the controller verifies if the rollout completed successfully.
|
||||
If the deployment was successful, the kustomization ready condition is marked as `true`,
|
||||
if the rollout failed, or if it takes more than the specified timeout to complete, then the
|
||||
kustomization ready condition is set to `false`. If the deployment becomes healthy on the next
|
||||
execution, then the kustomization is marked as ready.
|
||||
|
||||
## Kustomization dependencies
|
||||
|
||||
When running a kustomization, you may need to make sure other resources exist before the
|
||||
workloads defined in your kustomization are deployed.
|
||||
For example, a namespace must exist before applying resources to it.
|
||||
|
||||
With `spec.dependsOn` you can specify that the execution of a kustomization follows another.
|
||||
When you add `dependsOn` entries to a kustomization, that kustomization is applied
|
||||
only after all of its dependencies are ready. The readiness state of a kustomization is determined by
|
||||
its last apply status condition.
|
||||
|
||||
Assuming two kustomizations: a `common` one, that contains a namespace definition and a `backend` one, that
|
||||
contains the workload to be deployed in that namespace. You can instruct the controller to apply the `common`
|
||||
kustomization first with:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: common
|
||||
spec:
|
||||
interval: 5m
|
||||
path: "./webapp/common/"
|
||||
prune: "part-of=webapp"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
---
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
dependsOn:
|
||||
- common
|
||||
interval: 5m
|
||||
path: "./webapp/backend/"
|
||||
prune: "part-of=webapp,component=backend"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
```
|
||||
|
||||
When combined with health assessment, a kustomization will run after all its dependencies health checks are passing.
|
||||
For example, a service mesh proxy injector should be running before deploying applications inside the mesh.
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: istio
|
||||
spec:
|
||||
interval: 5m
|
||||
path: "./profiles/default/"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: istio
|
||||
healthChecks:
|
||||
- kind: Deployment
|
||||
name: istiod
|
||||
namespace: istio-system
|
||||
timeout: 2m
|
||||
---
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
dependsOn:
|
||||
- common
|
||||
- istio
|
||||
interval: 5m
|
||||
path: "./webapp/backend/"
|
||||
prune: "part-of=webapp,component=backend"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
```
|
||||
|
||||
> **Note** that circular dependencies between kustomizations must be avoided, otherwise the
|
||||
> interdependent kustomizations will never be applied on the cluster.
|
||||
* [kustomize-controller](https://github.com/fluxcd/kustomize-controller/)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,282 @@
|
|||
# Kustomization
|
||||
|
||||
The `Kustomization` API defines a pipeline for fetching, building, testing and applying Kubernetes manifests.
|
||||
|
||||
## Specification
|
||||
|
||||
A **kustomization** object defines the source of Kubernetes manifests by referencing an object
|
||||
managed by [source-controller](https://github.com/fluxcd/source-controller),
|
||||
the path to the kustomization file within that source,
|
||||
and the interval at which the kustomize build output is applied on the cluster.
|
||||
|
||||
```go
|
||||
type KustomizationSpec struct {
|
||||
// A list of kustomization that must be ready before this
|
||||
// kustomization can be applied.
|
||||
// +optional
|
||||
DependsOn []string `json:"dependsOn,omitempty"`
|
||||
|
||||
// The interval at which to apply the kustomization.
|
||||
// +required
|
||||
Interval metav1.Duration `json:"interval"`
|
||||
|
||||
// Path to the directory containing the kustomization file.
|
||||
// +kubebuilder:validation:Pattern="^\\./"
|
||||
// +required
|
||||
Path string `json:"path"`
|
||||
|
||||
// Label selector used for garbage collection.
|
||||
// +kubebuilder:validation:Pattern="^.*=.*$"
|
||||
// +optional
|
||||
Prune string `json:"prune,omitempty"`
|
||||
|
||||
// A list of workloads (Deployments, DaemonSets and StatefulSets)
|
||||
// to be included in the health assessment.
|
||||
// +optional
|
||||
HealthChecks []WorkloadReference `json:"healthChecks,omitempty"`
|
||||
|
||||
// Reference of the source where the kustomization file is.
|
||||
// +required
|
||||
SourceRef corev1.TypedLocalObjectReference `json:"sourceRef"`
|
||||
|
||||
// This flag tells the controller to suspend subsequent kustomize executions,
|
||||
// it does not apply to already started executions. Defaults to false.
|
||||
// +optional
|
||||
Suspend bool `json:"suspend,omitempty"`
|
||||
|
||||
// Timeout for validation, apply and health checking operations.
|
||||
// Defaults to 'Interval' duration.
|
||||
// +optional
|
||||
Timeout *metav1.Duration `json:"timeout,omitempty"`
|
||||
|
||||
// Validate the Kubernetes objects before applying them on the cluster.
|
||||
// The validation strategy can be 'client' (local dry-run) or 'server' (APIServer dry-run).
|
||||
// +kubebuilder:validation:Enum=client;server
|
||||
// +optional
|
||||
Validation string `json:"validation,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
The status sub-resource describes the result of the last kustomization execution:
|
||||
|
||||
```go
|
||||
type KustomizationStatus struct {
|
||||
// +optional
|
||||
Conditions []Condition `json:"conditions,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
Status condition types:
|
||||
|
||||
```go
|
||||
const (
|
||||
// ReadyCondition represents the fact that a given kustomization has passed
|
||||
// validation and was successfully applied on the cluster.
|
||||
ReadyCondition string = "Ready"
|
||||
)
|
||||
```
|
||||
|
||||
Status condition reasons:
|
||||
|
||||
```go
|
||||
const (
|
||||
// ApplySucceedReason represents the fact that the kustomization apply succeed.
|
||||
ApplySucceedReason string = "ApplySucceed"
|
||||
|
||||
// ApplyFailedReason represents the fact that the kustomization apply failed.
|
||||
ApplyFailedReason string = "ApplyFailed"
|
||||
|
||||
// BuildFailedReason represents the fact that the kustomize build command failed.
|
||||
BuildFailedReason string = "BuildFailed"
|
||||
|
||||
// SuspendedReason represents the fact that the kustomization execution is suspended.
|
||||
SuspendedReason string = "Suspended"
|
||||
|
||||
// ValidationFailedReason represents the fact that the dry-run apply failed.
|
||||
ValidationFailedReason string = "ValidationFailed"
|
||||
|
||||
// ArtifactFailedReason represents the fact that the artifact acquisition failed.
|
||||
ArtifactFailedReason string = "ArtifactFailed"
|
||||
)
|
||||
```
|
||||
|
||||
## Source reference
|
||||
|
||||
The kustomization `spec.sourceRef` is a reference to an object managed by
|
||||
[source-controller](https://github.com/fluxcd/source-controller). When the source
|
||||
[revision](https://github.com/fluxcd/source-controller/blob/master/docs/spec/v1alpha1/common.md#source-status)
|
||||
changes, it generates a Kubernetes event that triggers a kustomize build and apply.
|
||||
|
||||
Source supported types:
|
||||
|
||||
* [GitRepository](https://github.com/fluxcd/source-controller/blob/master/docs/spec/v1alpha1/gitrepositories.md)
|
||||
|
||||
> **Note** that the source must contain the kustomization.yaml and all the Kubernetes manifests and configuration files
|
||||
> referenced in the kustomization.yaml.
|
||||
|
||||
## Reconciliation
|
||||
|
||||
The kustomization `spec.interval` tells the controller at which interval to fetch the
|
||||
Kubernetes manifest for the source, build the kustomization and apply it on the cluster.
|
||||
The interval time units are `s`, `m` and `h` e.g. `interval: 5m`, the minimum value should be over 60 seconds.
|
||||
|
||||
The kustomization execution can be suspended by setting `spec.susped` to `true`.
|
||||
|
||||
The controller can be told to execute the kustomization outside of the specified interval
|
||||
by annotating the kustomization object with:
|
||||
|
||||
```go
|
||||
const (
|
||||
// SyncAtAnnotation is the annotation used for triggering a
|
||||
// sync outside of the specified schedule.
|
||||
SyncAtAnnotation string = "kustomize.fluxcd.io/syncAt"
|
||||
)
|
||||
```
|
||||
|
||||
On-demand execution example:
|
||||
|
||||
```bash
|
||||
kubectl annotate --overwrite kustomization/podinfo kustomize.fluxcd.io/syncAt="$(date +%s)"
|
||||
```
|
||||
|
||||
## Garbage collection
|
||||
|
||||
Garbage collection means that the Kubernetes objects that were previously applied on the cluster
|
||||
but are missing from the current apply, are removed from cluster automatically.
|
||||
Garbage collection is also performed when a Kustomization object is deleted,
|
||||
triggering a removal of all Kubernetes objects previously applied on the cluster.
|
||||
|
||||
Tpo enable garbage collection, all Kubernetes objects must have a common label that matches the `spec.prune`
|
||||
[label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
|
||||
|
||||
For example, `prune: env=dev,app=frontend` requires a `kustomization.yaml` with `commonLabels`:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.config.k8s.io/v1beta1
|
||||
kind: Kustomization
|
||||
commonLabels:
|
||||
env: dev
|
||||
app: frontend
|
||||
```
|
||||
|
||||
> **Note** that each kustomization must have a unique combination of labels values, otherwise the
|
||||
> garbage collection will remove resources outside of the kustomization scope.
|
||||
|
||||
## Health assessment
|
||||
|
||||
A kustomization can contain a series of health checks used to determine the
|
||||
[rollout status](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#deployment-status)
|
||||
of the deployed workloads. A health check entry can reference one of the following Kubernetes types:
|
||||
Deployment, DaemonSet or StatefulSet.
|
||||
|
||||
Assuming the kustomization source contains a Kubernetes Deployment named `backend`,
|
||||
a health check can be defined as follows:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
interval: 5m
|
||||
path: "./webapp/backend/"
|
||||
prune: "component=backend"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
healthChecks:
|
||||
- kind: Deployment
|
||||
name: backend
|
||||
namespace: dev
|
||||
timeout: 2m
|
||||
```
|
||||
|
||||
After applying the kustomize build output, the controller verifies if the rollout completed successfully.
|
||||
If the deployment was successful, the kustomization ready condition is marked as `true`,
|
||||
if the rollout failed, or if it takes more than the specified timeout to complete, then the
|
||||
kustomization ready condition is set to `false`. If the deployment becomes healthy on the next
|
||||
execution, then the kustomization is marked as ready.
|
||||
|
||||
## Kustomization dependencies
|
||||
|
||||
When applying a kustomization, you may need to make sure other resources exist before the
|
||||
workloads defined in your kustomization are deployed.
|
||||
For example, a namespace must exist before applying resources to it.
|
||||
|
||||
With `spec.dependsOn` you can specify that the execution of a kustomization follows another.
|
||||
When you add `dependsOn` entries to a kustomization, that kustomization is applied
|
||||
only after all of its dependencies are ready. The readiness state of a kustomization is determined by
|
||||
its last apply status condition.
|
||||
|
||||
Assuming two kustomizations:
|
||||
* `common` - contains a namespace and service accounts definitions
|
||||
* `backend` - contains the workloads to be deployed in that namespace
|
||||
|
||||
You can instruct the controller to apply the `common` kustomization before `backend`:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: common
|
||||
spec:
|
||||
interval: 5m
|
||||
path: "./webapp/common/"
|
||||
prune: "part-of=webapp"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
---
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
dependsOn:
|
||||
- common
|
||||
interval: 5m
|
||||
path: "./webapp/backend/"
|
||||
prune: "part-of=webapp,component=backend"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
```
|
||||
|
||||
When combined with health assessment, a kustomization will run after all its dependencies health checks are passing.
|
||||
For example, a service mesh proxy injector should be running before deploying applications inside the mesh.
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: istio
|
||||
spec:
|
||||
interval: 5m
|
||||
path: "./profiles/default/"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: istio
|
||||
healthChecks:
|
||||
- kind: Deployment
|
||||
name: istiod
|
||||
namespace: istio-system
|
||||
timeout: 2m
|
||||
---
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Kustomization
|
||||
metadata:
|
||||
name: backend
|
||||
spec:
|
||||
dependsOn:
|
||||
- common
|
||||
- istio
|
||||
interval: 5m
|
||||
path: "./webapp/backend/"
|
||||
prune: "part-of=webapp,component=backend"
|
||||
sourceRef:
|
||||
kind: GitRepository
|
||||
name: webapp
|
||||
```
|
||||
|
||||
> **Note** that circular dependencies between kustomizations must be avoided, otherwise the
|
||||
> interdependent kustomizations will never be applied on the cluster.
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
# Profile
|
||||
|
||||
The `Profile` API defines a common behavior for a group of [Kustomization](kustomization.md) objects.
|
||||
|
||||
## Specification
|
||||
|
||||
```go
|
||||
type ProfileSpec struct {
|
||||
// Alerting configuration of the kustomizations targeted by this profile.
|
||||
// +optional
|
||||
Alert *AlertProvider `json:"alert"`
|
||||
|
||||
// The list of kustomizations that this profile applies to.
|
||||
// +required
|
||||
Kustomizations []string `json:"kustomizations"`
|
||||
}
|
||||
```
|
||||
|
||||
Alerting configuration:
|
||||
|
||||
```go
|
||||
type AlertProvider struct {
|
||||
// HTTP(S) webhook address of this provider
|
||||
// +required
|
||||
Address string `json:"address"`
|
||||
|
||||
// Alert channel for this provider
|
||||
// +required
|
||||
Channel string `json:"channel"`
|
||||
|
||||
// Bot username for this provider
|
||||
// +required
|
||||
Username string `json:"username"`
|
||||
|
||||
// Filter alerts based on verbosity level, defaults to ('error').
|
||||
// +kubebuilder:validation:Enum=info;error
|
||||
// +optional
|
||||
Verbosity string `json:"verbosity,omitempty"`
|
||||
|
||||
// Type of provider
|
||||
// +kubebuilder:validation:Enum=slack;discord
|
||||
// +required
|
||||
Type string `json:"type"`
|
||||
}
|
||||
```
|
||||
|
||||
Status condition types:
|
||||
|
||||
```go
|
||||
const (
|
||||
// ReadyCondition represents the fact that a given Profile has been
|
||||
// processed by the controller.
|
||||
ReadyCondition string = "Ready"
|
||||
)
|
||||
```
|
||||
|
||||
Status condition reasons:
|
||||
|
||||
```go
|
||||
const (
|
||||
// InitializedReason represents the fact that a given resource has been initialized.
|
||||
InitializedReason string = "Initialized"
|
||||
)
|
||||
```
|
||||
|
||||
## Alerting
|
||||
|
||||
Alerting can be configured by creating a profile that contains an alert definition:
|
||||
|
||||
```yaml
|
||||
apiVersion: kustomize.fluxcd.io/v1alpha1
|
||||
kind: Profile
|
||||
metadata:
|
||||
name: default
|
||||
spec:
|
||||
alert:
|
||||
type: slack
|
||||
verbosity: info
|
||||
address: https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
|
||||
username: kustomize-controller
|
||||
channel: general
|
||||
kustomizations:
|
||||
- '*'
|
||||
```
|
||||
|
||||
The alert provider type can be: `slack` or `discord` and the verbosity can be set to `info` or `error`.
|
||||
|
||||
The `*` wildcard tells the controller to use this profile for all kustomizations that are present
|
||||
in the same namespace as the profile.
|
||||
Multiple profiles can be used to send alerts to different channels or Slack organizations.
|
||||
|
||||
When the verbosity is set to `error`, the controller will alert on any error encountered during the
|
||||
reconciliation process. This includes kustomize build and validation errors, apply errors and
|
||||
health check failures.
|
||||
|
||||
When the verbosity is set to `info`, the controller will alert whenever a kustomization status changes.
|
||||
Loading…
Reference in New Issue