You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This page provides guidance for administrators on how to manage Knative on an existing Kubernetes cluster.
10
+
This page provides guidance for administrators on how to manage Knative on an existing Kubernetes cluster. Knative administrators install and configure both or either of the Serving and Eventing components along with default or preferred plugins.
11
+
12
+
Administrators can use Knative to provide developers with a simple experience for interacting with clusters and deploying applications. In this model, developers primarily interact with Knative resources like Services, Brokers, and Triggers. Because Knative can interoperate with core Kubernetes objects, developers can also use existing Kubernetes tools such as pods, services, networking, identity, and storage where needed. Developers looking to further simplify the deployment experience can define functions with the Knative Functions programming model. The following illustration shows the roles of administrators and developers in this model:
13
+
14
+
```mermaid
15
+
---
16
+
config:
17
+
theme: redux
18
+
layout: dagre
19
+
look: classic
20
+
---
21
+
flowchart LR
22
+
subgraph Knative["**Knative** "]
23
+
direction LR
24
+
Serving["Serving"]
25
+
Eventing["Eventing"]
26
+
end
27
+
subgraph Plugins["**Plugins** "]
28
+
direction LR
29
+
net-istio["Istio"]
30
+
net-contour["Contour"]
31
+
net-gateway-api["Gateway API"]
32
+
event-kafka["Kafka"]
33
+
event-rabbitmq["RabbitMQ"]
34
+
event-nats["NATS"]
35
+
end
36
+
Dev(["**Developers**"]) --> dev-acts["Develops and manages"]
37
+
dev-acts --> Serving & Eventing
38
+
Admin(["**Administrators**"]) --> admin-acts["Installs and configures"]
As a cluster administrator, your responsibilities include managing the Kubernetes environment, installing cluster-wide components, and enabling developers to deploy applications on the cluster. Knative aims to simplify developer tasks, while aligning with existing management tools and processes.
13
68
14
69
Knative includes a plugin system to integrate with existing infrastructure in the cluster, enabling Knative resources such as Routes and Brokers to be implemented using one of multiple underlying suppliers. For example, a Knative Eventing app can deliver events to a Broker that triggers a function based on the received event. In a testing cluster, the delivery might use an in-memory option, while a staging or production environment might use a cloud-provided Kafka service.
15
70
16
-
Of particular interest to cluster administrators is that Knative supports customizable _default values_ on the parameters defined in resource YAML files. These configurations reduce the amount of environment configuration tasks developers needs to consider.
71
+
Of particular interest to cluster administrators is that Knative supports customizable _default values_ on the parameters defined in resource YAML files. These configurations reduce the amount of environment configuration tasks developers need to consider.
17
72
18
-
## Knative installations
73
+
## Installation decisions
19
74
20
75
See the [Installation roadmap](../install/README.md#installation-roadmap) for prerequisites and installation steps. Your first installation decision is whether to use a YAML-based installation or use the Knative Operator. The Knative Operator is a custom controller that extends the Kubernetes API to install Knative components. If you just need to get acquainted with Knative at this time, you can install the [quickstart](../getting-started/quickstart-install.md).
21
76
22
-
## Configuring Knative
77
+
The method you use to install Knative is not permanent and you can install clusters differently depending on the situation. Although transitioning between installation methods on one cluster is possible, new installations on separate clusters is the better-tested and officially supported approach.
23
78
24
-
Knative uses Kubernetes YAML manifests to define and configure system components. These manifests include core resources, custom resource definitions (CRDs), and extensibility features. As with Kubernetes, these configuration resources are declarative and can be managed using the `kubectl` CLI tool or with continuous delivery tools.
79
+
### Upgrades
80
+
81
+
Administrators are generally responsible for performing upgrades to cluster infrastructure, apps, and services. Knative is designed and tested for continuous operation during upgrades and rollbacks, allowing you to:
25
82
26
-
### Resource scoping and namespaces
83
+
- Upgrade or revert the Knative components while it is serving traffic, rather than needing a maintenance window.
84
+
- Downgrade by one Knative version. Downgrades work provided that no applications have used new features since the last upgrade.
85
+
86
+
## Securing Knative
27
87
28
-
Knative resources are namespaced. Knative adheres to the Kubernetes model of namespace-based isolation that lets you manage development teams and resources by assigning them to namespaces.
88
+
Knative resources are namespaced. Knative adheres to the Kubernetes model of namespace-based isolation that lets you manage development teams and resources by assigning them to namespaces. You may also grant developers access to additional resources related to their namespace in other services, such as observability, logs, metrics, tracing, and dashboards.
29
89
30
90
Namespaces can also isolate boundaries for tooling such as logs, metrics, tracing, CI/CD integrations, and dashboards. The extent of this isolation depends on both the enforcement strategy and how consistently teams adhere to namespace boundaries.
31
91
@@ -36,11 +96,11 @@ You can optimize and enforce isolation involving namespaces using standard Kuber
Knative configurations are performed by the following methods:
42
102
43
-
- Editing YAML manifests
103
+
- Editing YAML manifests and applying with the `kubectl` tool
44
104
45
105
Modify resource definitions directly, including labels, annotations, and field values. You can use Kubernetes features such as [OPA](https://kubernetes.io/blog/2019/08/06/opa-gatekeeper-policy-and-governance-for-kubernetes/) and [Kyverno](https://kyverno.io) to enforce specific values on a resource type, or use ConfigMaps in plugin installations to set values at the cluster level.
46
106
@@ -50,59 +110,40 @@ Knative configurations are performed by the following methods:
50
110
51
111
- Using the Knative Operator
52
112
53
-
Some platform-wide settings can be managed declaratively using the Knative Operator.
54
-
55
-
### Configuration tasks
56
-
57
-
Knative documentation provides the following configuration procedures. This list is subject subject to change.
Some platform-wide settings can be managed declaratively using the Knative Operator, installed with the `kn` Knative CLI plugin. You can manage the operator without using the `kn` CLI. The `kn` CLI manages only operator installations.
68
114
69
-
Configurations for new development:
115
+
For more information, see [Installing CLI tools](../client/README.md)
You can grant developers access to additional resources related to their namespace in other services, such as observability, logs, metrics, tracing, and dashboards.
117
+
Knative uses Kubernetes YAML manifests to define and configure system components. These manifests include core resources, custom resource definitions (CRDs), and extensibility features. As with Kubernetes, these configuration resources are declarative and can be managed using the `kubectl` CLI tool or with continuous delivery tools.
102
118
103
-
## Upgrades
119
+
The following sections provide an overview of the current configuration resources of interest to Administrators. You can edit these configurations using `kubectl`; Knative installs empty ConfigMaps with these names onto the cluster.
120
+
121
+
### Serving configurations
122
+
123
+
| Configuration | ConfigMap | Description |
124
+
| -- | --- | --- |
125
+
|[Default configurations](../serving/configuration/config-defaults.md)|`config-defaults`| Default resource values such as performance, hardware, and storage settings. |
126
+
|[Deployment resources](../serving/configuration/deployment.md)|`config-deployment`| Kubernetes deployment resources that back Knative services. |
127
+
|[Domain names](../serving/using-a-custom-domain.md)|`config-domain`| Configure and publish domains. |
128
+
|[High-availability](../serving/config-ha.md)| NA | Configure ensure that APIs stay operational if a disruption occurs. |
129
+
|[Garbage collection](../serving/revisions/revision-admin-config-options.md)|`config-gc`| Disable and enable collection and set retention time values. |
130
+
|[Ingress gateway](../serving/setting-up-custom-ingress-gateway.md)|`config-istio`| For new clusters, you can configure your own gateway and underlying service. |
131
+
|[Istio authorization](../serving/istio-authorization.md)| NA | Grant authorization to your deployed Knative services. |
132
+
|[Namespace exclusion from webhook](../serving/webhook-customizations.md)| NA | For performance concerns during an upgrade. |
133
+
|[Rollout duration for revisions](../serving/configuration/rolling-out-latest-revision-configmap.md)|`config-network`| Adjust rollout durations to accommodate longer request queues. |
134
+
|[Security - Certificates](../serving/encryption/configure-certmanager-integration.md)|`config-certmanager`| Describes how to manage automatic certificate provisioning. |
135
+
|[Security - Encryptions](../serving/encryption/encryption-overview.md)|`config-network`| Provides links to procedures for encrypting external domains, the local cluster, and system internal. |
136
+
137
+
### Eventing configurations
138
+
139
+
| Configuration | ConfigMap | Description |
140
+
| -- | --- | --- |
141
+
|[Broker defaults](../eventing/configuration/broker-configuration.md)|`config-br-defaults`| Specify your own broker class and channel, or use the default `MTChannelBasedBroker` Broker class and the ConfigMap of channel defaults. |
142
+
|[Broker features (Kafka)](../eventing/brokers/broker-types/kafka-broker/configuring-kafka-features.md)|`config-kafka-features`| Configure options for Broker interactions with Apache Kafka clusters. |
143
+
|[Channel defaults](../eventing/configuration/channel-configuration.md)|`default-ch-webhook`| Default configurations and labels to use for the channel. |
144
+
|[Channel defaults (Kafka)](../eventing/configuration/kafka-channel-configuration.md)|`kafka-channel`| Defines how KafkaChannel instances are created. Requires that KafkaChannel custom resource definitions (CRD) are installed.|
145
+
|[Event source defaults](../eventing/configuration/sources-configuration.md)|`config-ping-defaults`| Configure the PingSource default resources and the maximum data size for CloudEvents it produces. |
146
+
|[KEDA Autoscaling of Kafka Resources](../eventing/configuration/keda-configuration.md)|`config-kafka-features`| Configure how KEDA scales a KafkaSource, trigger, or subscription. Note: This feature is is Alpha pre-release. |
147
+
|[Sugar Controller](../eventing/sugar/README.md)|`config-sugar`| Configure the Sugar controller, which reacts to label configurations to produce or control eventing resources. See also [Knative Eventing Sugar Controller](../eventing/sugar/README.md). |
104
148
105
-
Administrators are generally responsible for performing upgrades cluster infrastructure and apps and services. Knative is designed and tested for continuous operation during upgrades and rollbacks, allowing you to:
106
149
107
-
- Upgrade or revert the Knative components while it is serving traffic, rather than needing a maintenance window.
108
-
- Downgrade one Knative version. Downgrades work provided that no applications have used new features since the last upgrade.
0 commit comments