Merge pull request #19221 from zacharysarah/dev-1.18-repair
Repair and sync the dev-1.18 branch
This commit is contained in:
Vineeth Pothulapati
@@ -30,7 +30,7 @@ A node's status contains the following information:
|
||||
* [Capacity and Allocatable](#capacity)
|
||||
* [Info](#info)
|
||||
|
||||
Node status and other details about a node can be displayed using below command:
|
||||
Node status and other details about a node can be displayed using the following command:
|
||||
```shell
|
||||
kubectl describe node <insert-node-name-here>
|
||||
```
|
||||
@@ -188,7 +188,7 @@ a Lease object.
|
||||
|
||||
In Kubernetes 1.4, we updated the logic of the node controller to better handle
|
||||
cases when a large number of nodes have problems with reaching the master
|
||||
(e.g. because the master has networking problem). Starting with 1.4, the node
|
||||
(e.g. because the master has networking problems). Starting with 1.4, the node
|
||||
controller looks at the state of all nodes in the cluster when making a
|
||||
decision about pod eviction.
|
||||
|
||||
@@ -212,9 +212,9 @@ there is only one availability zone (the whole cluster).
|
||||
|
||||
A key reason for spreading your nodes across availability zones is so that the
|
||||
workload can be shifted to healthy zones when one entire zone goes down.
|
||||
Therefore, if all nodes in a zone are unhealthy then node controller evicts at
|
||||
the normal rate `--node-eviction-rate`. The corner case is when all zones are
|
||||
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such
|
||||
Therefore, if all nodes in a zone are unhealthy then the node controller evicts at
|
||||
the normal rate of `--node-eviction-rate`. The corner case is when all zones are
|
||||
completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a
|
||||
case, the node controller assumes that there's some problem with master
|
||||
connectivity and stops all evictions until some connectivity is restored.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ This is a living document. If you think of something that is not on this list bu
|
||||
- Put object descriptions in annotations, to allow better introspection.
|
||||
|
||||
|
||||
## "Naked" Pods vs ReplicaSets, Deployments, and Jobs
|
||||
## "Naked" Pods versus ReplicaSets, Deployments, and Jobs {#naked-pods-vs-replicasets-deployments-and-jobs}
|
||||
|
||||
- Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure.
|
||||
|
||||
@@ -108,4 +108,3 @@ The caching semantics of the underlying image provider make even `imagePullPolic
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ When you create a custom resource, either via a CRDs or an AA, you get many feat
|
||||
| Finalizers | Block deletion of extension resources until external cleanup happens. |
|
||||
| Admission Webhooks | Set default values and validate extension resources during any create/update/delete operation. |
|
||||
| UI/CLI Display | Kubectl, dashboard can display extension resources. |
|
||||
| Unset vs Empty | Clients can distinguish unset fields from zero-valued fields. |
|
||||
| Unset versus Empty | Clients can distinguish unset fields from zero-valued fields. |
|
||||
| Client Libraries Generation | Kubernetes provides generic client libraries, as well as tools to generate type-specific client libraries. |
|
||||
| Labels and annotations | Common metadata across objects that tools know how to edit for core and custom resources. |
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ weight: 10
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
{{< warning >}}Alpha features change rapidly. {{< /warning >}}
|
||||
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
|
||||
|
||||
Network plugins in Kubernetes come in a few flavors:
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
|
||||
The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes.
|
||||
For example, the `spec` format for a Pod can be found in
|
||||
[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
|
||||
and the `spec` format for a Deployment can be found
|
||||
and the `spec` format for a Deployment can be found in
|
||||
[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
reviewers:
|
||||
- mikedanese
|
||||
- thockin
|
||||
title: Names
|
||||
title: Object Names and IDs
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
@@ -18,14 +18,41 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/conc
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Names
|
||||
|
||||
{{< glossary_definition term_id="name" length="all" >}}
|
||||
|
||||
Kubernetes resources can have names up to 253 characters long. The characters allowed in names are: digits (0-9), lower case letters (a-z), `-`, and `.`.
|
||||
Below are three types of commonly used name constraints for resources.
|
||||
|
||||
### DNS Subdomain Names
|
||||
|
||||
Most resource types require a name that can be used as a DNS subdomain name
|
||||
as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
|
||||
This means the name must:
|
||||
|
||||
- contain no more than 253 characters
|
||||
- contain only lowercase alphanumeric characters, '-' or '.'
|
||||
- start with an alphanumeric character
|
||||
- end with an alphanumeric character
|
||||
|
||||
### DNS Label Names
|
||||
|
||||
Some resource types require their names to follow the DNS
|
||||
label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
|
||||
This means the name must:
|
||||
|
||||
- contain at most 63 characters
|
||||
- contain only lowercase alphanumeric characters or '-'
|
||||
- start with an alphanumeric character
|
||||
- end with an alphanumeric character
|
||||
|
||||
### Path Segment Names
|
||||
|
||||
Some resource types require their names to be able to be safely encoded as a
|
||||
path segment. In other words, the name may not be "." or ".." and the name may
|
||||
not contain "/" or "%".
|
||||
|
||||
Here’s an example manifest for a Pod named `nginx-demo`.
|
||||
|
||||
@@ -42,6 +69,7 @@ spec:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}
|
||||
Some resource types have additional restrictions on their names.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -376,7 +376,7 @@ pods 0 10
|
||||
* `Exist`
|
||||
* `DoesNotExist`
|
||||
|
||||
## Requests vs Limits
|
||||
## Requests compared to Limits {#requests-vs-limits}
|
||||
|
||||
When allocating compute resources, each container may specify a request and a limit value for either CPU or memory.
|
||||
The quota can be configured to quota either value.
|
||||
|
||||
@@ -71,7 +71,7 @@ check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.
|
||||
|
||||
### Binding
|
||||
|
||||
A user creates, or in the case of dynamic provisioning, has already created, a `PersistentVolumeClaim` with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, `PersistentVolumeClaim` binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping.
|
||||
A user creates, or in the case of dynamic provisioning, has already created, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, using a ClaimRef which is a bi-directional binding between the PersistentVolume and the PersistentVolumeClaim.
|
||||
|
||||
Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ One CronJob object is like one line of a _crontab_ (cron table) file. It runs a
|
||||
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
|
||||
{{< note >}}
|
||||
All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated.
|
||||
All **CronJob** `schedule:` times are denoted in UTC.
|
||||
{{< /note >}}
|
||||
|
||||
When creating the manifest for a CronJob resource, make sure the name you provide
|
||||
|
||||
@@ -75,53 +75,50 @@ kubectl describe rs/frontend
|
||||
|
||||
And you will see output similar to:
|
||||
```shell
|
||||
Name: frontend
|
||||
Namespace: default
|
||||
Selector: tier=frontend
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Annotations: <none>
|
||||
Replicas: 3 current / 3 desired
|
||||
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
|
||||
Name: frontend
|
||||
Namespace: default
|
||||
Selector: tier=frontend
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Annotations: kubectl.kubernetes.io/last-applied-configuration:
|
||||
{"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
|
||||
Replicas: 3 current / 3 desired
|
||||
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
|
||||
Pod Template:
|
||||
Labels: app=guestbook
|
||||
tier=frontend
|
||||
Labels: tier=frontend
|
||||
Containers:
|
||||
php-redis:
|
||||
Image: gcr.io/google_samples/gb-frontend:v3
|
||||
Port: 80/TCP
|
||||
Requests:
|
||||
cpu: 100m
|
||||
memory: 100Mi
|
||||
Environment:
|
||||
GET_HOSTS_FROM: dns
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Image: gcr.io/google_samples/gb-frontend:v3
|
||||
Port: <none>
|
||||
Host Port: <none>
|
||||
Environment: <none>
|
||||
Mounts: <none>
|
||||
Volumes: <none>
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-qhloh
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-dnjpy
|
||||
1m 1m 1 {replicaset-controller } Normal SuccessfulCreate Created pod: frontend-9si5l
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm
|
||||
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv
|
||||
Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts
|
||||
```
|
||||
|
||||
And lastly you can check for the Pods brought up:
|
||||
```shell
|
||||
kubectl get Pods
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
You should see Pod information similar to:
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-9si5l 1/1 Running 0 1m
|
||||
frontend-dnjpy 1/1 Running 0 1m
|
||||
frontend-qhloh 1/1 Running 0 1m
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-b2zdv 1/1 Running 0 6m36s
|
||||
frontend-vcmts 1/1 Running 0 6m36s
|
||||
frontend-wtsmm 1/1 Running 0 6m36s
|
||||
```
|
||||
|
||||
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
|
||||
kubectl get pods frontend-b2zdv -o yaml
|
||||
```
|
||||
|
||||
The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field:
|
||||
@@ -129,11 +126,11 @@ The output will look similar to this, with the frontend ReplicaSet's info set in
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
creationTimestamp: 2019-01-31T17:20:41Z
|
||||
creationTimestamp: "2020-02-12T07:06:16Z"
|
||||
generateName: frontend-
|
||||
labels:
|
||||
tier: frontend
|
||||
name: frontend-9si5l
|
||||
name: frontend-b2zdv
|
||||
namespace: default
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
@@ -141,7 +138,7 @@ metadata:
|
||||
controller: true
|
||||
kind: ReplicaSet
|
||||
name: frontend
|
||||
uid: 892a2330-257c-11e9-aecd-025000000001
|
||||
uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
|
||||
...
|
||||
```
|
||||
|
||||
@@ -170,16 +167,17 @@ its desired count.
|
||||
|
||||
Fetching the Pods:
|
||||
```shell
|
||||
kubectl get Pods
|
||||
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
|
||||
frontend-dnjpy 1/1 Running 0 1m
|
||||
frontend-qhloh 1/1 Running 0 1m
|
||||
pod2 0/1 Terminating 0 4s
|
||||
frontend-b2zdv 1/1 Running 0 10m
|
||||
frontend-vcmts 1/1 Running 0 10m
|
||||
frontend-wtsmm 1/1 Running 0 10m
|
||||
pod1 0/1 Terminating 0 1s
|
||||
pod2 0/1 Terminating 0 1s
|
||||
```
|
||||
|
||||
If you create the Pods first:
|
||||
@@ -195,15 +193,15 @@ 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
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
Will reveal in its output:
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
frontend-pxj4r 1/1 Running 0 5s
|
||||
pod1 1/1 Running 0 13s
|
||||
pod2 1/1 Running 0 13s
|
||||
frontend-hmmj2 1/1 Running 0 9s
|
||||
pod1 1/1 Running 0 36s
|
||||
pod2 1/1 Running 0 36s
|
||||
```
|
||||
|
||||
In this manner, a ReplicaSet can own a non-homogenous set of Pods
|
||||
|
||||
Reference in New Issue
Block a user