Karen Bradshaw
parent
d4f302e848
commit
5fe8c3ca5e
|
|
@ -31,9 +31,11 @@ The control plane components also communicate with the cluster apiserver over th
|
|||
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
|
||||
|
||||
## Control Plane to node
|
||||
|
||||
There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
|
||||
|
||||
### apiserver to kubelet
|
||||
|
||||
The connections from the apiserver to the kubelet are used for:
|
||||
|
||||
* Fetching logs for pods.
|
||||
|
|
@ -61,9 +63,10 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh
|
|||
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
|
||||
|
||||
### Konnectivity service
|
||||
|
||||
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
|
||||
|
||||
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to Cluster communication. The Konnectivity consists of two parts, the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the connections.
|
||||
All control plane to nodes traffic then goes through these connections.
|
||||
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections.
|
||||
After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
|
||||
|
||||
See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set it up in your cluster.
|
||||
Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.
|
||||
|
|
|
|||
|
|
@ -39,9 +39,9 @@ to disable the timeout restriction. This deprecated feature gate will be removed
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
|
||||
* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
|
||||
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
|
||||
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
|
||||
* Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
|
||||
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ Regardless of how they are installed, the new resources are referred to as Custo
|
|||
|
||||
## CustomResourceDefinitions
|
||||
|
||||
The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
|
||||
The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
API resource allows you to define custom resources.
|
||||
Defining a CRD object creates a new custom resource with a name and schema that you specify.
|
||||
The Kubernetes API serves and handles the storage of your custom resource.
|
||||
|
|
@ -178,17 +178,17 @@ Aggregated APIs offer more advanced API features and customization of other feat
|
|||
|
||||
| Feature | Description | CRDs | Aggregated API |
|
||||
| ------- | ----------- | ---- | -------------- |
|
||||
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
|
||||
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
|
||||
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
|
||||
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
|
||||
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
|
||||
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
|
||||
| Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |
|
||||
| Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
|
||||
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes |
|
||||
| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
|
||||
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | Yes |
|
||||
| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | Yes |
|
||||
| Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
|
||||
| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes |
|
||||
| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
|
||||
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
|
||||
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
|
||||
|
||||
### Common Features
|
||||
|
||||
|
|
@ -253,6 +253,6 @@ When you add a custom resource, you can access it using:
|
|||
|
||||
* Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
|
||||
* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
|
||||
* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -136,10 +136,10 @@ There are several API groups in a cluster:
|
|||
|
||||
There are two paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/):
|
||||
|
||||
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
|
||||
1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resource-definitions/)
|
||||
lets you declaratively define how the API server should provide your chosen resource API.
|
||||
1. You can also [implement your own extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)
|
||||
and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
|
||||
1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/)
|
||||
and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
|
||||
to make it seamless for clients.
|
||||
|
||||
## Enabling or disabling API groups
|
||||
|
|
|
|||
|
|
@ -37,12 +37,12 @@ consistency among topics of a given type.
|
|||
Choose a title that has the keywords you want search engines to find.
|
||||
Create a filename that uses the words in your title separated by hyphens.
|
||||
For example, the topic with title
|
||||
[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
|
||||
[Using an HTTP Proxy to Access the Kubernetes API](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
|
||||
has filename `http-proxy-access-api.md`. You don't need to put
|
||||
"kubernetes" in the filename, because "kubernetes" is already in the
|
||||
URL for the topic, for example:
|
||||
|
||||
/docs/tasks/access-kubernetes-api/http-proxy-access-api/
|
||||
/docs/tasks/extend-kubernetes/http-proxy-access-api/
|
||||
|
||||
## Adding the topic title to the front matter
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,6 @@ tags:
|
|||
---
|
||||
The aggregation layer lets you install additional Kubernetes-style APIs in your cluster.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
|
||||
When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/extend-kubernetes/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: CustomResourceDefinition
|
||||
id: CustomResourceDefinition
|
||||
date: 2018-04-12
|
||||
full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/
|
||||
full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
|
||||
short_description: >
|
||||
Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
|
||||
|
||||
|
|
@ -14,7 +14,6 @@ tags:
|
|||
---
|
||||
Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
|
||||
<!--more-->
|
||||
|
||||
Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs.
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ Currently, there are several API groups in use:
|
|||
|
||||
The two paths that support extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/) are:
|
||||
|
||||
- [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
|
||||
- [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
|
||||
for basic CRUD needs.
|
||||
- [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) for a full set of Kubernetes API semantics to implement their own apiserver.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Kubernetes requires PKI for the following operations:
|
|||
* Client and server certificates for the [front-proxy][proxy]
|
||||
|
||||
{{< note >}}
|
||||
`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/).
|
||||
`front-proxy` certificates are required only if you run kube-proxy to support [an extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/).
|
||||
{{< /note >}}
|
||||
|
||||
etcd also implements mutual TLS to authenticate clients and peers.
|
||||
|
|
@ -162,6 +162,6 @@ These files are used as follows:
|
|||
|
||||
[usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage
|
||||
[kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/
|
||||
[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/
|
||||
[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide
|
|||
You need to have a Kubernetes cluster and the `kubectl` command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes. This section covers a set of initial steps required once for each cluster:
|
||||
|
||||
### Install the GMSACredentialSpec CRD
|
||||
A [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
|
||||
A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml.
|
||||
Next, install the CRD with `kubectl apply -f gmsa-crd.yaml`
|
||||
|
||||
### Install webhooks to validate GMSA users
|
||||
|
|
|
|||
|
|
@ -397,7 +397,7 @@ Learn about additional debugging tools, including:
|
|||
* [Logging](/docs/concepts/cluster-administration/logging/)
|
||||
* [Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||
* [Getting into containers via `exec`](/docs/tasks/debug-application-cluster/get-shell-running-container/)
|
||||
* [Connecting to containers via proxies](/docs/tasks/access-kubernetes-api/http-proxy-access-api/)
|
||||
* [Connecting to containers via proxies](/docs/tasks/extend-kubernetes/http-proxy-access-api/)
|
||||
* [Connecting to containers via port forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
* [Inspect Kubernetes node with crictl](/docs/tasks/debug-application-cluster/crictl/)
|
||||
|
||||
|
|
|
|||
0
content/en/docs/tasks/access-kubernetes-api/_index.md → content/en/docs/tasks/extend-kubernetes/_index.md
Executable file → Normal file
0
content/en/docs/tasks/access-kubernetes-api/_index.md → content/en/docs/tasks/extend-kubernetes/_index.md
Executable file → Normal file
|
|
@ -10,24 +10,19 @@ weight: 10
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
|
||||
|
||||
|
||||
Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{< note >}}
|
||||
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
|
||||
There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
Reusing the same CA for different client types can negatively impact the cluster's ability to function. For more information, see [CA Reusage and Conflicts](#ca-reusage-and-conflicts).
|
||||
{{< /caution >}}
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
|
@ -138,7 +133,10 @@ The Kubernetes apiserver connects to the extension apiserver over TLS, authentic
|
|||
The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` to authenticate to the extension apiserver. In order for the request to be considered valid by a compliant extension apiserver, the following conditions must be met:
|
||||
|
||||
1. The connection must be made using a client certificate that is signed by the CA whose certificate is in `--requestheader-client-ca-file`.
|
||||
2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`. **Note:** You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
|
||||
2. The connection must be made using a client certificate whose CN is one of those listed in `--requestheader-allowed-names`.
|
||||
|
||||
{{< note >}}You can set this option to blank as `--requestheader-allowed-names=""`. This will indicate to an extension apiserver that _any_ CN is acceptable.
|
||||
{{< /note >}}
|
||||
|
||||
When started with these options, the Kubernetes apiserver will:
|
||||
|
||||
|
|
@ -278,10 +276,6 @@ spec:
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
|
||||
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation/).
|
||||
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
|
||||
|
||||
|
||||
|
||||
* [Setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
|
||||
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
|
|
@ -251,11 +251,11 @@ If you later recreate the same CustomResourceDefinition, it will start out empty
|
|||
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
|
||||
CustomResources traditionally store arbitrary JSON (next to `apiVersion`, `kind` and `metadata`, which is validated by the API server implicitly). With [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) a schema can be specified, which is validated during creation and updates, compare below for details and limits of such a schema.
|
||||
|
||||
With `apiextensions.k8s.io/v1` the definition of a structural schema is mandatory for CustomResourceDefinitions, while in `v1beta1` this is still optional.
|
||||
|
||||
A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) which:
|
||||
A structural schema is an [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) which:
|
||||
|
||||
1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of:
|
||||
* a node with `x-kubernetes-int-or-string: true`
|
||||
|
|
@ -364,15 +364,15 @@ Violations of the structural schema rules are reported in the `NonStructural` co
|
|||
|
||||
Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables the following features for `apiextensions.k8s.io/v1beta1`:
|
||||
|
||||
* [Validation Schema Publishing](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
|
||||
* [Webhook Conversion](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion)
|
||||
* [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2)
|
||||
* [Webhook Conversion](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#webhook-conversion)
|
||||
* [Pruning](#preserving-unknown-fields)
|
||||
|
||||
### Pruning versus preserving unknown fields {#preserving-unknown-fields}
|
||||
|
||||
{{< feature-state state="stable" for_k8s_version="v1.16" >}}
|
||||
|
||||
CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
|
||||
CustomResourceDefinitions traditionally store any (possibly validated) JSON as is in etcd. This means that unspecified fields (if there is a [OpenAPI v3.0 validation schema](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) at all) are persisted. This is in contrast to native Kubernetes resources such as a pod where unknown fields are dropped before being persisted to etcd. We call this "pruning" of unknown fields.
|
||||
|
||||
{{< tabs name="CustomResourceDefinition_pruning" >}}
|
||||
{{% tab name="apiextensions.k8s.io/v1" %}}
|
||||
|
|
@ -427,7 +427,7 @@ spec:
|
|||
|
||||
The field `someRandomField` has been pruned.
|
||||
|
||||
Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
|
||||
Note that the `kubectl create` call uses `--validate=false` to skip client-side validation. Because the [OpenAPI validation schemas are also published](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#publish-validation-schema-in-openapi-v2) to kubectl, it will also check for unknown fields and reject those objects long before they are sent to the API server.
|
||||
|
||||
### Controlling pruning
|
||||
|
||||
|
|
@ -533,7 +533,7 @@ allOf:
|
|||
|
||||
With one of those specification, both an integer and a string validate.
|
||||
|
||||
In [Validation Schema Publishing](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
|
||||
In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/extend-api-custom-resource-definitions/#publish-validation-schema-in-openapi-v2), `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above.
|
||||
|
||||
### RawExtension
|
||||
|
||||
|
|
@ -565,7 +565,7 @@ With `x-kubernetes-embedded-resource: true`, the `apiVersion`, `kind` and `metad
|
|||
|
||||
## Serving multiple versions of a CRD
|
||||
|
||||
See [Custom resource definition versioning](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/)
|
||||
See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/)
|
||||
for more information about serving multiple versions of your
|
||||
CustomResourceDefinition and migrating your objects from one version to another.
|
||||
|
||||
|
|
@ -634,7 +634,7 @@ Additionally, the following restrictions are applied to the schema:
|
|||
|
||||
These fields can only be set with specific features enabled:
|
||||
|
||||
- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting).
|
||||
- `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting).
|
||||
|
||||
{{< note >}}
|
||||
Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features.
|
||||
|
|
@ -1456,6 +1456,6 @@ crontabs/my-new-cron-object 3s
|
|||
|
||||
* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1-apiextensions-k8s-io).
|
||||
|
||||
* Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a
|
||||
* Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a
|
||||
CustomResourceDefinition.
|
||||
|
||||
|
|
@ -20,8 +20,6 @@ a Hello world application by entering this command:
|
|||
kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080
|
||||
```
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Using kubectl to start a proxy server
|
||||
|
|
@ -82,11 +80,6 @@ The output should look similar to this:
|
|||
...
|
||||
}
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Learn more about [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy).
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Setup an Extension API Server
|
||||
title: Set up an Extension API Server
|
||||
reviewers:
|
||||
- lavalamp
|
||||
- cheftako
|
||||
|
|
@ -10,7 +10,7 @@ weight: 15
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Setting up an extension API server to work the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
|
||||
Setting up an extension API server to work with the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
|
||||
|
||||
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ Setting up an extension API server to work the aggregation layer allows the Kube
|
|||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* You must [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
|
||||
* You must [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and enable the apiserver flags.
|
||||
|
||||
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Setting up an extension API server to work the aggregation layer allows the Kube
|
|||
|
||||
The following steps describe how to set up an extension-apiserver *at a high level*. These steps apply regardless if you're using YAML configs or using APIs. An attempt is made to specifically identify any differences between the two. For a concrete example of how they can be implemented using YAML configs, you can look at the [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md) in the Kubernetes repo.
|
||||
|
||||
Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/Kubernetes-incubator/apiserver-builder/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you.
|
||||
Alternatively, you can use an existing 3rd party solution, such as [apiserver-builder](https://github.com/kubernetes-sigs/apiserver-builder-alpha/blob/master/README.md), which should generate a skeleton and automate all of the following steps for you.
|
||||
|
||||
1. Make sure the APIService API is enabled (check `--runtime-config`). It should be on by default, unless it's been deliberately turned off in your cluster.
|
||||
1. You may need to make an RBAC rule allowing you to add APIService objects, or get your cluster administrator to make one. (Since API extensions affect the entire cluster, it is not recommended to do testing/development/debug of an API extension in a live cluster.)
|
||||
|
|
@ -45,18 +45,13 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
|
|||
1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
|
||||
1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
|
||||
1. Create a Kubernetes apiservice. The CA cert above should be base64 encoded, stripped of new lines and used as the spec.caBundle in the apiservice. This should not be namespaced. If using the [kube-aggregator API](https://github.com/kubernetes/kube-aggregator/), only pass in the PEM encoded CA bundle because the base 64 encoding is done for you.
|
||||
1. Use kubectl to get your resource. It should return "No resources found." Which means that everything worked but you currently have no objects of that resource type created yet.
|
||||
|
||||
1. Use kubectl to get your resource. When run, kubectl should return "No resources found.". This message
|
||||
indicates that everything worked but you currently have no objects of that resource type created.
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* If you haven't already, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) and enable the apiserver flags.
|
||||
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/api-extension/apiserver-aggregation).
|
||||
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* Walk through the steps to [configure the API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and enable the apiserver flags.
|
||||
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
* Learn how to [Extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
|
||||
|
|
@ -6,36 +6,34 @@ weight: 70
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
The Konnectivity service provides TCP level proxy for the Master → Cluster
|
||||
The Konnectivity service provides a TCP level proxy for the control plane to cluster
|
||||
communication.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Configure the Konnectivity service
|
||||
|
||||
First, you need to configure the API Server to use the Konnectivity service
|
||||
to direct its network traffic to cluster nodes:
|
||||
|
||||
1. Set the `--egress-selector-config-file` flag of the API Server, it is the
|
||||
path to the API Server egress configuration file.
|
||||
1. At the path, create a configuration file. For example,
|
||||
The following steps require an egress configuration, for example:
|
||||
|
||||
{{< codenew file="admin/konnectivity/egress-selector-configuration.yaml" >}}
|
||||
|
||||
You need to configure the API Server to use the Konnectivity service
|
||||
and direct the network traffic to the cluster nodes:
|
||||
|
||||
1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
|
||||
1. Set the `--egress-selector-config-file` flag of the API Server to the path of
|
||||
your API Server egress configuration file.
|
||||
|
||||
Next, you need to deploy the Konnectivity server and agents.
|
||||
[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
|
||||
is a reference implementation.
|
||||
|
||||
Deploy the Konnectivity server on your master node. The provided yaml assumes
|
||||
Deploy the Konnectivity server on your control plane node. The provided
|
||||
`konnectivity-server.yaml` manifest assumes
|
||||
that the Kubernetes components are deployed as a {{< glossary_tooltip text="static Pod"
|
||||
term_id="static-pod" >}} in your cluster. If not, you can deploy the Konnectivity
|
||||
server as a DaemonSet.
|
||||
|
|
@ -49,4 +47,3 @@ Then deploy the Konnectivity agents in your cluster:
|
|||
Last, if RBAC is enabled in your cluster, create the relevant RBAC rules:
|
||||
|
||||
{{< codenew file="admin/konnectivity/konnectivity-rbac.yaml" >}}
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ specified by one of the built-in Kubernetes controllers:
|
|||
In this case, make a note of the controller's `.spec.selector`; the same
|
||||
selector goes into the PDBs `.spec.selector`.
|
||||
|
||||
From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.
|
||||
From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.
|
||||
|
||||
You can also use PDBs with pods which are not controlled by one of the above
|
||||
controllers, or arbitrary groups of pods, but there are some restrictions,
|
||||
|
|
|
|||
|
|
@ -260,7 +260,7 @@ See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
|
|||
By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
|
||||
APIs, cluster administrators must ensure that:
|
||||
|
||||
* The [API aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) is enabled.
|
||||
* The [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) is enabled.
|
||||
|
||||
* The corresponding APIs are registered:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: "Setup Konnectivity Service"
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
|
@ -98,7 +98,6 @@
|
|||
/docs/concepts/configuration/scheduler-perf-tuning/ /docs/concepts/scheduling-eviction/scheduler-perf-tuning/ 301
|
||||
/docs/concepts/configuration/scheduling-framework/ /docs/concepts/scheduling-eviction/scheduling-framework/ 301
|
||||
/docs/concepts/configuration/taint-and-toleration/ /docs/concepts/scheduling-eviction/taint-and-toleration/ 301
|
||||
/docs/concepts/ecosystem/thirdpartyresource/ /docs/tasks/access-kubernetes-api/extend-api-third-party-resource/ 301
|
||||
/docs/concepts/jobs/cron-jobs/ /docs/concepts/workloads/controllers/cron-jobs/ 301
|
||||
/docs/concepts/jobs/run-to-completion-finite-workloads/ /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301
|
||||
/docs/concepts/nodes/node/ /docs/concepts/architecture/nodes/ 301
|
||||
|
|
@ -194,9 +193,13 @@
|
|||
|
||||
/docs/tasks/access-application-cluster/access-cluster.md /docs/tasks/access-application-cluster/access-cluster/ 301!
|
||||
/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301
|
||||
/docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api/ /docs/tasks/access-kubernetes-api/http-proxy-access-api/ 301
|
||||
/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/ 301
|
||||
/docs/tasks/access-kubernetes-api/migrate-third-party-resource/ /docs/tasks/access-kubernetes-api/custom-resources/migrate-third-party-resource/ 301
|
||||
|
||||
/docs/tasks/access-kubernetes-api/access-kubernetes-api/custom-resources/custom-resource-definitions/ /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ 301
|
||||
/docs/tasks/access-kubernetes-api/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/ /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/ 301
|
||||
/docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api/ /docs/tasks/extend-kubernetes/http-proxy-access-api/ 301
|
||||
/docs/tasks/access-kubernetes-api/configure-aggregation-layer/ /docs/tasks/extend-kubernetes/configure-aggregation-layer/ 301
|
||||
/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ 301
|
||||
/docs/tasks/access-kubernetes-api/setup-extension-api-server/ /docs/tasks/extend-kubernetes/setup-extension-api-server/ 301
|
||||
|
||||
/docs/tasks/administer-cluster/apply-resource-quota-limit/ /docs/tasks/administer-cluster/quota-api-object/ 301
|
||||
/docs/tasks/administer-cluster/assign-pods-nodes/ /docs/tasks/configure-pod-container/assign-pods-nodes/ 301
|
||||
|
|
@ -253,6 +256,7 @@
|
|||
/docs/tasks/configure-pod-container/weave-network-policy/ /docs/tasks/administer-cluster/weave-network-policy/ 301
|
||||
/docs/tasks/debug-application-cluster/sematext-logging-monitoring/ https://sematext.com/kubernetes/ 301
|
||||
/docs/tasks/job/work-queue-1/ /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301
|
||||
/docs/tasks/setup-konnectivity/setup-konnectivity/ /docs/tasks/extend-kubernetes/setup-konnectivity/ 301
|
||||
/docs/tasks/kubectl/get-shell-running-container/ /docs/tasks/debug-application-cluster/get-shell-running-container/ 301
|
||||
/docs/tasks/kubectl/install/ /docs/tasks/tools/install-kubectl/ 301
|
||||
/docs/tasks/kubectl/list-all-running-container-images/ /docs/tasks/access-application-cluster/list-all-running-container-images/ 301
|
||||
|
|
@ -404,7 +408,6 @@
|
|||
/docs/user-guide/sharing-clusters/ /docs/tasks/administer-cluster/share-configuration/ 301
|
||||
/docs/user-guide/simple-nginx/ /docs/tasks/run-application/run-stateless-application-deployment/ 301
|
||||
/docs/user-guide/StatefulSet/ /docs/concepts/workloads/controllers/statefulset/ 301
|
||||
/docs/user-guide/thirdpartyresources/ /docs/tasks/access-kubernetes-api/extend-api-third-party-resource/ 301
|
||||
/docs/user-guide/ui/ /docs/tasks/access-application-cluster/web-ui-dashboard/ 301
|
||||
/docs/user-guide/ui-access/ /docs/tasks/access-application-cluster/web-ui-dashboard/ 301
|
||||
/docs/user-guide/update-dem/ /docs/tasks/run-application/rolling-update-replication-controller/ 301
|
||||
|
|
|
|||
Loading…
Reference in New Issue