Merge pull request #26352 from kbhawkey/fixup-remove-word-easy
clean up use of word: easy
This commit is contained in:
Kubernetes Prow Robot
@@ -68,8 +68,8 @@ when interpreted by an [authorizer](/docs/reference/access-authn-authz/authoriza
|
||||
|
||||
You can enable multiple authentication methods at once. You should usually use at least two methods:
|
||||
|
||||
- service account tokens for service accounts
|
||||
- at least one other method for user authentication.
|
||||
- service account tokens for service accounts
|
||||
- at least one other method for user authentication.
|
||||
|
||||
When multiple authenticator modules are enabled, the first module
|
||||
to successfully authenticate the request short-circuits evaluation.
|
||||
@@ -321,13 +321,11 @@ sequenceDiagram
|
||||
9. `kubectl` provides feedback to the user
|
||||
|
||||
Since all of the data needed to validate who you are is in the `id_token`, Kubernetes doesn't need to
|
||||
"phone home" to the identity provider. In a model where every request is stateless this provides a very scalable
|
||||
solution for authentication. It does offer a few challenges:
|
||||
|
||||
1. Kubernetes has no "web interface" to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
|
||||
2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
|
||||
3. There's no easy way to authenticate to the Kubernetes dashboard without using the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
|
||||
"phone home" to the identity provider. In a model where every request is stateless this provides a very scalable solution for authentication. It does offer a few challenges:
|
||||
|
||||
1. Kubernetes has no "web interface" to trigger the authentication process. There is no browser or interface to collect credentials which is why you need to authenticate to your identity provider first.
|
||||
2. The `id_token` can't be revoked, it's like a certificate so it should be short-lived (only a few minutes) so it can be very annoying to have to get a new token every few minutes.
|
||||
3. To authenticate to the Kubernetes dashboard, you must the `kubectl proxy` command or a reverse proxy that injects the `id_token`.
|
||||
|
||||
#### Configuring the API Server
|
||||
|
||||
|
||||
@@ -1093,8 +1093,8 @@ be a layering violation). `host` may also be an IP address.
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is
|
||||
risky unless you take great care to run this webhook on all hosts
|
||||
which run an apiserver which might need to make calls to this
|
||||
webhook. Such installs are likely to be non-portable, i.e., not easy
|
||||
to turn up in a new cluster.
|
||||
webhook. Such installations are likely to be non-portable or not readily
|
||||
run in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
|
||||
@@ -12,9 +12,8 @@ tags:
|
||||
---
|
||||
Facilitates the discussion and/or implementation of a short-lived, narrow, or decoupled project for a committee, {{< glossary_tooltip text="SIG" term_id="sig" >}}, or cross-SIG effort.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Working groups are a way of organizing people to accomplish a discrete task, and are relatively easy to create and deprecate when inactive.
|
||||
Working groups are a way of organizing people to accomplish a discrete task.
|
||||
|
||||
For more information, see the [kubernetes/community](https://github.com/kubernetes/community) repo and the current list of [SIGs and working groups](https://github.com/kubernetes/community/blob/master/sig-list.md).
|
||||
|
||||
|
||||
+6
-6
@@ -250,15 +250,15 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear
|
||||
- **conversion.webhook.clientConfig.url** (string)
|
||||
|
||||
url gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.
|
||||
|
||||
|
||||
The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
|
||||
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.
|
||||
|
||||
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
|
||||
A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.
|
||||
|
||||
|
||||
Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
|
||||
|
||||
- **preserveUnknownFields** (boolean)
|
||||
|
||||
+6
-6
@@ -82,15 +82,15 @@ MutatingWebhookConfiguration describes the configuration of and admission webhoo
|
||||
- **webhooks.clientConfig.url** (string)
|
||||
|
||||
`url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.
|
||||
|
||||
|
||||
The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
|
||||
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.
|
||||
|
||||
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
|
||||
A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.
|
||||
|
||||
|
||||
Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
|
||||
|
||||
- **webhooks.name** (string), required
|
||||
|
||||
+6
-6
@@ -82,15 +82,15 @@ ValidatingWebhookConfiguration describes the configuration of and admission webh
|
||||
- **webhooks.clientConfig.url** (string)
|
||||
|
||||
`url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified.
|
||||
|
||||
|
||||
The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address.
|
||||
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster.
|
||||
|
||||
|
||||
Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
|
||||
A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier.
|
||||
|
||||
|
||||
Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either.
|
||||
|
||||
- **webhooks.name** (string), required
|
||||
|
||||
@@ -28,7 +28,7 @@ The cluster that `kubeadm init` and `kubeadm join` set up should be:
|
||||
- lock-down the kubelet API
|
||||
- locking down access to the API for system components like the kube-proxy and CoreDNS
|
||||
- locking down what a Bootstrap Token can access
|
||||
- **Easy to use**: The user should not have to run anything more than a couple of commands:
|
||||
- **User-friendly**: The user should not have to run anything more than a couple of commands:
|
||||
- `kubeadm init`
|
||||
- `export KUBECONFIG=/etc/kubernetes/admin.conf`
|
||||
- `kubectl apply -f <network-of-choice.yaml>`
|
||||
|
||||
@@ -108,7 +108,7 @@ if the `kubeadm init` command was called with `--upload-certs`.
|
||||
control-plane node even if other worker nodes or the network are compromised.
|
||||
|
||||
- Convenient to execute manually since all of the information required fits
|
||||
into a single `kubeadm join` command that is easy to copy and paste.
|
||||
into a single `kubeadm join` command.
|
||||
|
||||
**Disadvantages:**
|
||||
|
||||
|
||||
@@ -20,8 +20,8 @@ Kubernetes contains several built-in tools to help you work with the Kubernetes
|
||||
|
||||
## Minikube
|
||||
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that makes it
|
||||
easy to run a single-node Kubernetes cluster locally on your workstation for
|
||||
[`minikube`](https://minikube.sigs.k8s.io/docs/) is a tool that
|
||||
runs a single-node Kubernetes cluster locally on your workstation for
|
||||
development and testing purposes.
|
||||
|
||||
## Dashboard
|
||||
@@ -51,4 +51,3 @@ Use Kompose to:
|
||||
* Translate a Docker Compose file into Kubernetes objects
|
||||
* Go from local Docker development to managing your application via Kubernetes
|
||||
* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
|
||||
|
||||
|
||||
@@ -297,7 +297,7 @@ is not what the user wants to happen, even temporarily.
|
||||
|
||||
There are two solutions:
|
||||
|
||||
- (easy) Leave `replicas` in the configuration; when HPA eventually writes to that
|
||||
- (basic) Leave `replicas` in the configuration; when HPA eventually writes to that
|
||||
field, the system gives the user a conflict over it. At that point, it is safe
|
||||
to remove from the configuration.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user