Merge remote-tracking branch 'upstream/master' into zacharysarah-merged-master-dev-1.18
This commit is contained in:
zacharysarah
@@ -157,7 +157,7 @@ controller deletes the node from its list of nodes.
|
||||
The third is monitoring the nodes' health. The node controller is
|
||||
responsible for updating the NodeReady condition of NodeStatus to
|
||||
ConditionUnknown when a node becomes unreachable (i.e. the node controller stops
|
||||
receiving heartbeats for some reason, e.g. due to the node being down), and then later evicting
|
||||
receiving heartbeats for some reason, for example due to the node being down), and then later evicting
|
||||
all the pods from the node (using graceful termination) if the node continues
|
||||
to be unreachable. (The default timeouts are 40s to start reporting
|
||||
ConditionUnknown and 5m after that to start evicting pods.) The node controller
|
||||
|
||||
@@ -94,7 +94,7 @@ Different settings can be applied to a load balancer service in AWS using _annot
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: Used to specify access log s3 bucket prefix.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: Used on the service to specify a comma-separated list of key-value pairs which will be recorded as additional tags in the ELB. For example: `"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: Used on the service to specify the protocol spoken by the backend (pod) behind a listener. If `http` (default) or `https`, an HTTPS listener that terminates the connection and parses headers is created. If set to `ssl` or `tcp`, a "raw" SSL listener is used. If set to `http` and `aws-load-balancer-ssl-cert` is not used then a HTTP listener is used.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, e.g. `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: Used on the service to request a secure listener. Value is a valid certificate ARN. For more, see [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN is an IAM or CM certificate ARN, for example `arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: Used on the service to enable or disable connection draining.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: Used on the service to specify a connection draining timeout.
|
||||
* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: Used on the service to specify the idle connection timeout.
|
||||
|
||||
@@ -140,7 +140,7 @@ Reasons to prefer fewer clusters per availability zone are:
|
||||
|
||||
- improved bin packing of Pods in some cases with more nodes in one cluster (less resource fragmentation).
|
||||
- reduced operational overhead (though the advantage is diminished as ops tooling and processes mature).
|
||||
- reduced costs for per-cluster fixed resource costs, e.g. apiserver VMs (but small as a percentage
|
||||
- reduced costs for per-cluster fixed resource costs, for example apiserver VMs (but small as a percentage
|
||||
of overall cluster cost for medium to large clusters).
|
||||
|
||||
Reasons to have multiple clusters include:
|
||||
|
||||
@@ -76,7 +76,7 @@ should set up a solution to address that.
|
||||
For example, in Kubernetes clusters, deployed by the `kube-up.sh` script,
|
||||
there is a [`logrotate`](https://linux.die.net/man/8/logrotate)
|
||||
tool configured to run each hour. You can also set up a container runtime to
|
||||
rotate application's logs automatically, e.g. by using Docker's `log-opt`.
|
||||
rotate application's logs automatically, for example by using Docker's `log-opt`.
|
||||
In the `kube-up.sh` script, the latter approach is used for COS image on GCP,
|
||||
and the former approach is used in any other environment. In both cases, by
|
||||
default rotation is configured to take place when log file exceeds 10MB.
|
||||
|
||||
@@ -17,7 +17,7 @@ There are several ways to do this, and the recommended approaches all use
|
||||
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
|
||||
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
|
||||
(e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
|
||||
but there are some circumstances where you may want more control on a node where a pod lands, e.g. to ensure
|
||||
but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
|
||||
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
|
||||
services that communicate a lot into the same availability zone.
|
||||
|
||||
@@ -176,7 +176,7 @@ Y is expressed as a LabelSelector with an optional associated list of namespaces
|
||||
(and therefore the labels on pods are implicitly namespaced),
|
||||
a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
|
||||
like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the
|
||||
key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above
|
||||
key for the node label that the system uses to denote such a topology domain; for example, see the label keys listed above
|
||||
in the section [Interlude: built-in node labels](#built-in-node-labels).
|
||||
|
||||
{{< note >}}
|
||||
@@ -366,7 +366,7 @@ Some of the limitations of using `nodeName` to select nodes are:
|
||||
some cases may be automatically deleted.
|
||||
- If the named node does not have the resources to accommodate the
|
||||
pod, the pod will fail and its reason will indicate why,
|
||||
e.g. OutOfmemory or OutOfcpu.
|
||||
for example OutOfmemory or OutOfcpu.
|
||||
- Node names in cloud environments are not always predictable or
|
||||
stable.
|
||||
|
||||
|
||||
@@ -158,12 +158,9 @@ globalDefault: false
|
||||
description: "This priority class should be used for XYZ service pods only."
|
||||
```
|
||||
|
||||
### Non-preempting PriorityClasses (alpha) {#non-preempting-priority-class}
|
||||
## Non-preempting PriorityClass {#non-preempting-priority-class}
|
||||
|
||||
1.15 adds the `PreemptionPolicy` field as an alpha feature.
|
||||
It is disabled by default in 1.15,
|
||||
and requires the `NonPreemptingPriority`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/
|
||||
) to be enabled.
|
||||
{{< feature-state for_k8s_version="1.15" state="alpha" >}}
|
||||
|
||||
Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue
|
||||
ahead of lower-priority pods,
|
||||
@@ -187,6 +184,10 @@ which will allow pods of that PriorityClass to preempt lower-priority pods
|
||||
If `PreemptionPolicy` is set to `Never`,
|
||||
pods in that PriorityClass will be non-preempting.
|
||||
|
||||
The use of the `PreemptionPolicy` field requires the `NonPreemptingPriority`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
to be enabled.
|
||||
|
||||
An example use case is for data science workloads.
|
||||
A user may submit a job that they want to be prioritized above other workloads,
|
||||
but do not wish to discard existing work by preempting running pods.
|
||||
@@ -194,7 +195,7 @@ The high priority job with `PreemptionPolicy: Never` will be scheduled
|
||||
ahead of other queued pods,
|
||||
as soon as sufficient cluster resources "naturally" become free.
|
||||
|
||||
#### Example Non-preempting PriorityClass
|
||||
### Example Non-preempting PriorityClass
|
||||
|
||||
```yaml
|
||||
apiVersion: scheduling.k8s.io/v1
|
||||
|
||||
@@ -128,7 +128,12 @@ 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/) 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.
|
||||
The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/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.
|
||||
The name of a CRD object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
This frees you from writing your own API server to handle the custom resource,
|
||||
but the generic nature of the implementation means you have less flexibility than with
|
||||
@@ -179,7 +184,7 @@ Aggregated APIs offer more advanced API features and customization of other feat
|
||||
| Custom Storage | If you need storage with a different performance mode (for example, time-series database instead of key-value store) or isolation for security (for example, encryption secrets or different | 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 | <ul><li>Finer-grained access control: user writes spec section, controller writes status section.</li><li>Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource)</li></ul> | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-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 |
|
||||
| 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/run-application/update-api-object-kubectl-patch/) | No | Yes |
|
||||
| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
|
||||
|
||||
@@ -154,7 +154,7 @@ most network plugins.
|
||||
|
||||
Where needed, you can specify the MTU explicitly with the `network-plugin-mtu` kubelet option. For example,
|
||||
on AWS the `eth0` MTU is typically 9001, so you might specify `--network-plugin-mtu=9001`. If you're using IPSEC you
|
||||
might reduce it to allow for encapsulation overhead e.g. `--network-plugin-mtu=8873`.
|
||||
might reduce it to allow for encapsulation overhead; for example: `--network-plugin-mtu=8873`.
|
||||
|
||||
This option is provided to the network-plugin; currently **only kubenet supports `network-plugin-mtu`**.
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
* kube-proxy:
|
||||
* `--proxy-mode=ipvs`
|
||||
* `--cluster-cidrs=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR>`
|
||||
* `--feature-gates="IPv6DualStack=true"`
|
||||
|
||||
{{< caution >}}
|
||||
|
||||
@@ -350,7 +350,7 @@ parameters:
|
||||
contains user password to use when talking to Gluster REST service. These
|
||||
parameters are optional, empty password will be used when both
|
||||
`secretNamespace` and `secretName` are omitted. The provided secret must have
|
||||
type `"kubernetes.io/glusterfs"`, e.g. created in this way:
|
||||
type `"kubernetes.io/glusterfs"`, for example created in this way:
|
||||
|
||||
```
|
||||
kubectl create secret generic heketi-secret \
|
||||
@@ -514,7 +514,7 @@ parameters:
|
||||
same as `adminId`.
|
||||
* `userSecretName`: The name of Ceph Secret for `userId` to map RBD image. It
|
||||
must exist in the same namespace as PVCs. This parameter is required.
|
||||
The provided secret must have type "kubernetes.io/rbd", e.g. created in this
|
||||
The provided secret must have type "kubernetes.io/rbd", for example created in this
|
||||
way:
|
||||
|
||||
```shell
|
||||
@@ -561,7 +561,7 @@ parameters:
|
||||
* `adminSecretName`: secret that holds information about the Quobyte user and
|
||||
the password to authenticate against the API server. The provided secret
|
||||
must have type "kubernetes.io/quobyte" and the keys `user` and `password`,
|
||||
e.g. created in this way:
|
||||
for example:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic quobyte-admin-secret \
|
||||
|
||||
@@ -39,7 +39,8 @@ You can describe a DaemonSet in a YAML file. For example, the `daemonset.yaml` f
|
||||
|
||||
{{< codenew file="controllers/daemonset.yaml" >}}
|
||||
|
||||
* Create a DaemonSet based on the YAML file:
|
||||
Create a DaemonSet based on the YAML file:
|
||||
|
||||
```
|
||||
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
```
|
||||
@@ -50,6 +51,9 @@ As with all other Kubernetes config, a DaemonSet needs `apiVersion`, `kind`, and
|
||||
general information about working with config files, see [deploying applications](/docs/user-guide/deploying-applications/),
|
||||
[configuring containers](/docs/tasks/), and [object management using kubectl](/docs/concepts/overview/working-with-objects/object-management/) documents.
|
||||
|
||||
The name of a DaemonSet object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
A DaemonSet also needs a [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) section.
|
||||
|
||||
### Pod Template
|
||||
|
||||
@@ -1020,6 +1020,8 @@ can create multiple Deployments, one for each release, following the canary patt
|
||||
As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, and `metadata` fields.
|
||||
For general information about working with config files, see [deploying applications](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
|
||||
configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
|
||||
The name of a Deployment object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
||||
|
||||
@@ -58,22 +58,26 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
||||
```
|
||||
|
||||
You can then get the current ReplicaSets deployed:
|
||||
|
||||
```shell
|
||||
kubectl get rs
|
||||
```
|
||||
|
||||
And see the frontend one you created:
|
||||
|
||||
```shell
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
frontend 3 3 3 6s
|
||||
```
|
||||
|
||||
You can also check on the state of the replicaset:
|
||||
You can also check on the state of the ReplicaSet:
|
||||
|
||||
```shell
|
||||
kubectl describe rs/frontend
|
||||
```
|
||||
|
||||
And you will see output similar to:
|
||||
|
||||
```shell
|
||||
Name: frontend
|
||||
Namespace: default
|
||||
@@ -106,11 +110,13 @@ Events:
|
||||
```
|
||||
|
||||
And lastly you can check for the Pods brought up:
|
||||
|
||||
```shell
|
||||
kubectl get Pods
|
||||
```
|
||||
|
||||
You should see Pod information similar to:
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-9si5l 1/1 Running 0 1m
|
||||
@@ -120,11 +126,13 @@ frontend-qhloh 1/1 Running 0 1m
|
||||
|
||||
You can also verify that the owner reference of these pods is set to the frontend ReplicaSet.
|
||||
To do this, get the yaml of one of the Pods running:
|
||||
|
||||
```shell
|
||||
kubectl get pods frontend-9si5l -o yaml
|
||||
```
|
||||
|
||||
The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field:
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -169,11 +177,13 @@ The new Pods will be acquired by the ReplicaSet, and then immediately terminated
|
||||
its desired count.
|
||||
|
||||
Fetching the Pods:
|
||||
|
||||
```shell
|
||||
kubectl get Pods
|
||||
```
|
||||
|
||||
The output shows that the new Pods are either already terminated, or in the process of being terminated:
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-9si5l 1/1 Running 0 1m
|
||||
@@ -183,17 +193,20 @@ pod2 0/1 Terminating 0 4s
|
||||
```
|
||||
|
||||
If you create the Pods first:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml
|
||||
```
|
||||
|
||||
And then create the ReplicaSet however:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
|
||||
```
|
||||
|
||||
You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the
|
||||
number of its new Pods and the original matches its desired count. As fetching the Pods:
|
||||
|
||||
```shell
|
||||
kubectl get Pods
|
||||
```
|
||||
@@ -215,6 +228,9 @@ For ReplicaSets, the kind is always just ReplicaSet.
|
||||
In Kubernetes 1.9 the API version `apps/v1` on the ReplicaSet kind is the current version and is enabled by default. The API version `apps/v1beta2` is deprecated.
|
||||
Refer to the first lines of the `frontend.yaml` example for guidance.
|
||||
|
||||
The name of a ReplicaSet object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
||||
### Pod Template
|
||||
|
||||
@@ -109,10 +109,15 @@ In the above example:
|
||||
* The StatefulSet, named `web`, has a Spec that indicates that 3 replicas of the nginx container will be launched in unique Pods.
|
||||
* The `volumeClaimTemplates` will provide stable storage using [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisioned by a PersistentVolume Provisioner.
|
||||
|
||||
The name of a StatefulSet object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
## Pod Selector
|
||||
|
||||
You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
|
||||
|
||||
## Pod Identity
|
||||
|
||||
StatefulSet Pods have a unique identity that is comprised of an ordinal, a
|
||||
stable network identity, and stable storage. The identity sticks to the Pod,
|
||||
regardless of which node it's (re)scheduled on.
|
||||
|
||||
@@ -732,7 +732,7 @@ For Kubernetes 1.9 and earlier, we recommend running the following set of admiss
|
||||
```
|
||||
|
||||
* It's worth reiterating that in 1.9, these happen in a mutating phase
|
||||
and a validating phase, and that e.g. `ResourceQuota` runs in the validating
|
||||
and a validating phase, and that for example `ResourceQuota` runs in the validating
|
||||
phase, and therefore is the last admission controller to run.
|
||||
`MutatingAdmissionWebhook` appears before it in this list, because it runs
|
||||
in the mutating phase.
|
||||
|
||||
@@ -1048,7 +1048,7 @@ to turn up in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
|
||||
Attempting to use a user or basic auth (for example "user:password@") is not allowed.
|
||||
Fragments ("#...") and query parameters ("?...") are also not allowed.
|
||||
|
||||
Here is an example of a mutating webhook configured to call a URL
|
||||
|
||||
@@ -578,7 +578,7 @@ A number of markers were added in Kubernetes 1.16 and 1.17, to allow API develop
|
||||
| Golang marker | OpenAPI extension | Accepted values | Description | Introduced in |
|
||||
|---|---|---|---|---|
|
||||
| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `granular`, different managers can manage entries separately. | 1.16 |
|
||||
| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 |
|
||||
| `//+listMapKeys` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. | 1.16 |
|
||||
| `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 |
|
||||
| `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 |
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ The following production environment solutions table lists the providers and the
|
||||
| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
|
||||
| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | |
|
||||
| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | |
|
||||
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
|
||||
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
|
||||
| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ |
|
||||
|
||||
+1
-1
@@ -397,7 +397,7 @@ If your network is not working or CoreDNS is not in the Running state, checkout
|
||||
### Control plane node isolation
|
||||
|
||||
By default, your cluster will not schedule Pods on the control-plane node for security
|
||||
reasons. If you want to be able to schedule Pods on the control-plane node, e.g. for a
|
||||
reasons. If you want to be able to schedule Pods on the control-plane node, for example for a
|
||||
single-machine Kubernetes cluster for development, run:
|
||||
|
||||
```bash
|
||||
|
||||
+1
-1
@@ -63,7 +63,7 @@ The jsonpath is interpreted as follows:
|
||||
- `.image`: get the image
|
||||
|
||||
{{< note >}}
|
||||
When fetching a single Pod by name, e.g. `kubectl get pod nginx`,
|
||||
When fetching a single Pod by name, for example `kubectl get pod nginx`,
|
||||
the `.items[*]` portion of the path should be omitted because a single
|
||||
Pod is returned instead of a list of items.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -113,7 +113,7 @@ track=stable
|
||||
|
||||
- **Image Pull Secret**: In case the specified Docker container image is private, it may require [pull secret](/docs/concepts/configuration/secret/) credentials.
|
||||
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, e.g. `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
|
||||
Dashboard offers all available secrets in a dropdown list, and allows you to create a new secret. The secret name must follow the DNS domain name syntax, for example `new.image-pull.secret`. The content of a secret must be base64-encoded and specified in a [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) file. The secret name may consist of a maximum of 253 characters.
|
||||
|
||||
In case the creation of the image pull secret is successful, it is selected by default. If the creation fails, no secret is applied.
|
||||
|
||||
|
||||
@@ -246,6 +246,9 @@ spec:
|
||||
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
|
||||
```
|
||||
|
||||
The name of an APIService object must be a valid
|
||||
[path segment name](/docs/concepts/overview/working-with-objects/names#path-segment-names).
|
||||
|
||||
#### Contacting the extension apiserver
|
||||
|
||||
Once the Kubernetes apiserver has determined a request should be sent to a extension apiserver,
|
||||
|
||||
+1
-1
@@ -502,7 +502,7 @@ to turn up in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
|
||||
Attempting to use a user or basic auth (for example "user:password@") is not allowed.
|
||||
Fragments ("#...") and query parameters ("?...") are also not allowed.
|
||||
|
||||
Here is an example of a conversion webhook configured to call a URL
|
||||
|
||||
+1
-1
@@ -366,7 +366,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables
|
||||
|
||||
{{< feature-state state="stable" for_kubernetes_version="1.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 like e.g. 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/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.
|
||||
|
||||
{{< tabs name="CustomResourceDefinition_pruning" >}}
|
||||
{{% tab name="apiextensions.k8s.io/v1" %}}
|
||||
|
||||
@@ -37,7 +37,7 @@ The agent configuration file must be written in YAML or JSON syntax, and may con
|
||||
|
||||
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
|
||||
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
|
||||
* **resyncInterval:** An interval at which the agent attempts to reload config from disk. e.g. '30s' where 's' is seconds, 'ms' is milliseconds etc...
|
||||
* **resyncInterval:** A time interval at which the agent attempts to reload config from disk. For example: '30s', where 's' means seconds, 'ms' means milliseconds, etc...
|
||||
|
||||
Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent:
|
||||
|
||||
|
||||
@@ -72,9 +72,9 @@ cluster admin on a per-node basis. Pods with disabled unsafe sysctls will be
|
||||
scheduled, but will fail to launch.
|
||||
|
||||
With the warning above in mind, the cluster admin can allow certain _unsafe_
|
||||
sysctls for very special situations like e.g. high-performance or real-time
|
||||
sysctls for very special situations such as high-performance or real-time
|
||||
application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
|
||||
flag of the kubelet, e.g.:
|
||||
flag of the kubelet; for example:
|
||||
|
||||
```shell
|
||||
kubelet --allowed-unsafe-sysctls \
|
||||
|
||||
@@ -63,7 +63,7 @@ For example, this is how to start a simple web server as a static Pod:
|
||||
ssh my-node1
|
||||
```
|
||||
|
||||
2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, e.g. `/etc/kubelet.d/static-web.yaml`:
|
||||
2. Choose a directory, say `/etc/kubelet.d` and place a web server Pod definition there, for example `/etc/kubelet.d/static-web.yaml`:
|
||||
|
||||
```shell
|
||||
# Run this command on the node where kubelet is running
|
||||
|
||||
@@ -34,13 +34,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
|
||||
|
||||
```sh
|
||||
# Linux
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-linux-amd64 -o kompose
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-linux-amd64 -o kompose
|
||||
|
||||
# macOS
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-darwin-amd64 -o kompose
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-darwin-amd64 -o kompose
|
||||
|
||||
# Windows
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.16.0/kompose-windows-amd64.exe -o kompose.exe
|
||||
curl -L https://github.com/kubernetes/kompose/releases/download/v1.21.0/kompose-windows-amd64.exe -o kompose.exe
|
||||
|
||||
chmod +x kompose
|
||||
sudo mv ./kompose /usr/local/bin/kompose
|
||||
@@ -580,7 +580,7 @@ If you want to create normal pods without controllers you can use `restart` cons
|
||||
The controller object could be `deployment` or `replicationcontroller`, etc.
|
||||
{{< /note >}}
|
||||
|
||||
For e.g. `pival` service will become pod down here. This container calculated value of `pi`.
|
||||
For example, the `pival` service will become pod down here. This container calculated value of `pi`.
|
||||
|
||||
```yaml
|
||||
version: '2'
|
||||
|
||||
@@ -272,7 +272,7 @@ to turn up in a new cluster.
|
||||
|
||||
The scheme must be "https"; the URL must begin with "https://".
|
||||
|
||||
Attempting to use a user or basic auth e.g. "user:password@" is not allowed.
|
||||
Attempting to use a user or basic auth (for example "user:password@") is not allowed.
|
||||
Fragments ("#...") and query parameters ("?...") are also not allowed.
|
||||
|
||||
Here is an example of a webhook configured to call a URL
|
||||
|
||||
@@ -55,7 +55,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your
|
||||
- Network partition within cluster, or between cluster and users
|
||||
- Crashes in Kubernetes software
|
||||
- Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume)
|
||||
- Operator error, e.g. misconfigured Kubernetes software or application software
|
||||
- Operator error, for example misconfigured Kubernetes software or application software
|
||||
|
||||
### Specific scenarios:
|
||||
|
||||
|
||||
@@ -362,7 +362,7 @@ you want to add Kafka sink for messages from a particular container for addition
|
||||
You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
|
||||
with minor changes:
|
||||
|
||||
* Change Makefile to point to your container repository, e.g. `PREFIX=gcr.io/<your-project-id>`.
|
||||
* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/<your-project-id>`.
|
||||
* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`.
|
||||
|
||||
Then run `make build push` from this directory. After updating `DaemonSet` to pick up the
|
||||
|
||||
@@ -21,9 +21,7 @@ encryption keys, into Pods.
|
||||
## Convert your secret data to a base-64 representation
|
||||
|
||||
Suppose you want to have two pieces of secret data: a username `my-app` and a password
|
||||
`39528$vdg7Jb`. First, use online Base 64 Encoding Tool [Base64 encoding](https://www.base64encode.org/), [Base64 encode](https://goonlinetools.com/base64-encode/) to
|
||||
convert your username and password to a base-64 representation. Here's a Linux
|
||||
example:
|
||||
`39528$vdg7Jb`. First, use a base64 encoding tool to convert your username and password to a base64 representation. Here's an example using the commonly available base64 program:
|
||||
|
||||
```shell
|
||||
echo -n 'my-app' | base64
|
||||
|
||||
@@ -132,7 +132,8 @@ NAME CONTROLLER REVISION AGE
|
||||
```
|
||||
|
||||
Each `ControllerRevision` stores the annotations and template of a DaemonSet
|
||||
revision.
|
||||
revision. The name of a ControllerRevision object must be a valid
|
||||
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
|
||||
|
||||
`kubectl rollout undo` takes a specific `ControllerRevision` and replaces
|
||||
DaemonSet template with the template stored in the `ControllerRevision`.
|
||||
|
||||
@@ -33,7 +33,7 @@ DaemonSet has two update strategy types:
|
||||
* RollingUpdate: This is the default update strategy.
|
||||
With `RollingUpdate` update strategy, after you update a
|
||||
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
|
||||
will be created automatically, in a controlled fashion.
|
||||
will be created automatically, in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process.
|
||||
|
||||
## Performing a Rolling Update
|
||||
|
||||
|
||||
Reference in New Issue
Block a user