whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update with master content resolving merge conflicts

Browse Source
This commit is contained in:
MAKOSCAFEE
2019-06-19 19:10:18 +03:00
parent b42f019aae 42cbe1256e
commit 8781518d32
1439 changed files with 70927 additions and 43295 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md
+3 -3
View File
@@ -22,7 +22,7 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi
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.
{{< 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].
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 >}}
@@ -38,8 +38,8 @@ This section describes how the authentication and authorization flows work, and
The high-level flow is as follows:
1. Kubenetes apiserver: authenticate the requesting user and authorize their rights to the requested API path.
2. Kubenetes apiserver: proxy the request to the extension apiserver
1. Kubernetes apiserver: authenticate the requesting user and authorize their rights to the requested API path.
2. Kubernetes apiserver: proxy the request to the extension apiserver
3. Extension apiserver: authenticate the request from the Kubernetes apiserver
4. Extension apiserver: authorize the request from the original user
5. Extension apiserver: execute
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning.md
+1 -1
View File
@@ -175,7 +175,7 @@ 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.13.0/test/images/crd-conversion-webhook/converter/framework.go)) that leaves only [one function]((https://github.com/kubernetes/kubernetes/tree/v1.13.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.14.0/test/images/crd-conversion-webhook/converter/framework.go) that leaves only [one function](https://github.com/kubernetes/kubernetes/blob/v1.13.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
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+1 -1
View File
@@ -156,6 +156,7 @@ from the yaml you used to create it:
```console
apiVersion: v1
kind: List
items:
- apiVersion: stable.example.com/v1
kind: CronTab
@@ -170,7 +171,6 @@ items:
spec:
cronSpec: '* * * * */5'
image: my-awesome-cron-image
kind: List
metadata:
resourceVersion: ""
selfLink: ""