Merge branch 'dev-1.22' into merged-master-dev-1.22
This commit is contained in:
commit
fe170db160
|
@ -13,15 +13,23 @@ weight: 60
|
|||
|
||||
System component traces record the latency of and relationships between operations in the cluster.
|
||||
|
||||
Kubernetes components emit traces using the [OpenTelemetry Protocol](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification) with the gRPC exporter and can be collected and routed to tracing backends using an [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector).
|
||||
Kubernetes components emit traces using the
|
||||
[OpenTelemetry Protocol](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification)
|
||||
with the gRPC exporter and can be collected and routed to tracing backends using an
|
||||
[OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Trace Collection
|
||||
|
||||
For a complete guide to collecting traces and using the collector, see [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/). However, there are a few things to note that are specific to Kubernetes components.
|
||||
For a complete guide to collecting traces and using the collector, see
|
||||
[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/).
|
||||
However, there are a few things to note that are specific to Kubernetes components.
|
||||
|
||||
By default, Kubernetes components export traces using the grpc exporter for OTLP on the [IANA OpenTelemetry port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry), 4317. As an example, if the collector is running as a sidecar to a Kubernetes component, the following receiver configuration will collect spans and log them to standard output:
|
||||
By default, Kubernetes components export traces using the grpc exporter for OTLP on the
|
||||
[IANA OpenTelemetry port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry), 4317.
|
||||
As an example, if the collector is running as a sidecar to a Kubernetes component,
|
||||
the following receiver configuration will collect spans and log them to standard output:
|
||||
|
||||
```yaml
|
||||
receivers:
|
||||
|
@ -43,11 +51,19 @@ service:
|
|||
|
||||
### kube-apiserver traces
|
||||
|
||||
The kube-apiserver generates spans for incoming HTTP requests, and for outgoing requests to webhooks, etcd, and re-entrant requests. It propagates the [W3C Trace Context](https://www.w3.org/TR/trace-context/) with outgoing requests but does not make use of the trace context attached to incoming requests, as the kube-apiserver is often a public endpoint.
|
||||
The kube-apiserver generates spans for incoming HTTP requests, and for outgoing requests
|
||||
to webhooks, etcd, and re-entrant requests. It propagates the
|
||||
[W3C Trace Context](https://www.w3.org/TR/trace-context/) with outgoing requests
|
||||
but does not make use of the trace context attached to incoming requests,
|
||||
as the kube-apiserver is often a public endpoint.
|
||||
|
||||
#### Enabling tracing in the kube-apiserver
|
||||
|
||||
To enable tracing, enable the `APIServerTracing` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver. Also, provide the kube-apiserver with a tracing configration file with `--tracing-config-file=<path-to-config>`. This is an example config that records spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint:
|
||||
To enable tracing, enable the `APIServerTracing`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
on the kube-apiserver. Also, provide the kube-apiserver with a tracing configration file
|
||||
with `--tracing-config-file=<path-to-config>`. This is an example config that records
|
||||
spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint:
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1alpha1
|
||||
|
@ -57,10 +73,17 @@ kind: TracingConfiguration
|
|||
samplingRatePerMillion: 100
|
||||
```
|
||||
|
||||
For more information about the `TracingConfiguration` struct, see
|
||||
[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration).
|
||||
|
||||
## Stability
|
||||
|
||||
Tracing instrumentation is still under active development, and may change in a variety of ways. This includes span names, attached attributes, instrumented endpoints, etc. Until this feature graduates to stable, there are no guarantees of backwards compatibility for tracing instrumentation.
|
||||
Tracing instrumentation is still under active development, and may change
|
||||
in a variety of ways. This includes span names, attached attributes,
|
||||
instrumented endpoints, etc. Until this feature graduates to stable,
|
||||
there are no guarantees of backwards compatibility for tracing instrumentation.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
|
||||
|
||||
|
|
|
@ -188,9 +188,10 @@ selectors and uses DNS names instead. For more information, see the
|
|||
[ExternalName](#externalname) section later in this document.
|
||||
|
||||
### Over Capacity Endpoints
|
||||
If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.21
|
||||
cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: warning`.
|
||||
This annotation indicates that the affected Endpoints object is over capacity.
|
||||
If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.22 (or later)
|
||||
cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: truncated`.
|
||||
This annotation indicates that the affected Endpoints object is over capacity and that
|
||||
the endpoints controller has truncated the number of endpoints to 1000.
|
||||
|
||||
### EndpointSlices
|
||||
|
||||
|
|
|
@ -415,37 +415,40 @@ The access modes are:
|
|||
* ReadWriteOnce -- the volume can be mounted as read-write by a single node
|
||||
* ReadOnlyMany -- the volume can be mounted read-only by many nodes
|
||||
* ReadWriteMany -- the volume can be mounted as read-write by many nodes
|
||||
* ReadWriteOncePod -- the volume can be mounted as read-write by a single Pod.
|
||||
This is only supported for CSI volumes and Kubernetes version 1.22+.
|
||||
|
||||
In the CLI, the access modes are abbreviated to:
|
||||
|
||||
* RWO - ReadWriteOnce
|
||||
* ROX - ReadOnlyMany
|
||||
* RWX - ReadWriteMany
|
||||
* RWOP - ReadWriteOncePod
|
||||
|
||||
> __Important!__ A volume can only be mounted using one access mode at a time, even if it supports many. For example, a GCEPersistentDisk can be mounted as ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time.
|
||||
|
||||
|
||||
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany|
|
||||
| :--- | :---: | :---: | :---: |
|
||||
| AWSElasticBlockStore | ✓ | - | - |
|
||||
| AzureFile | ✓ | ✓ | ✓ |
|
||||
| AzureDisk | ✓ | - | - |
|
||||
| CephFS | ✓ | ✓ | ✓ |
|
||||
| Cinder | ✓ | - | - |
|
||||
| CSI | depends on the driver | depends on the driver | depends on the driver |
|
||||
| FC | ✓ | ✓ | - |
|
||||
| FlexVolume | ✓ | ✓ | depends on the driver |
|
||||
| Flocker | ✓ | - | - |
|
||||
| GCEPersistentDisk | ✓ | ✓ | - |
|
||||
| Glusterfs | ✓ | ✓ | ✓ |
|
||||
| HostPath | ✓ | - | - |
|
||||
| iSCSI | ✓ | ✓ | - |
|
||||
| Quobyte | ✓ | ✓ | ✓ |
|
||||
| NFS | ✓ | ✓ | ✓ |
|
||||
| RBD | ✓ | ✓ | - |
|
||||
| VsphereVolume | ✓ | - | - (works when Pods are collocated) |
|
||||
| PortworxVolume | ✓ | - | ✓ |
|
||||
| StorageOS | ✓ | - | - |
|
||||
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod |
|
||||
| :--- | :---: | :---: | :---: | - |
|
||||
| AWSElasticBlockStore | ✓ | - | - | - |
|
||||
| AzureFile | ✓ | ✓ | ✓ | - |
|
||||
| AzureDisk | ✓ | - | - | - |
|
||||
| CephFS | ✓ | ✓ | ✓ | - |
|
||||
| Cinder | ✓ | - | - | - |
|
||||
| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
|
||||
| FC | ✓ | ✓ | - | - |
|
||||
| FlexVolume | ✓ | ✓ | depends on the driver | - |
|
||||
| Flocker | ✓ | - | - | - |
|
||||
| GCEPersistentDisk | ✓ | ✓ | - | - |
|
||||
| Glusterfs | ✓ | ✓ | ✓ | - |
|
||||
| HostPath | ✓ | - | - | - |
|
||||
| iSCSI | ✓ | ✓ | - | - |
|
||||
| Quobyte | ✓ | ✓ | ✓ | - |
|
||||
| NFS | ✓ | ✓ | ✓ | - |
|
||||
| RBD | ✓ | ✓ | - | - |
|
||||
| VsphereVolume | ✓ | - | - (works when Pods are collocated) | - |
|
||||
| PortworxVolume | ✓ | - | ✓ | - | - |
|
||||
| StorageOS | ✓ | - | - | - |
|
||||
|
||||
### Class
|
||||
|
||||
|
@ -792,6 +795,82 @@ spec:
|
|||
storage: 10Gi
|
||||
```
|
||||
|
||||
## Volume populators and data sources
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes supports custom volume populators; this alpha feature was introduced
|
||||
in Kubernetes 1.18. Kubernetes 1.22 reimplemented the mechanism with a redesigned API.
|
||||
Check that you are reading the version of the Kubernetes documentation that matches your
|
||||
cluster. {{% version-check %}}
|
||||
To use custom volume populators, you must enable the `AnyVolumeDataSource`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for
|
||||
the kube-apiserver and kube-controller-manager.
|
||||
{{< /note >}}
|
||||
|
||||
Volume populators take advantage of a PVC spec field called `dataSourceRef`. Unlike the
|
||||
`dataSource` field, which can only contain either a reference to another PersistentVolumeClaim
|
||||
or to a VolumeSnapshot, the `dataSourceRef` field can contain a reference to any object in the
|
||||
same namespace, except for core objects other than PVCs. For clusters that have the feature
|
||||
gate enabled, use of the `dataSourceRef` is preferred over `dataSource`.
|
||||
|
||||
## Data source references
|
||||
|
||||
The `dataSourceRef` field behaves almost the same as the `dataSource` field. If either one is
|
||||
specified while the other is not, the API server will give both fields the same value. Neither
|
||||
field can be changed after creation, and attempting to specify different values for the two
|
||||
fields will result in a validation error. Therefore the two fields will always have the same
|
||||
contents.
|
||||
|
||||
There are two differences between the `dataSourceRef` field and the `dataSource` field that
|
||||
users should be aware of:
|
||||
* The `dataSource` field ignores invalid values (as if the field was blank) while the
|
||||
`dataSourceRef` field never ignores values and will cause an error if an invalid value is
|
||||
used. Invalid values are any core object (objects with no apiGroup) except for PVCs.
|
||||
* The `dataSourceRef` field may contain different types of objects, while the `dataSource` field
|
||||
only allows PVCs and VolumeSnapshots.
|
||||
|
||||
Users should always use `dataSourceRef` on clusters that have the feature gate enabled, and
|
||||
fall back to `dataSource` on clusters that do not. It is not necessary to look at both fields
|
||||
under any circumstance. The duplicated values with slightly different semantics exist only for
|
||||
backwards compatibility. In particular, a mixture of older and newer controllers are able to
|
||||
interoperate because the fields are the same.
|
||||
|
||||
### Using volume populators
|
||||
|
||||
Volume populators are {{< glossary_tooltip text="controllers" term_id="controller" >}} that can
|
||||
create non-empty volumes, where the contents of the volume are determined by a Custom Resource.
|
||||
Users create a populated volume by referring to a Custom Resource using the `dataSourceRef` field:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: populated-pvc
|
||||
spec:
|
||||
dataSourceRef:
|
||||
name: example-name
|
||||
kind: ExampleDataSource
|
||||
apiGroup: example.storage.k8s.io
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
```
|
||||
|
||||
Because volume populators are external components, attempts to create a PVC that uses one
|
||||
can fail if not all the correct components are installed. External controllers should generate
|
||||
events on the PVC to provide feedback on the status of the creation, including warnings if
|
||||
the PVC cannot be created due to some missing component.
|
||||
|
||||
You can install the alpha [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator)
|
||||
controller into your cluster. That controller generates warning Events on a PVC in the case that no populator
|
||||
is registered to handle that kind of data source. When a suitable populator is installed for a PVC, it's the
|
||||
responsibility of that populator controller to report Events that relate to volume creation and issues during
|
||||
the process.
|
||||
|
||||
## Writing Portable Configuration
|
||||
|
||||
If you're writing configuration templates or examples that run on a wide range of clusters
|
||||
|
|
|
@ -71,6 +71,7 @@ configure kubernetes components or tools. Most of these APIs are not exposed
|
|||
by the API server in a RESTful way though they are essential for a user or an
|
||||
operator to use or manage a cluster.
|
||||
|
||||
* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
|
||||
* [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
|
||||
* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
|
||||
* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
|
||||
|
|
|
@ -471,7 +471,7 @@ different Kubernetes components.
|
|||
| `WatchBookmark` | `true` | GA | 1.17 | - |
|
||||
| `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | 1.20 |
|
||||
| `WindowsEndpointSliceProxying` | `true` | Beta | 1.21 | 1.21 |
|
||||
| `WindowsEndpointSliceProxying` | `true` | GA | 1.22 | - |
|
||||
| `WindowsEndpointSliceProxying` | `true` | GA | 1.22| - |
|
||||
| `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 |
|
||||
| `WindowsGMSA` | `true` | GA | 1.18 | - |
|
||||
|
|
|
@ -0,0 +1,438 @@
|
|||
---
|
||||
title: kube-apiserver Configuration (v1alpha1)
|
||||
content_type: tool-reference
|
||||
package: apiserver.k8s.io/v1alpha1
|
||||
auto_generated: true
|
||||
---
|
||||
Package v1alpha1 is the v1alpha1 version of the API.
|
||||
|
||||
## Resource Types
|
||||
|
||||
|
||||
- [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration)
|
||||
- [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration)
|
||||
- [TracingConfiguration](#apiserver-k8s-io-v1alpha1-TracingConfiguration)
|
||||
|
||||
|
||||
|
||||
|
||||
## `AdmissionConfiguration` {#apiserver-k8s-io-v1alpha1-AdmissionConfiguration}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
AdmissionConfiguration provides versioned configuration for admission controllers.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1alpha1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>AdmissionConfiguration</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>plugins</code><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-AdmissionPluginConfiguration"><code>[]AdmissionPluginConfiguration</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Plugins allows specifying a configuration per admission control plugin.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `EgressSelectorConfiguration` {#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
EgressSelectorConfiguration provides versioned configuration for egress selector clients.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1alpha1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>EgressSelectorConfiguration</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>egressSelections</code> <B>[Required]</B><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-EgressSelection"><code>[]EgressSelection</code></a>
|
||||
</td>
|
||||
<td>
|
||||
connectionServices contains a list of egress selection client configurations</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `TracingConfiguration` {#apiserver-k8s-io-v1alpha1-TracingConfiguration}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
TracingConfiguration provides versioned configuration for tracing clients.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
<tr><td><code>apiVersion</code><br/>string</td><td><code>apiserver.k8s.io/v1alpha1</code></td></tr>
|
||||
<tr><td><code>kind</code><br/>string</td><td><code>TracingConfiguration</code></td></tr>
|
||||
|
||||
|
||||
|
||||
|
||||
<tr><td><code>endpoint</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Endpoint of the collector that's running on the control-plane node.
|
||||
The APIServer uses the egressType ControlPlane when sending data to the collector.
|
||||
The syntax is defined in https://github.com/grpc/grpc/blob/master/doc/naming.md.
|
||||
Defaults to the otlpgrpc default, localhost:4317
|
||||
The connection is insecure, and does not support TLS.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>samplingRatePerMillion</code><br/>
|
||||
<code>int32</code>
|
||||
</td>
|
||||
<td>
|
||||
SamplingRatePerMillion is the number of samples to collect per million spans.
|
||||
Defaults to 0.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `AdmissionPluginConfiguration` {#apiserver-k8s-io-v1alpha1-AdmissionPluginConfiguration}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration)
|
||||
|
||||
|
||||
AdmissionPluginConfiguration provides the configuration for a single plug-in.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>name</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Name is the name of the admission controller.
|
||||
It must match the registered admission plugin name.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>path</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
Path is the path to a configuration file that contains the plugin's
|
||||
configuration</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>configuration</code><br/>
|
||||
<a href="https://godoc.org/k8s.io/apimachinery/pkg/runtime#Unknown"><code>k8s.io/apimachinery/pkg/runtime.Unknown</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Configuration is an embedded configuration object to be used as the plugin's
|
||||
configuration. If present, it will be used instead of the path to the configuration file.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `Connection` {#apiserver-k8s-io-v1alpha1-Connection}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [EgressSelection](#apiserver-k8s-io-v1alpha1-EgressSelection)
|
||||
|
||||
|
||||
Connection provides the configuration for a single egress selection client.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>proxyProtocol</code> <B>[Required]</B><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-ProtocolType"><code>ProtocolType</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Protocol is the protocol used to connect from client to the konnectivity server.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>transport</code><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-Transport"><code>Transport</code></a>
|
||||
</td>
|
||||
<td>
|
||||
Transport defines the transport configurations we use to dial to the konnectivity server.
|
||||
This is required if ProxyProtocol is HTTPConnect or GRPC.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `EgressSelection` {#apiserver-k8s-io-v1alpha1-EgressSelection}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration)
|
||||
|
||||
|
||||
EgressSelection provides the configuration for a single egress selection client.
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>name</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
name is the name of the egress selection.
|
||||
Currently supported values are "controlplane", "master", "etcd" and "cluster"
|
||||
The "master" egress selector is deprecated in favor of "controlplane"</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>connection</code> <B>[Required]</B><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-Connection"><code>Connection</code></a>
|
||||
</td>
|
||||
<td>
|
||||
connection is the exact information used to configure the egress selection</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `ProtocolType` {#apiserver-k8s-io-v1alpha1-ProtocolType}
|
||||
|
||||
(Alias of `string`)
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Connection](#apiserver-k8s-io-v1alpha1-Connection)
|
||||
|
||||
|
||||
ProtocolType is a set of valid values for Connection.ProtocolType
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## `TCPTransport` {#apiserver-k8s-io-v1alpha1-TCPTransport}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Transport](#apiserver-k8s-io-v1alpha1-Transport)
|
||||
|
||||
|
||||
TCPTransport provides the information to connect to konnectivity server via TCP
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>url</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
URL is the location of the konnectivity server to connect to.
|
||||
As an example it might be "https://127.0.0.1:8131"</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>tlsConfig</code><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-TLSConfig"><code>TLSConfig</code></a>
|
||||
</td>
|
||||
<td>
|
||||
TLSConfig is the config needed to use TLS when connecting to konnectivity server</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `TLSConfig` {#apiserver-k8s-io-v1alpha1-TLSConfig}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [TCPTransport](#apiserver-k8s-io-v1alpha1-TCPTransport)
|
||||
|
||||
|
||||
TLSConfig provides the authentication information to connect to konnectivity server
|
||||
Only used with TCPTransport
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>caBundle</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
caBundle is the file location of the CA to be used to determine trust with the konnectivity server.
|
||||
Must be absent/empty if TCPTransport.URL is prefixed with http://
|
||||
If absent while TCPTransport.URL is prefixed with https://, default to system trust roots.</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>clientKey</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
clientKey is the file location of the client key to be used in mtls handshakes with the konnectivity server.
|
||||
Must be absent/empty if TCPTransport.URL is prefixed with http://
|
||||
Must be configured if TCPTransport.URL is prefixed with https://</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>clientCert</code><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
clientCert is the file location of the client certificate to be used in mtls handshakes with the konnectivity server.
|
||||
Must be absent/empty if TCPTransport.URL is prefixed with http://
|
||||
Must be configured if TCPTransport.URL is prefixed with https://</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `Transport` {#apiserver-k8s-io-v1alpha1-Transport}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Connection](#apiserver-k8s-io-v1alpha1-Connection)
|
||||
|
||||
|
||||
Transport defines the transport configurations we use to dial to the konnectivity server
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>tcp</code><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-TCPTransport"><code>TCPTransport</code></a>
|
||||
</td>
|
||||
<td>
|
||||
TCP is the TCP configuration for communicating with the konnectivity server via TCP
|
||||
ProxyProtocol of GRPC is not supported with TCP transport at the moment
|
||||
Requires at least one of TCP or UDS to be set</td>
|
||||
</tr>
|
||||
|
||||
|
||||
<tr><td><code>uds</code><br/>
|
||||
<a href="#apiserver-k8s-io-v1alpha1-UDSTransport"><code>UDSTransport</code></a>
|
||||
</td>
|
||||
<td>
|
||||
UDS is the UDS configuration for communicating with the konnectivity server via UDS
|
||||
Requires at least one of TCP or UDS to be set</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## `UDSTransport` {#apiserver-k8s-io-v1alpha1-UDSTransport}
|
||||
|
||||
|
||||
|
||||
|
||||
**Appears in:**
|
||||
|
||||
- [Transport](#apiserver-k8s-io-v1alpha1-Transport)
|
||||
|
||||
|
||||
UDSTransport provides the information to connect to konnectivity server via UDS
|
||||
|
||||
<table class="table">
|
||||
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
|
||||
<tbody>
|
||||
|
||||
|
||||
|
||||
<tr><td><code>udsName</code> <B>[Required]</B><br/>
|
||||
<code>string</code>
|
||||
</td>
|
||||
<td>
|
||||
UDSName is the name of the unix domain socket to connect to konnectivity server
|
||||
This does not use a unix:// prefix. (Eg: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)</td>
|
||||
</tr>
|
||||
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
|
@ -328,7 +328,31 @@ kubectl [flags]
|
|||
</tbody>
|
||||
</table>
|
||||
|
||||
## {{% heading "envvars" %}}
|
||||
|
||||
<table style="width: 100%; table-layout: fixed;">
|
||||
<colgroup>
|
||||
<col span="1" style="width: 10px;" />
|
||||
<col span="1" />
|
||||
</colgroup>
|
||||
<tbody>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">KUBECONFIG</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">Path to the kubectl configuration ("kubeconfig") file. Default: "$HOME/.kube/config"</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td colspan="2">KUBECTL_COMMAND_HEADERS</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to false, turns off extra HTTP headers detailing invoked kubectl command (Kubernetes version v1.22 or later)</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## {{% heading "seealso" %}}
|
||||
|
||||
|
|
|
@ -263,11 +263,11 @@ The value of the annotation is the container name that is default for this Pod.
|
|||
|
||||
## endpoints.kubernetes.io/over-capacity
|
||||
|
||||
Example: `endpoints.kubernetes.io/over-capacity:warning`
|
||||
Example: `endpoints.kubernetes.io/over-capacity:truncated`
|
||||
|
||||
Used on: Endpoints
|
||||
|
||||
In Kubernetes clusters v1.21 (or later), the Endpoints controller adds this annotation to an Endpoints resource if it has more than 1000 endpoints. The annotation indicates that the Endpoints resource is over capacity.
|
||||
In Kubernetes clusters v1.22 (or later), the Endpoints controller adds this annotation to an Endpoints resource if it has more than 1000 endpoints. The annotation indicates that the Endpoints resource is over capacity and the number of endpoints has been truncated to 1000.
|
||||
|
||||
## batch.kubernetes.io/job-tracking
|
||||
|
||||
|
|
|
@ -60,6 +60,9 @@ other = "Older versions"
|
|||
[end_of_life]
|
||||
other = "End of Life:"
|
||||
|
||||
[envvars_heading]
|
||||
other = "Environment variables"
|
||||
|
||||
[error_404_were_you_looking_for]
|
||||
other = "Were you looking for:"
|
||||
|
||||
|
|
Loading…
Reference in New Issue