Merge master into dev-1.19 to keep in sync
This commit is contained in:
Anna Jung
@@ -9,7 +9,8 @@ weight: 20
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
|
||||
Kubernetes ships with a default scheduler that is described
|
||||
[here](/docs/reference/command-line-tools-reference/kube-scheduler/).
|
||||
If the default scheduler does not suit your needs you can implement your own scheduler.
|
||||
Not just that, you can even run multiple schedulers simultaneously alongside the default
|
||||
scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's
|
||||
@@ -20,16 +21,10 @@ document. Please refer to the kube-scheduler implementation in
|
||||
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
|
||||
in the Kubernetes source directory for a canonical example.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Package the scheduler
|
||||
@@ -83,7 +78,7 @@ Note also that we created a dedicated service account `my-scheduler` and bind th
|
||||
`system:kube-scheduler` to it so that it can acquire the same privileges as `kube-scheduler`.
|
||||
|
||||
Please see the
|
||||
[kube-scheduler documentation](/docs/admin/kube-scheduler/) for
|
||||
[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for
|
||||
detailed description of other command line arguments.
|
||||
|
||||
## Run the second scheduler in the cluster
|
||||
@@ -100,6 +95,7 @@ Verify that the scheduler pod is running:
|
||||
```shell
|
||||
kubectl get pods --namespace=kube-system
|
||||
```
|
||||
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
....
|
||||
@@ -125,8 +121,10 @@ The control plane creates the lock objects for you, but the namespace must alrea
|
||||
You can use the `kube-system` namespace.
|
||||
{{< /note >}}
|
||||
|
||||
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
|
||||
```
|
||||
If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role.
|
||||
Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
|
||||
|
||||
```shell
|
||||
kubectl edit clusterrole system:kube-scheduler
|
||||
```
|
||||
|
||||
@@ -134,10 +132,11 @@ kubectl edit clusterrole system:kube-scheduler
|
||||
|
||||
## Specify schedulers for pods
|
||||
|
||||
Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the
|
||||
Now that our second scheduler is running, let's create some pods, and direct them
|
||||
to be scheduled by either the default scheduler or the one we just deployed.
|
||||
In order to schedule a given pod using a specific scheduler, we specify the name of the
|
||||
scheduler in that pod spec. Let's look at three examples.
|
||||
|
||||
|
||||
- Pod spec without any scheduler name
|
||||
|
||||
{{< codenew file="admin/sched/pod1.yaml" >}}
|
||||
@@ -147,9 +146,9 @@ scheduler in that pod spec. Let's look at three examples.
|
||||
|
||||
Save this file as `pod1.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
```shell
|
||||
kubectl create -f pod1.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f pod1.yaml
|
||||
```
|
||||
|
||||
- Pod spec with `default-scheduler`
|
||||
|
||||
@@ -160,9 +159,9 @@ kubectl create -f pod1.yaml
|
||||
|
||||
Save this file as `pod2.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
```shell
|
||||
kubectl create -f pod2.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f pod2.yaml
|
||||
```
|
||||
|
||||
- Pod spec with `my-scheduler`
|
||||
|
||||
@@ -174,17 +173,15 @@ kubectl create -f pod2.yaml
|
||||
|
||||
Save this file as `pod3.yaml` and submit it to the Kubernetes cluster.
|
||||
|
||||
```shell
|
||||
kubectl create -f pod3.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl create -f pod3.yaml
|
||||
```
|
||||
|
||||
Verify that all three pods are running.
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
|
||||
```shell
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
@@ -206,4 +203,3 @@ verify that the pods were scheduled by the desired schedulers.
|
||||
kubectl get events
|
||||
```
|
||||
|
||||
|
||||
|
||||
+19
-11
@@ -13,19 +13,15 @@ This page explains how to add versioning information to
|
||||
[CustomResourceDefinitions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions), to indicate the stability
|
||||
level of your CustomResourceDefinitions or advance your API to a new version with conversion between API representations. It also describes how to upgrade an object from one version to another.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
You should have a initial understanding of [custom resources](/docs/concepts/api-extension/custom-resources/).
|
||||
You should have a initial understanding of [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
{{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Overview
|
||||
@@ -374,7 +370,9 @@ conversions that call an external service in case a conversion is required. For
|
||||
* Watch is created in one version but the changed object is stored in another version.
|
||||
* custom resource PUT request is in a different version than storage version.
|
||||
|
||||
To cover all of these cases and to optimize conversion by the API server, the conversion requests may contain multiple objects in order to minimize the external calls. The webhook should perform these conversions independently.
|
||||
To cover all of these cases and to optimize conversion by the API server,
|
||||
the conversion requests may contain multiple objects in order to minimize the external calls.
|
||||
The webhook should perform these conversions independently.
|
||||
|
||||
### Write a conversion webhook server
|
||||
|
||||
@@ -385,7 +383,12 @@ that is validated in a Kubernetes e2e test. The webhook handles the
|
||||
results wrapped in `ConversionResponse`. Note that the request
|
||||
contains a list of custom resources that need to be converted independently without
|
||||
changing the order of objects.
|
||||
The example server is organized in a way to be reused for other conversions. Most of the common code are located in the [framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80) to be implemented for different conversions.
|
||||
The example server is organized in a way to be reused for other conversions.
|
||||
Most of the common code are located in the
|
||||
[framework file](https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/images/crd-conversion-webhook/converter/framework.go)
|
||||
that leaves only
|
||||
[one function](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/images/crd-conversion-webhook/converter/example_converter.go#L29-L80)
|
||||
to be implemented for different conversions.
|
||||
|
||||
{{< note >}}
|
||||
The example conversion webhook server leaves the `ClientAuth` field
|
||||
@@ -398,12 +401,17 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-
|
||||
|
||||
#### Permissible mutations
|
||||
|
||||
A conversion webhook must not mutate anything inside of `metadata` of the converted object other than `labels` and `annotations`. Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request which caused the conversion. All other changes are just ignored.
|
||||
A conversion webhook must not mutate anything inside of `metadata` of the converted object
|
||||
other than `labels` and `annotations`.
|
||||
Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request
|
||||
which caused the conversion. All other changes are just ignored.
|
||||
|
||||
### Deploy the conversion webhook service
|
||||
|
||||
Documentation for deploying the conversion webhook is the same as for the [admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
|
||||
The assumption for next sections is that the conversion webhook server is deployed to a service named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
|
||||
Documentation for deploying the conversion webhook is the same as for the
|
||||
[admission webhook example service](/docs/reference/access-authn-authz/extensible-admission-controllers/#deploy_the_admission_webhook_service).
|
||||
The assumption for next sections is that the conversion webhook server is deployed to a service
|
||||
named `example-conversion-webhook-server` in `default` namespace and serving traffic on path `/crdconvert`.
|
||||
|
||||
{{< note >}}
|
||||
When the webhook server is deployed into the Kubernetes cluster as a
|
||||
@@ -639,7 +647,7 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa
|
||||
{{< tabs name="CustomResourceDefinition_versioning_example_4" >}}
|
||||
{{% tab name="apiextensions.k8s.io/v1" %}}
|
||||
```yaml
|
||||
apiVersion: apiextensions.k8s.io/v1b
|
||||
apiVersion: apiextensions.k8s.io/v1
|
||||
kind: CustomResourceDefinition
|
||||
...
|
||||
spec:
|
||||
|
||||
+9
-9
@@ -16,7 +16,6 @@ This page shows how to install a
|
||||
into the Kubernetes API by creating a
|
||||
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
@@ -24,9 +23,7 @@ into the Kubernetes API by creating a
|
||||
|
||||
* Make sure your Kubernetes cluster has a master version of 1.16.0 or higher to use `apiextensions.k8s.io/v1`, or 1.7.0 or higher for `apiextensions.k8s.io/v1beta1`.
|
||||
|
||||
* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
|
||||
|
||||
|
||||
* Read about [custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
@@ -427,7 +424,9 @@ 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/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.
|
||||
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,11 +532,14 @@ allOf:
|
||||
|
||||
With one of those specification, both an integer and a string validate.
|
||||
|
||||
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.
|
||||
In [Validation Schema Publishing](/docs/tasks/extend-kubernetes/custom-resources/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
|
||||
|
||||
RawExtensions (as in `runtime.RawExtension` defined in [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.
|
||||
RawExtensions (as in `runtime.RawExtension` defined in
|
||||
[k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94))
|
||||
holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields.
|
||||
|
||||
It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example:
|
||||
|
||||
@@ -569,8 +571,6 @@ See [Custom resource definition versioning](/docs/tasks/extend-kubernetes/custom
|
||||
for more information about serving multiple versions of your
|
||||
CustomResourceDefinition and migrating your objects from one version to another.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
## Advanced topics
|
||||
|
||||
|
||||
Reference in New Issue
Block a user