resolving conflicts
This commit is contained in:
@@ -1,3 +1,4 @@
|
||||
---
|
||||
linktitle: Kubernetes Documentation
|
||||
title: Documentation
|
||||
---
|
||||
|
||||
@@ -113,9 +113,9 @@ useful changes, it doesn't matter if the overall state is or is not stable.
|
||||
As a tenet of its design, Kubernetes uses lots of controllers that each manage
|
||||
a particular aspect of cluster state. Most commonly, a particular control loop
|
||||
(controller) uses one kind of resource as its desired state, and has a different
|
||||
kind of resource that it manages to make that desired state happen. For example,
|
||||
kind of resource that it manages to make that desired state happen. For example,
|
||||
a controller for Jobs tracks Job objects (to discover new work) and Pod objects
|
||||
(to run the Jobs, and then to see when the work is finished). In this case
|
||||
(to run the Jobs, and then to see when the work is finished). In this case
|
||||
something else creates the Jobs, whereas the Job controller creates Pods.
|
||||
|
||||
It's useful to have simple controllers rather than one, monolithic set of control
|
||||
@@ -154,8 +154,7 @@ controller does.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane)
|
||||
* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects)
|
||||
* Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components)
|
||||
* Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
|
||||
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
|
||||
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ You can modify Node objects regardless of the setting of `--register-node`.
|
||||
For example, you can set labels on an existing Node, or mark it unschedulable.
|
||||
|
||||
You can use labels on Nodes in conjunction with node selectors on Pods to control
|
||||
scheduling. For example, you can to constrain a Pod to only be eligible to run on
|
||||
scheduling. For example, you can constrain a Pod to only be eligible to run on
|
||||
a subset of the available nodes.
|
||||
|
||||
Marking a node as unschedulable prevents the scheduler from placing new pods onto
|
||||
|
||||
@@ -29,7 +29,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
|
||||
* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
|
||||
|
||||
## Service Discovery
|
||||
|
||||
@@ -49,5 +49,3 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
|
||||
There are several other add-ons documented in the deprecated [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) directory.
|
||||
|
||||
Well-maintained ones should be linked to here. PRs welcome!
|
||||
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ weight: 30
|
||||
|
||||
<!-- overview -->
|
||||
This page explains how to manage Kubernetes running on a specific
|
||||
cloud provider.
|
||||
cloud provider. There are many other third-party cloud provider projects, but this list is specific to projects embedded within, or relied upon by Kubernetes itself.
|
||||
|
||||
<!-- body -->
|
||||
### kubeadm
|
||||
@@ -116,15 +116,6 @@ If you wish to use the external cloud provider, its repository is [kubernetes/cl
|
||||
The Azure cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Azure VM name.
|
||||
|
||||
## CloudStack
|
||||
|
||||
If you wish to use the external cloud provider, its repository is [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)
|
||||
|
||||
### Node Name
|
||||
|
||||
The CloudStack cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the CloudStack VM name.
|
||||
|
||||
## GCE
|
||||
|
||||
If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)
|
||||
@@ -138,11 +129,6 @@ Note that the first segment of the Kubernetes Node name must match the GCE insta
|
||||
|
||||
If you wish to use the external cloud provider, its repository is [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud).
|
||||
|
||||
### Node Name
|
||||
|
||||
The HUAWEI CLOUD provider needs the private IP address of the node as the name of the Kubernetes Node object.
|
||||
Please make sure indicating `--hostname-override=<node private IP>` when starting kubelet on the node.
|
||||
|
||||
## OpenStack
|
||||
This section describes all the possible configurations which can
|
||||
be used when using OpenStack with Kubernetes.
|
||||
@@ -251,11 +237,9 @@ file:
|
||||
values are `v1` or `v2`. Where no value is provided automatic detection will
|
||||
select the highest supported version exposed by the underlying OpenStack
|
||||
cloud.
|
||||
* `use-octavia` (Optional): Used to determine whether to look for and use an
|
||||
Octavia LBaaS V2 service catalog endpoint. Valid values are `true` or `false`.
|
||||
Where `true` is specified and an Octaiva LBaaS V2 entry can not be found, the
|
||||
provider will fall back and attempt to find a Neutron LBaaS V2 endpoint
|
||||
instead. The default value is `false`.
|
||||
* `use-octavia`(Optional): Whether or not to use Octavia for LoadBalancer type
|
||||
of Service implementation instead of using Neutron-LBaaS. Default: true
|
||||
Attention: Openstack CCM use Octavia as default load balancer implementation since v1.17.0
|
||||
* `subnet-id` (Optional): Used to specify the id of the subnet you want to
|
||||
create your loadbalancer on. Can be found at Network > Networks. Click on the
|
||||
respective network to get its subnets.
|
||||
@@ -362,19 +346,7 @@ Kubernetes network plugin and should appear in the `[Route]` section of the
|
||||
[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)
|
||||
on OpenStack.
|
||||
|
||||
## OVirt
|
||||
|
||||
### Node Name
|
||||
|
||||
The OVirt cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the VM FQDN (reported by OVirt under `<vm><guest_info><fqdn>...</fqdn></guest_info></vm>`)
|
||||
|
||||
## Photon
|
||||
|
||||
### Node Name
|
||||
|
||||
The Photon cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Photon VM name (or if `overrideIP` is set to true in the `--cloud-config`, the Kubernetes Node name must match the Photon VM IP address).
|
||||
[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
|
||||
|
||||
## vSphere
|
||||
|
||||
@@ -388,46 +360,3 @@ If you are running vSphere < 6.7U3, the in-tree vSphere cloud provider is recomm
|
||||
{{< /tabs >}}
|
||||
|
||||
For in-depth documentation on the vSphere cloud provider, visit the [vSphere cloud provider docs site](https://cloud-provider-vsphere.sigs.k8s.io).
|
||||
|
||||
## IBM Cloud Kubernetes Service
|
||||
|
||||
### Compute nodes
|
||||
By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes).
|
||||
|
||||
The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.
|
||||
|
||||
### Networking
|
||||
The IBM Cloud Kubernetes Service provider provides VLANs for quality network performance and network isolation for nodes. You can set up custom firewalls and Calico network policies to add an extra layer of security for your cluster, or connect your cluster to your on-prem data center via VPN. For more information, see [Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters).
|
||||
|
||||
To expose apps to the public or within the cluster, you can leverage NodePort, LoadBalancer, or Ingress services. You can also customize the Ingress application load balancer with annotations. For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
|
||||
|
||||
### Storage
|
||||
The IBM Cloud Kubernetes Service provider leverages Kubernetes-native persistent volumes to enable users to mount file, block, and cloud object storage to their apps. You can also use database-as-a-service and third-party add-ons for persistent storage of your data. For more information, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).
|
||||
|
||||
## Baidu Cloud Container Engine
|
||||
|
||||
### Node Name
|
||||
|
||||
The Baidu cloud provider uses the private IP address of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Baidu VM private IP.
|
||||
|
||||
## Tencent Kubernetes Engine
|
||||
|
||||
If you wish to use the external cloud provider, its repository is [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager).
|
||||
|
||||
### Node Name
|
||||
|
||||
The Tencent cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object.
|
||||
Note that the Kubernetes Node name must match the Tencent VM private IP.
|
||||
|
||||
## Alibaba Cloud Kubernetes
|
||||
|
||||
If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud).
|
||||
|
||||
### Node Name
|
||||
|
||||
Alibaba Cloud does not require the format of node name, but the kubelet needs to add `--provider-id=${REGION_ID}.${INSTANCE_ID}`. The parameter `${REGION_ID}` represents the region id of the Kubernetes and `${INSTANCE_ID}` denotes the Alibaba ECS (Elastic Compute Service) ID.
|
||||
|
||||
### Load Balancers
|
||||
|
||||
You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) .
|
||||
|
||||
@@ -111,7 +111,7 @@ CPU is always requested as an absolute quantity, never as a relative quantity;
|
||||
### Meaning of memory
|
||||
|
||||
Limits and requests for `memory` are measured in bytes. You can express memory as
|
||||
a plain integer or as a fixed-point integer using one of these suffixes:
|
||||
a plain integer or as a fixed-point number using one of these suffixes:
|
||||
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following represent roughly the same value:
|
||||
|
||||
@@ -311,7 +311,7 @@ You can use _ephemeral-storage_ for managing local ephemeral storage. Each Conta
|
||||
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||
|
||||
Limits and requests for `ephemeral-storage` are measured in bytes. You can express storage as
|
||||
a plain integer or as a fixed-point integer using one of these suffixes:
|
||||
a plain integer or as a fixed-point number using one of these suffixes:
|
||||
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
|
||||
Mi, Ki. For example, the following represent roughly the same value:
|
||||
|
||||
|
||||
@@ -172,7 +172,7 @@ Node Score:
|
||||
|
||||
intel.com/foo = resourceScoringFunction((2+2),8)
|
||||
= (100 - ((8-4)*100/8)
|
||||
= (100 - 25)
|
||||
= (100 - 50)
|
||||
= 50
|
||||
= rawScoringFunction(50)
|
||||
= 5
|
||||
|
||||
@@ -352,6 +352,8 @@ NAME TYPE DATA
|
||||
db-user-pass-96mffmfh4k Opaque 2 51s
|
||||
```
|
||||
|
||||
You can view a description of the secret:
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/db-user-pass-96mffmfh4k
|
||||
```
|
||||
@@ -1002,6 +1004,8 @@ The output is similar to:
|
||||
secret "prod-db-secret" created
|
||||
```
|
||||
|
||||
You can also create a secret for test environment credentials.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
|
||||
```
|
||||
|
||||
@@ -30,7 +30,7 @@ There are two hooks that are exposed to Containers:
|
||||
|
||||
`PostStart`
|
||||
|
||||
This hook executes immediately after a container is created.
|
||||
This hook is executed immediately after a container is created.
|
||||
However, there is no guarantee that the hook will execute before the container ENTRYPOINT.
|
||||
No parameters are passed to the handler.
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ runtime to authenticate to a private container registry.
|
||||
This approach is suitable if you can control node configuration.
|
||||
|
||||
{{< note >}}
|
||||
Kubernetes as only supports the `auths` and `HttpHeaders` section in Docker configuration.
|
||||
Default Kubernetes only supports the `auths` and `HttpHeaders` section in Docker configuration.
|
||||
Docker credential helpers (`credHelpers` or `credsStore`) are not supported.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ weight: 30
|
||||
Operators are software extensions to Kubernetes that make use of
|
||||
[custom resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
to manage applications and their components. Operators follow
|
||||
Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane).
|
||||
Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
@@ -209,11 +209,11 @@ well as lower-trust users.The following listed controls should be enforced/disal
|
||||
<tr>
|
||||
<td>Privilege Escalation</td>
|
||||
<td>
|
||||
Privilege escalation to root should not be allowed.<br>
|
||||
Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.containers[*].securityContext.privileged<br>
|
||||
spec.initContainers[*].securityContext.privileged<br>
|
||||
<br><b>Allowed Values:</b> false, undefined/nil<br>
|
||||
spec.containers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
spec.initContainers[*].securityContext.allowPrivilegeEscalation<br>
|
||||
<br><b>Allowed Values:</b> false<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
||||
@@ -259,7 +259,7 @@ Expanding EBS volumes is a time-consuming operation. Also, there is a per-volume
|
||||
If expanding underlying storage fails, the cluster administrator can manually recover the Persistent Volume Claim (PVC) state and cancel the resize requests. Otherwise, the resize requests are continuously retried by the controller without administrator intervention.
|
||||
|
||||
1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) with `Retain` reclaim policy.
|
||||
2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not loose any data when we recreate the PVC.
|
||||
2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not lose any data when we recreate the PVC.
|
||||
3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. This should make the PV `Available`.
|
||||
4. Re-create the PVC with smaller size than PV and set `volumeName` field of the PVC to the name of the PV. This should bind new PVC to existing PV.
|
||||
5. Don't forget to restore the reclaim policy of the PV.
|
||||
|
||||
@@ -94,14 +94,14 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
|
||||
|
||||
For pre-provisioned snapshots, you need to specify a `volumeSnapshotContentName` as the source for the snapshot as shown in the following example. The `volumeSnapshotContentName` source field is required for pre-provisioned snapshots.
|
||||
|
||||
```
|
||||
```yaml
|
||||
apiVersion: snapshot.storage.k8s.io/v1beta1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: test-snapshot
|
||||
spec:
|
||||
source:
|
||||
volumeSnapshotContentName: test-content
|
||||
volumeSnapshotContentName: test-content
|
||||
```
|
||||
|
||||
## Volume Snapshot Contents
|
||||
|
||||
@@ -7,7 +7,7 @@ reviewers:
|
||||
- kow3ns
|
||||
title: DaemonSet
|
||||
content_type: concept
|
||||
weight: 50
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -8,7 +8,7 @@ feature:
|
||||
Kubernetes progressively rolls out changes to your application or its configuration, while monitoring application health to ensure it doesn't kill all your instances at the same time. If something goes wrong, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.
|
||||
|
||||
content_type: concept
|
||||
weight: 30
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -84,7 +84,7 @@ Follow the steps given below to create the above Deployment:
|
||||
2. Run `kubectl get deployments` to check if the Deployment was created.
|
||||
|
||||
If the Deployment is still being created, the output is similar to the following:
|
||||
```shell
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 0/3 0 0 1s
|
||||
```
|
||||
@@ -100,21 +100,21 @@ Follow the steps given below to create the above Deployment:
|
||||
3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`.
|
||||
|
||||
The output is similar to:
|
||||
```shell
|
||||
```
|
||||
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
|
||||
deployment.apps/nginx-deployment successfully rolled out
|
||||
```
|
||||
|
||||
4. Run the `kubectl get deployments` again a few seconds later.
|
||||
The output is similar to this:
|
||||
```shell
|
||||
```
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
nginx-deployment 3/3 3 3 18s
|
||||
```
|
||||
Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available.
|
||||
|
||||
5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this:
|
||||
```shell
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-75675f5897 3 3 3 18s
|
||||
```
|
||||
@@ -131,7 +131,7 @@ Follow the steps given below to create the above Deployment:
|
||||
|
||||
6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`.
|
||||
The output is similar to:
|
||||
```shell
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE LABELS
|
||||
nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453
|
||||
@@ -1054,7 +1054,7 @@ The `.spec.template` and `.spec.selector` are the only required field of the `.s
|
||||
The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
|
||||
|
||||
In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate
|
||||
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector)).
|
||||
labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector).
|
||||
|
||||
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
|
||||
allowed, which is the default if not specified.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Garbage Collection
|
||||
content_type: concept
|
||||
weight: 70
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -8,7 +8,7 @@ feature:
|
||||
title: Batch execution
|
||||
description: >
|
||||
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
|
||||
weight: 60
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -5,7 +5,7 @@ reviewers:
|
||||
- madhusudancs
|
||||
title: ReplicaSet
|
||||
content_type: concept
|
||||
weight: 10
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
@@ -245,9 +245,10 @@ For the template's [restart policy](/docs/concepts/workloads/Pods/pod-lifecycle/
|
||||
The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/). As discussed
|
||||
[earlier](#how-a-replicaset-works) these are the labels used to identify potential Pods to acquire. In our
|
||||
`frontend.yaml` example, the selector was:
|
||||
```shell
|
||||
|
||||
```yaml
|
||||
matchLabels:
|
||||
tier: frontend
|
||||
tier: frontend
|
||||
```
|
||||
|
||||
In the ReplicaSet, `.spec.template.metadata.labels` must match `spec.selector`, or it will
|
||||
|
||||
@@ -10,7 +10,7 @@ feature:
|
||||
Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve.
|
||||
|
||||
content_type: concept
|
||||
weight: 20
|
||||
weight: 90
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -8,7 +8,7 @@ reviewers:
|
||||
- smarterclayton
|
||||
title: StatefulSets
|
||||
content_type: concept
|
||||
weight: 40
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -124,9 +124,9 @@ about when the container entered the `Running` state.
|
||||
|
||||
### `Terminated` {#container-state-terminated}
|
||||
|
||||
A container in the `Terminated` state has begin execution and has then either run to
|
||||
completion or has failed for some reason. When you use `kubectl` to query a Pod with
|
||||
a container that is `Terminated`, you see a reason, and exit code, and the start and
|
||||
A container in the `Terminated` state began execution and then either ran to
|
||||
completion or failed for some reason. When you use `kubectl` to query a Pod with
|
||||
a container that is `Terminated`, you see a reason, an exit code, and the start and
|
||||
finish time for that container's period of execution.
|
||||
|
||||
If a container has a `preStop` hook configured, that runs before the container enters
|
||||
@@ -341,8 +341,8 @@ before the Pod is allowed to be forcefully killed. With that forceful shutdown t
|
||||
place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
|
||||
shutdown.
|
||||
|
||||
Typically, the container runtime sends a a TERM signal is sent to the main process in each
|
||||
container. Once the grace period has expired, the KILL signal is sent to any remainig
|
||||
Typically, the container runtime sends a TERM signal to the main process in each
|
||||
container. Once the grace period has expired, the KILL signal is sent to any remaining
|
||||
processes, and the Pod is then deleted from the
|
||||
{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
|
||||
container runtime's management service is restarted while waiting for processes to terminate, the
|
||||
@@ -442,4 +442,3 @@ This avoids a resource leak as Pods are created and terminated over time.
|
||||
* For detailed information about Pod / Container status in the API, see [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core)
|
||||
and
|
||||
[ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core).
|
||||
|
||||
|
||||
@@ -669,7 +669,7 @@ rules:
|
||||
```
|
||||
|
||||
Extra fields are evaluated as sub-resources of the resource "userextras". To
|
||||
allow a user to use impersonation headers for the extra field "scopes," a user
|
||||
allow a user to use impersonation headers for the extra field "scopes", a user
|
||||
should be granted the following role:
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: API server
|
||||
id: kube-apiserver
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-apiserver/
|
||||
full_link: /docs/concepts/overview/components/#kube-apiserver
|
||||
short_description: >
|
||||
Control plane component that serves the Kubernetes API.
|
||||
|
||||
|
||||
@@ -12,17 +12,11 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
|
||||
|
||||
This page is an overview of the `kubectl` command.
|
||||
|
||||
|
||||
This page contains a list of commonly used `kubectl` commands and flags.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
# kubectl - Cheat Sheet
|
||||
|
||||
## Kubectl Autocomplete
|
||||
## Kubectl autocomplete
|
||||
|
||||
### BASH
|
||||
|
||||
@@ -31,7 +25,7 @@ source <(kubectl completion bash) # setup autocomplete in bash into the current
|
||||
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
|
||||
```
|
||||
|
||||
You can also use a shorthand alias for `kubectl` that also works with completion:
|
||||
You can also use a shorthand alias for `kubectl` that also works with completion:
|
||||
|
||||
```bash
|
||||
alias k=kubectl
|
||||
@@ -45,7 +39,7 @@ source <(kubectl completion zsh) # setup autocomplete in zsh into the current s
|
||||
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # add autocomplete permanently to your zsh shell
|
||||
```
|
||||
|
||||
## Kubectl Context and Configuration
|
||||
## Kubectl context and configuration
|
||||
|
||||
Set which Kubernetes cluster `kubectl` communicates with and modifies configuration
|
||||
information. See [Authenticating Across Clusters with kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation for
|
||||
@@ -77,14 +71,15 @@ kubectl config set-context --current --namespace=ggckad-s2
|
||||
# set a context utilizing a specific username and namespace.
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
|
||||
kubectl config unset users.foo # delete user foo
|
||||
```
|
||||
|
||||
## Apply
|
||||
## Kubectl apply
|
||||
|
||||
`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io).
|
||||
|
||||
## Creating Objects
|
||||
## Creating objects
|
||||
|
||||
Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`,
|
||||
`.yml`, and `.json` can be used.
|
||||
@@ -138,7 +133,7 @@ EOF
|
||||
|
||||
```
|
||||
|
||||
## Viewing, Finding Resources
|
||||
## Viewing, finding resources
|
||||
|
||||
```bash
|
||||
# Get commands with basic output
|
||||
@@ -213,8 +208,7 @@ kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
|
||||
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
|
||||
```
|
||||
|
||||
## Updating Resources
|
||||
|
||||
## Updating resources
|
||||
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
|
||||
@@ -241,7 +235,7 @@ kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annota
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo"
|
||||
```
|
||||
|
||||
## Patching Resources
|
||||
## Patching resources
|
||||
|
||||
```bash
|
||||
# Partially update a node
|
||||
@@ -260,7 +254,8 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
```
|
||||
|
||||
## Editing Resources
|
||||
## Editing resources
|
||||
|
||||
Edit any API resource in your preferred editor.
|
||||
|
||||
```bash
|
||||
@@ -268,7 +263,7 @@ kubectl edit svc/docker-registry # Edit the service named d
|
||||
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor
|
||||
```
|
||||
|
||||
## Scaling Resources
|
||||
## Scaling resources
|
||||
|
||||
```bash
|
||||
kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3
|
||||
@@ -277,7 +272,7 @@ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deplo
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
|
||||
```
|
||||
|
||||
## Deleting Resources
|
||||
## Deleting resources
|
||||
|
||||
```bash
|
||||
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
|
||||
@@ -313,7 +308,7 @@ kubectl exec my-pod -c my-container -- ls / # Run command in existing po
|
||||
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
|
||||
```
|
||||
|
||||
## Interacting with Nodes and Cluster
|
||||
## Interacting with Nodes and cluster
|
||||
|
||||
```bash
|
||||
kubectl cordon my-node # Mark my-node as unschedulable
|
||||
@@ -393,17 +388,12 @@ Verbosity | Description
|
||||
`--v=8` | Display HTTP request contents.
|
||||
`--v=9` | Display HTTP request contents without truncation of contents.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
* Read the [kubectl overview](/docs/reference/kubectl/overview/) and learn about [JsonPath](/docs/reference/kubectl/jsonpath).
|
||||
|
||||
* See [kubectl](/docs/reference/kubectl/kubectl/) options.
|
||||
|
||||
* Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
|
||||
* Also read [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use kubectl in reusable scripts.
|
||||
|
||||
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
|
||||
|
||||
|
||||
|
||||
@@ -13,7 +13,17 @@ file and passing its path as a command line argument.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Minimal Configuration
|
||||
A scheduling Profile allows you to configure the different stages of scheduling
|
||||
in the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}.
|
||||
Each stage is exposed in a extension point. Plugins provide scheduling behaviors
|
||||
by implementing one or more of these extension points.
|
||||
|
||||
You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
|
||||
using the component config APIs
|
||||
([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration)
|
||||
or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)).
|
||||
The `v1alpha2` API allows you to configure kube-scheduler to run
|
||||
[multiple profiles](#multiple-profiles).
|
||||
|
||||
A minimal configuration looks as follows:
|
||||
|
||||
@@ -90,6 +100,10 @@ for that extension point. This can also be used to rearrange plugins order, if
|
||||
desired.
|
||||
|
||||
### Scheduling plugins
|
||||
1. `UnReserve`: This is an informational extension point that is called if
|
||||
a Pod is rejected after being reserved and put on hold by a `Permit` plugin.
|
||||
|
||||
## Scheduling plugins
|
||||
|
||||
The following plugins, enabled by default, implement one or more of these
|
||||
extension points:
|
||||
@@ -236,4 +250,3 @@ only has one pending pods queue.
|
||||
|
||||
* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
|
||||
|
||||
@@ -221,64 +221,89 @@ sysctl --system
|
||||
{{< tabs name="tab-cri-cri-o-installation" >}}
|
||||
{{% tab name="Debian" %}}
|
||||
|
||||
To install CRI-O on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
|
||||
|
||||
| Operating system | $OS |
|
||||
| ---------------- | ----------------- |
|
||||
| Debian Unstable | `Debian_Unstable` |
|
||||
| Debian Testing | `Debian_Testing` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
# Debian Unstable/Sid
|
||||
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add -
|
||||
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
|
||||
|
||||
apt-get update
|
||||
apt-get install cri-o cri-o-runc
|
||||
```
|
||||
|
||||
```shell
|
||||
# Debian Testing
|
||||
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add -
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
```shell
|
||||
# Debian 10
|
||||
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add -
|
||||
```
|
||||
{{% tab name="Ubuntu" %}}
|
||||
|
||||
```shell
|
||||
# Raspbian 10
|
||||
echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add -
|
||||
```
|
||||
To install on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
|
||||
|
||||
and then install CRI-O:
|
||||
| Operating system | $OS |
|
||||
| ---------------- | ----------------- |
|
||||
| Ubuntu 20.04 | `xUbuntu_20.04` |
|
||||
| Ubuntu 19.10 | `xUbuntu_19.10` |
|
||||
| Ubuntu 19.04 | `xUbuntu_19.04` |
|
||||
| Ubuntu 18.04 | `xUbuntu_18.04` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
sudo apt-get install cri-o-1.17
|
||||
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list
|
||||
echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list
|
||||
|
||||
curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | apt-key add -
|
||||
curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | apt-key add -
|
||||
|
||||
apt-get update
|
||||
apt-get install cri-o cri-o-runc
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Ubuntu 18.04, 19.04 and 19.10" %}}
|
||||
{{% tab name="CentOS" %}}
|
||||
|
||||
To install on the following operating systems, set the environment variable $OS to the appropriate field in the following table:
|
||||
|
||||
| Operating system | $OS |
|
||||
| ---------------- | ----------------- |
|
||||
| Centos 8 | `CentOS_8` |
|
||||
| Centos 8 Stream | `CentOS_8_Stream` |
|
||||
| Centos 7 | `CentOS_7` |
|
||||
|
||||
<br />
|
||||
Then, set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.18, set `VERSION=1.18`.
|
||||
You can pin your installation to a specific release.
|
||||
To install version 1.18.3, set `VERSION=1.18:1.18.3`.
|
||||
<br />
|
||||
|
||||
Then run
|
||||
```shell
|
||||
# Configure package repository
|
||||
. /etc/os-release
|
||||
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"
|
||||
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add -
|
||||
sudo apt-get update
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/devel:kubic:libcontainers:stable.repo
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/devel:kubic:libcontainers:stable:cri-o:$VERSION.repo
|
||||
yum install cri-o
|
||||
```
|
||||
|
||||
```shell
|
||||
# Install CRI-O
|
||||
sudo apt-get install cri-o-1.17
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="CentOS/RHEL 7.4+" %}}
|
||||
|
||||
```shell
|
||||
# Install prerequisites
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo
|
||||
curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo
|
||||
```
|
||||
|
||||
```shell
|
||||
# Install CRI-O
|
||||
yum install -y cri-o
|
||||
```
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="openSUSE Tumbleweed" %}}
|
||||
@@ -286,6 +311,23 @@ yum install -y cri-o
|
||||
```shell
|
||||
sudo zypper install cri-o
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Fedora" %}}
|
||||
|
||||
Set `$VERSION` to the CRI-O version that matches your Kubernetes version.
|
||||
For instance, if you want to install CRI-O 1.18, `VERSION=1.18`
|
||||
You can find available versions with:
|
||||
```shell
|
||||
dnf module list cri-o
|
||||
```
|
||||
CRI-O does not support pinning to specific releases on Fedora.
|
||||
|
||||
Then run
|
||||
```shell
|
||||
dnf module enable cri-o:$VERSION
|
||||
dnf install cri-o
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
+4
-4
@@ -1,14 +1,14 @@
|
||||
---
|
||||
reviewers:
|
||||
- sig-cluster-lifecycle
|
||||
title: Creating a single control-plane cluster with kubeadm
|
||||
title: Creating a cluster with kubeadm
|
||||
content_type: task
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">The `kubeadm` tool helps you bootstrap a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">Creating a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification).
|
||||
`kubeadm` also supports other cluster
|
||||
lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades.
|
||||
|
||||
@@ -60,7 +60,7 @@ Any commands under `kubeadm alpha` are, by definition, supported on an alpha lev
|
||||
|
||||
## Objectives
|
||||
|
||||
* Install a single control-plane Kubernetes cluster or [high-availability cluster](/docs/setup/production-environment/tools/kubeadm/high-availability/)
|
||||
* Install a single control-plane Kubernetes cluster
|
||||
* Install a Pod network on the cluster so that your Pods can
|
||||
talk to each other
|
||||
|
||||
@@ -554,7 +554,7 @@ Workarounds:
|
||||
|
||||
* Use multiple control-plane nodes. You can read
|
||||
[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/) to pick a cluster
|
||||
topology that provides higher availabilty.
|
||||
topology that provides [high-availability](/docs/setup/production-environment/tools/kubeadm/high-availability/).
|
||||
|
||||
### Platform compatibility {#multi-platform}
|
||||
|
||||
|
||||
@@ -155,7 +155,7 @@ Running a cluster with `kubelet` instances that are persistently two minor versi
|
||||
|
||||
Example:
|
||||
|
||||
If `kube-proxy` version is **{{< skew latestVersion >}}**:
|
||||
If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
|
||||
|
||||
* `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**.
|
||||
* `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**.
|
||||
* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
|
||||
|
||||
@@ -12,4 +12,4 @@ show how to do individual tasks. A task page shows how to do a
|
||||
single thing, typically by giving a short sequence of steps.
|
||||
|
||||
If you would like to write a task page, see
|
||||
[Creating a Documentation Pull Request](/docs/home/contribute/create-pull-request/).
|
||||
[Creating a Documentation Pull Request](/docs/contribute/new-content/open-a-pr/).
|
||||
|
||||
@@ -80,7 +80,8 @@ spec:
|
||||
requests:
|
||||
cpu: 700m
|
||||
memory: 200Mi
|
||||
...
|
||||
...
|
||||
status:
|
||||
qosClass: Guaranteed
|
||||
```
|
||||
|
||||
@@ -134,7 +135,8 @@ spec:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
...
|
||||
...
|
||||
status:
|
||||
qosClass: Burstable
|
||||
```
|
||||
|
||||
@@ -174,6 +176,7 @@ spec:
|
||||
...
|
||||
resources: {}
|
||||
...
|
||||
status:
|
||||
qosClass: BestEffort
|
||||
```
|
||||
|
||||
@@ -219,6 +222,7 @@ spec:
|
||||
name: qos-demo-4-ctr-2
|
||||
resources: {}
|
||||
...
|
||||
status:
|
||||
qosClass: Burstable
|
||||
```
|
||||
|
||||
|
||||
@@ -251,7 +251,7 @@ different audit policies.
|
||||
|
||||
### Use fluentd to collect and distribute audit events from log file
|
||||
|
||||
[Fluentd](http://www.fluentd.org/) is an open source data collector for unified logging layer.
|
||||
[Fluentd](https://www.fluentd.org/) is an open source data collector for unified logging layer.
|
||||
In this example, we will use fluentd to split audit events by different namespaces.
|
||||
|
||||
{{< note >}}
|
||||
@@ -379,7 +379,7 @@ different users into different files.
|
||||
bin/logstash -f /etc/logstash/config --path.settings /etc/logstash/
|
||||
```
|
||||
|
||||
1. create a [kubeconfig file](/docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/) for kube-apiserver webhook audit backend
|
||||
1. create a [kubeconfig file](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) for kube-apiserver webhook audit backend
|
||||
|
||||
cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
|
||||
apiVersion: v1
|
||||
@@ -413,9 +413,5 @@ plugin which supports full-text search and analytics.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco).
|
||||
|
||||
Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
|
||||
|
||||
|
||||
|
||||
@@ -10,10 +10,7 @@ content_type: concept
|
||||
|
||||
This guide is to help users debug applications that are deployed into Kubernetes and not behaving correctly.
|
||||
This is *not* a guide for people who want to debug their cluster. For that you should check out
|
||||
[this guide](/docs/admin/cluster-troubleshooting).
|
||||
|
||||
|
||||
|
||||
[this guide](/docs/tasks/debug-application-cluster/debug-cluster).
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -46,7 +43,8 @@ there are insufficient resources of one type or another that prevent scheduling.
|
||||
your pod. Reasons include:
|
||||
|
||||
* **You don't have enough resources**: You may have exhausted the supply of CPU or Memory in your cluster, in this case
|
||||
you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See [Compute Resources document](/docs/user-guide/compute-resources/#my-pods-are-pending-with-event-message-failedscheduling) for more information.
|
||||
you need to delete Pods, adjust resource requests, or add new nodes to your cluster. See
|
||||
[Compute Resources document](/docs/concepts/configuration/manage-resources-containers/) for more information.
|
||||
|
||||
* **You are using `hostPort`**: When you bind a Pod to a `hostPort` there are a limited number of places that pod can be
|
||||
scheduled. In most cases, `hostPort` is unnecessary, try using a Service object to expose your Pod. If you do require
|
||||
@@ -161,13 +159,13 @@ check:
|
||||
* Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP.
|
||||
* Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
If none of the above solves your problem, follow the instructions in
|
||||
[Debugging Service document](/docs/tasks/debug-application-cluster/debug-service/)
|
||||
to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are
|
||||
actually serving; you have DNS working, iptables rules installed, and kube-proxy
|
||||
does not seem to be misbehaving.
|
||||
|
||||
If none of the above solves your problem, follow the instructions in [Debugging Service document](/docs/user-guide/debugging-services) to make sure that your `Service` is running, has `Endpoints`, and your `Pods` are actually serving; you have DNS working, iptables rules installed, and kube-proxy does not seem to be misbehaving.
|
||||
|
||||
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
|
||||
You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
|
||||
|
||||
|
||||
@@ -10,10 +10,7 @@ content_type: concept
|
||||
This doc is about cluster troubleshooting; we assume you have already ruled out your application as the root cause of the
|
||||
problem you are experiencing. See
|
||||
the [application troubleshooting guide](/docs/tasks/debug-application-cluster/debug-application) for tips on application debugging.
|
||||
You may also visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
|
||||
|
||||
|
||||
You may also visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/) for more information.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
|
||||
@@ -15,10 +15,8 @@ content_type: task
|
||||
|
||||
This page shows how to investigate problems related to the execution of
|
||||
Init Containers. The example command lines below refer to the Pod as
|
||||
`<pod-name>` and the Init Containers as `<init-container-1>` and
|
||||
`<init-container-2>`.
|
||||
|
||||
|
||||
`<pod-name>` and the Init Containers as `<init-container-1>` and
|
||||
`<init-container-2>`.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
@@ -26,11 +24,9 @@ Init Containers. The example command lines below refer to the Pod as
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
* You should be familiar with the basics of
|
||||
[Init Containers](/docs/concepts/abstractions/init-containers/).
|
||||
[Init Containers](/docs/concepts/workloads/pods/init-containers/).
|
||||
* You should have [Configured an Init Container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container/).
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Checking the status of Init Containers
|
||||
|
||||
@@ -9,8 +9,6 @@ content_type: task
|
||||
|
||||
This page shows how to debug Pods and ReplicationControllers.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
@@ -20,8 +18,6 @@ This page shows how to debug Pods and ReplicationControllers.
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} and with
|
||||
Pods' [lifecycles](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Debugging Pods
|
||||
@@ -51,9 +47,9 @@ can not schedule your pod. Reasons include:
|
||||
You may have exhausted the supply of CPU or Memory in your cluster. In this
|
||||
case you can try several things:
|
||||
|
||||
* [Add more nodes](/docs/admin/cluster-management/#resizing-a-cluster) to the cluster.
|
||||
* [Add more nodes](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster) to the cluster.
|
||||
|
||||
* [Terminate unneeded pods](/docs/user-guide/pods/single-container/#deleting_a_pod)
|
||||
* [Terminate unneeded pods](/docs/concepts/workloads/pods/#pod-termination)
|
||||
to make room for pending pods.
|
||||
|
||||
* Check that the pod is not larger than your nodes. For example, if all
|
||||
|
||||
@@ -13,9 +13,6 @@ Deployment (or other workload controller) and created a Service, but you
|
||||
get no response when you try to access it. This document will hopefully help
|
||||
you to figure out what's going wrong.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Running commands in a Pod
|
||||
@@ -658,7 +655,7 @@ This might sound unlikely, but it does happen and it is supposed to work.
|
||||
This can happen when the network is not properly configured for "hairpin"
|
||||
traffic, usually when `kube-proxy` is running in `iptables` mode and Pods
|
||||
are connected with bridge network. The `Kubelet` exposes a `hairpin-mode`
|
||||
[flag](/docs/admin/kubelet/) that allows endpoints of a Service to loadbalance
|
||||
[flag](/docs/reference/command-line-tools-reference/kubelet/) that allows endpoints of a Service to loadbalance
|
||||
back to themselves if they try to access their own Service VIP. The
|
||||
`hairpin-mode` flag must either be set to `hairpin-veth` or
|
||||
`promiscuous-bridge`.
|
||||
@@ -724,15 +721,13 @@ Service is not working. Please let us know what is going on, so we can help
|
||||
investigate!
|
||||
|
||||
Contact us on
|
||||
[Slack](/docs/troubleshooting/#slack) or
|
||||
[Slack](/docs/tasks/debug-application-cluster/troubleshooting/#slack) or
|
||||
[Forum](https://discuss.kubernetes.io) or
|
||||
[GitHub](https://github.com/kubernetes/kubernetes).
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Visit [troubleshooting document](/docs/troubleshooting/) for more information.
|
||||
Visit [troubleshooting document](/docs/tasks/debug-application-cluster/troubleshooting/)
|
||||
for more information.
|
||||
|
||||
|
||||
|
||||
@@ -12,19 +12,13 @@ content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This task shows you how to debug a StatefulSet.
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.
|
||||
* You should have a StatefulSet running that you want to investigate.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Debugging a StatefulSet
|
||||
@@ -37,18 +31,12 @@ kubectl get pods -l app=myapp
|
||||
```
|
||||
|
||||
If you find that any Pods listed are in `Unknown` or `Terminating` state for an extended period of time,
|
||||
refer to the [Deleting StatefulSet Pods](/docs/tasks/manage-stateful-set/delete-pods/) task for
|
||||
refer to the [Deleting StatefulSet Pods](/docs/tasks/run-application/delete-stateful-set/) task for
|
||||
instructions on how to deal with them.
|
||||
You can debug individual Pods in a StatefulSet using the
|
||||
[Debugging Pods](/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) guide.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Learn more about [debugging an init-container](/docs/tasks/debug-application-cluster/debug-init-containers/).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ title: Logging Using Elasticsearch and Kibana
|
||||
|
||||
On the Google Compute Engine (GCE) platform, the default logging support targets
|
||||
[Stackdriver Logging](https://cloud.google.com/logging/), which is described in detail
|
||||
in the [Logging With Stackdriver Logging](/docs/user-guide/logging/stackdriver).
|
||||
in the [Logging With Stackdriver Logging](/docs/tasks/debug-application-cluster/logging-stackdriver).
|
||||
|
||||
This article describes how to set up a cluster to ingest logs into
|
||||
[Elasticsearch](https://www.elastic.co/products/elasticsearch) and view
|
||||
@@ -90,7 +90,8 @@ Elasticsearch, and is part of a service named `kibana-logging`.
|
||||
|
||||
The Elasticsearch and Kibana services are both in the `kube-system` namespace
|
||||
and are not directly exposed via a publicly reachable IP address. To reach them,
|
||||
follow the instructions for [Accessing services running in a cluster](/docs/concepts/cluster-administration/access-cluster/#accessing-services-running-on-the-cluster).
|
||||
follow the instructions for
|
||||
[Accessing services running in a cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster).
|
||||
|
||||
If you try accessing the `elasticsearch-logging` service in your browser, you'll
|
||||
see a status page that looks something like this:
|
||||
@@ -102,7 +103,7 @@ like. See [Elasticsearch's documentation](https://www.elastic.co/guide/en/elasti
|
||||
for more details on how to do so.
|
||||
|
||||
Alternatively, you can view your cluster's logs using Kibana (again using the
|
||||
[instructions for accessing a service running in the cluster](/docs/user-guide/accessing-the-cluster/#accessing-services-running-on-the-cluster)).
|
||||
[instructions for accessing a service running in the cluster](/docs/tasks/access-application-cluster/access-cluster/#accessing-services-running-on-the-cluster)).
|
||||
The first time you visit the Kibana URL you will be presented with a page that
|
||||
asks you to configure your view of the ingested logs. Select the option for
|
||||
timeseries values and select `@timestamp`. On the following page select the
|
||||
|
||||
@@ -317,8 +317,8 @@ After some time, Stackdriver Logging agent pods will be restarted with the new c
|
||||
### Changing fluentd parameters
|
||||
|
||||
Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration
|
||||
files that are merged together. You can learn about fluentd configuration on the [official
|
||||
site](http://docs.fluentd.org).
|
||||
files that are merged together. You can learn about fluentd configuration on the
|
||||
[official site](https://docs.fluentd.org).
|
||||
|
||||
Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand
|
||||
default Python logging format. An appropriate fluentd filter looks similar to this:
|
||||
@@ -356,7 +356,7 @@ using [guide above](#changing-daemonset-parameters).
|
||||
### Adding fluentd plugins
|
||||
|
||||
Fluentd is written in Ruby and allows to extend its capabilities using
|
||||
[plugins](http://www.fluentd.org/plugins). If you want to use a plugin, which is not included
|
||||
[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included
|
||||
in the default Stackdriver Logging container image, you have to build a custom image. Imagine
|
||||
you want to add Kafka sink for messages from a particular container for additional processing.
|
||||
You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image)
|
||||
|
||||
@@ -13,9 +13,6 @@ are available in Kubernetes through the Metrics API. These metrics can be either
|
||||
by user, for example by using `kubectl top` command, or used by a controller in the cluster, e.g.
|
||||
Horizontal Pod Autoscaler, to make decisions.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## The Metrics API
|
||||
@@ -41,11 +38,19 @@ The API requires metrics server to be deployed in the cluster. Otherwise it will
|
||||
|
||||
### CPU
|
||||
|
||||
CPU is reported as the average usage, in [CPU cores](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu), over a period of time. This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The kubelet chooses the window for the rate calculation.
|
||||
CPU is reported as the average usage, in
|
||||
[CPU cores](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu),
|
||||
over a period of time. This value is derived by taking a rate over a cumulative CPU counter
|
||||
provided by the kernel (in both Linux and Windows kernels).
|
||||
The kubelet chooses the window for the rate calculation.
|
||||
|
||||
### Memory
|
||||
|
||||
Memory is reported as the working set, in bytes, at the instant the metric was collected. In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure. However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate. It includes all anonymous (non-file-backed) memory since kubernetes does not support swap. The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
|
||||
Memory is reported as the working set, in bytes, at the instant the metric was collected.
|
||||
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure.
|
||||
However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
|
||||
It includes all anonymous (non-file-backed) memory since kubernetes does not support swap.
|
||||
The metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim such pages.
|
||||
|
||||
## Metrics Server
|
||||
|
||||
@@ -54,9 +59,12 @@ It is deployed by default in clusters created by `kube-up.sh` script
|
||||
as a Deployment object. If you use a different Kubernetes setup mechanism you can deploy it using the provided
|
||||
[deployment components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) file.
|
||||
|
||||
Metric server collects metrics from the Summary API, exposed by [Kubelet](/docs/admin/kubelet/) on each node.
|
||||
Metric server collects metrics from the Summary API, exposed by
|
||||
[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) on each node.
|
||||
|
||||
Metrics Server is registered with the main API server through
|
||||
[Kubernetes aggregator](/docs/concepts/api-extension/apiserver-aggregation/).
|
||||
[Kubernetes aggregator](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
|
||||
|
||||
Learn more about the metrics server in
|
||||
[the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
|
||||
|
||||
Learn more about the metrics server in [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md).
|
||||
|
||||
@@ -10,29 +10,32 @@ title: Tools for Monitoring Resources
|
||||
To scale an application and provide a reliable service, you need to
|
||||
understand how the application behaves when it is deployed. You can examine
|
||||
application performance in a Kubernetes cluster by examining the containers,
|
||||
[pods](/docs/user-guide/pods), [services](/docs/user-guide/services), and
|
||||
[pods](/docs/concepts/workloads/pods/),
|
||||
[services](/docs/concepts/services-networking/service/), and
|
||||
the characteristics of the overall cluster. Kubernetes provides detailed
|
||||
information about an application's resource usage at each of these levels.
|
||||
This information allows you to evaluate your application's performance and
|
||||
where bottlenecks can be removed to improve overall performance.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
|
||||
In Kubernetes, application monitoring does not depend on a single monitoring solution.
|
||||
On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or
|
||||
[full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
|
||||
|
||||
## Resource metrics pipeline
|
||||
|
||||
The resource metrics pipeline provides a limited set of metrics related to
|
||||
cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility.
|
||||
cluster components such as the
|
||||
[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)
|
||||
controller, as well as the `kubectl top` utility.
|
||||
These metrics are collected by the lightweight, short-term, in-memory
|
||||
[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and
|
||||
are exposed via the `metrics.k8s.io` API.
|
||||
|
||||
metrics-server discovers all nodes on the cluster and
|
||||
queries each node's
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and
|
||||
[kubelet](/docs/reference/command-line-tools-reference/kubelet/) for CPU and
|
||||
memory usage. The kubelet acts as a bridge between the Kubernetes master and
|
||||
the nodes, managing the pods and containers running on a machine. The kubelet
|
||||
translates each pod into its constituent containers and fetches individual
|
||||
|
||||
@@ -11,15 +11,14 @@ title: Troubleshooting
|
||||
Sometimes things go wrong. This guide is aimed at making them right. It has
|
||||
two sections:
|
||||
|
||||
* [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful for users who are deploying code into Kubernetes and wondering why it is not working.
|
||||
* [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful for cluster administrators and people whose Kubernetes cluster is unhappy.
|
||||
* [Troubleshooting your application](/docs/tasks/debug-application-cluster/debug-application/) - Useful
|
||||
for users who are deploying code into Kubernetes and wondering why it is not working.
|
||||
* [Troubleshooting your cluster](/docs/tasks/debug-application-cluster/debug-cluster/) - Useful
|
||||
for cluster administrators and people whose Kubernetes cluster is unhappy.
|
||||
|
||||
You should also check the known issues for the [release](https://github.com/kubernetes/kubernetes/releases)
|
||||
you're using.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Getting help
|
||||
@@ -37,12 +36,12 @@ accomplish commonly used tasks, and [Tutorials](/docs/tutorials/) are more
|
||||
comprehensive walkthroughs of real-world, industry-specific, or end-to-end
|
||||
development scenarios. The [Reference](/docs/reference/) section provides
|
||||
detailed documentation on the [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
and command-line interfaces (CLIs), such as [`kubectl`](/docs/user-guide/kubectl-overview/).
|
||||
and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/overview/).
|
||||
|
||||
You may also find the Stack Overflow topics relevant:
|
||||
|
||||
* [Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes)
|
||||
* [Google Kubernetes Engine](http://stackoverflow.com/questions/tagged/google-container-engine)
|
||||
* [Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes)
|
||||
* [Google Kubernetes Engine](https://stackoverflow.com/questions/tagged/google-container-engine)
|
||||
|
||||
## Help! My question isn't covered! I need help now!
|
||||
|
||||
@@ -50,15 +49,16 @@ You may also find the Stack Overflow topics relevant:
|
||||
|
||||
Someone else from the community may have already asked a similar question or may
|
||||
be able to help with your problem. The Kubernetes team will also monitor
|
||||
[posts tagged Kubernetes](http://stackoverflow.com/questions/tagged/kubernetes).
|
||||
If there aren't any existing questions that help, please [ask a new one](http://stackoverflow.com/questions/ask?tags=kubernetes)!
|
||||
[posts tagged Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes).
|
||||
If there aren't any existing questions that help, please
|
||||
[ask a new one](https://stackoverflow.com/questions/ask?tags=kubernetes)!
|
||||
|
||||
### Slack
|
||||
|
||||
The Kubernetes team hangs out on Slack in the `#kubernetes-users` channel. You
|
||||
can participate in discussion with the Kubernetes team [here](https://kubernetes.slack.com).
|
||||
Slack requires registration, but the Kubernetes team is open invitation to
|
||||
anyone to register [here](http://slack.kubernetes.io). Feel free to come and ask
|
||||
anyone to register [here](https://slack.kubernetes.io). Feel free to come and ask
|
||||
any and all questions.
|
||||
|
||||
Once registered, browse the growing list of channels for various subjects of
|
||||
|
||||
+4
@@ -673,6 +673,8 @@ spec:
|
||||
cronSpec:
|
||||
type: string
|
||||
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
|
||||
image:
|
||||
type: string
|
||||
replicas:
|
||||
type: integer
|
||||
minimum: 1
|
||||
@@ -720,6 +722,8 @@ spec:
|
||||
cronSpec:
|
||||
type: string
|
||||
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
|
||||
image:
|
||||
type: string
|
||||
replicas:
|
||||
type: integer
|
||||
minimum: 1
|
||||
|
||||
@@ -1005,7 +1005,7 @@ template:
|
||||
|
||||
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
@@ -167,7 +167,7 @@ kubectl create --edit -f /tmp/srv.yaml
|
||||
|
||||
* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
|
||||
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
@@ -150,7 +150,7 @@ template:
|
||||
|
||||
* [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
|
||||
* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
@@ -832,7 +832,7 @@ deployment.apps "dev-my-nginx" deleted
|
||||
|
||||
* [Kustomize](https://github.com/kubernetes-sigs/kustomize)
|
||||
* [Kubectl Book](https://kubectl.docs.kubernetes.io)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
|
||||
* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
@@ -229,7 +229,7 @@ The `kubectl patch` command has a `type` parameter that you can set to one of th
|
||||
</table>
|
||||
|
||||
For a comparison of JSON patch and JSON merge patch, see
|
||||
[JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/).
|
||||
[JSON Patch and JSON Merge Patch](https://erosb.github.io/post/json-patch-vs-merge-patch/).
|
||||
|
||||
The default value for the `type` parameter is `strategic`. So in the preceding exercise, you
|
||||
did a strategic merge patch.
|
||||
|
||||
@@ -37,13 +37,23 @@ You can perform a graceful pod deletion with the following command:
|
||||
kubectl delete pods <pod>
|
||||
```
|
||||
|
||||
For the above to lead to graceful termination, the Pod **must not** specify a `pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a `pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod [shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) before the kubelet deletes the name from the apiserver.
|
||||
For the above to lead to graceful termination, the Pod **must not** specify a
|
||||
`pod.Spec.TerminationGracePeriodSeconds` of 0. The practice of setting a
|
||||
`pod.Spec.TerminationGracePeriodSeconds` of 0 seconds is unsafe and strongly discouraged
|
||||
for StatefulSet Pods. Graceful deletion is safe and will ensure that the Pod
|
||||
[shuts down gracefully](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
|
||||
before the kubelet deletes the name from the apiserver.
|
||||
|
||||
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable. The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a [timeout](/docs/admin/node/#node-condition). Pods may also enter these states when the user attempts graceful deletion of a Pod on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
|
||||
Kubernetes (versions 1.5 or newer) will not delete Pods just because a Node is unreachable.
|
||||
The Pods running on an unreachable Node enter the 'Terminating' or 'Unknown' state after a
|
||||
[timeout](/docs/concepts/architecture/nodes/#node-condition).
|
||||
Pods may also enter these states when the user attempts graceful deletion of a Pod
|
||||
on an unreachable Node.
|
||||
The only ways in which a Pod in such a state can be removed from the apiserver are as follows:
|
||||
|
||||
* The Node object is deleted (either by you, or by the [Node Controller](/docs/admin/node)).<br/>
|
||||
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.<br/>
|
||||
* Force deletion of the Pod by the user.
|
||||
* The Node object is deleted (either by you, or by the [Node Controller](/docs/concepts/architecture/nodes/)).
|
||||
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.
|
||||
* Force deletion of the Pod by the user.
|
||||
|
||||
The recommended best practice is to use the first or second approach. If a Node is confirmed to be dead (e.g. permanently disconnected from the network, powered down, etc), then delete the Node object. If the Node is suffering from a network partition, then try to resolve this or wait for it to resolve. When the partition heals, the kubelet will complete the deletion of the Pod and free up its name in the apiserver.
|
||||
|
||||
|
||||
@@ -15,11 +15,9 @@ Horizontal Pod Autoscaler automatically scales the number of pods
|
||||
in a replication controller, deployment, replica set or stateful set based on observed CPU utilization
|
||||
(or, with beta support, on some other, application-provided metrics).
|
||||
|
||||
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server. For more information on how Horizontal Pod Autoscaler behaves, see the [Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
|
||||
|
||||
|
||||
|
||||
This document walks you through an example of enabling Horizontal Pod Autoscaler for the php-apache server.
|
||||
For more information on how Horizontal Pod Autoscaler behaves, see the
|
||||
[Horizontal Pod Autoscaler user guide](/docs/tasks/run-application/horizontal-pod-autoscale/).
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
@@ -459,12 +457,12 @@ HorizontalPodAutoscaler.
|
||||
## Appendix: Quantities
|
||||
|
||||
All metrics in the HorizontalPodAutoscaler and metrics APIs are specified using
|
||||
a special whole-number notation known in Kubernetes as a *quantity*. For example,
|
||||
a special whole-number notation known in Kubernetes as a
|
||||
{{< glossary_tooltip term_id="quantity" text="quantity">}}. For example,
|
||||
the quantity `10500m` would be written as `10.5` in decimal notation. The metrics APIs
|
||||
will return whole numbers without a suffix when possible, and will generally return
|
||||
quantities in milli-units otherwise. This means you might see your metric value fluctuate
|
||||
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation. See the
|
||||
[glossary entry on quantities](/docs/reference/glossary?core-object=true#term-quantity) for more information.
|
||||
between `1` and `1500m`, or `1` and `1.5` when written in decimal notation.
|
||||
|
||||
## Appendix: Other possible scenarios
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ on general patterns for running stateful applications in Kubernetes.
|
||||
* This tutorial assumes you are familiar with
|
||||
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)
|
||||
and [StatefulSets](/docs/concepts/workloads/controllers/statefulset/),
|
||||
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/pod/),
|
||||
as well as other core concepts like [Pods](/docs/concepts/workloads/pods/),
|
||||
[Services](/docs/concepts/services-networking/service/), and
|
||||
[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/).
|
||||
* Some familiarity with MySQL helps, but this tutorial aims to present
|
||||
@@ -297,7 +297,7 @@ running while you force a Pod out of the Ready state.
|
||||
|
||||
### Break the Readiness Probe
|
||||
|
||||
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes)
|
||||
The [readiness probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
|
||||
for the `mysql` container runs the command `mysql -h 127.0.0.1 -e 'SELECT 1'`
|
||||
to make sure the server is up and able to execute queries.
|
||||
|
||||
|
||||
@@ -8,14 +8,13 @@ content_type: task
|
||||
<!-- overview -->
|
||||
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
|
||||
|
||||
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. Up to date information on this process can be found at the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo.
|
||||
|
||||
|
||||
|
||||
Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster.
|
||||
Up to date information on this process can be found at the
|
||||
[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
|
||||
* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
|
||||
* Service Catalog requires a Kubernetes cluster running version 1.7 or higher.
|
||||
* You must have a Kubernetes cluster with cluster DNS enabled.
|
||||
* If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled.
|
||||
|
||||
@@ -19,7 +19,7 @@ Service Catalog itself can work with any kind of managed service, not just Googl
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* Understand the key concepts of [Service Catalog](/docs/concepts/service-catalog/).
|
||||
* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/).
|
||||
* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`.
|
||||
* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts.
|
||||
* Service Catalog requires Kubernetes version 1.7+.
|
||||
|
||||
@@ -33,7 +33,7 @@ Once you have Minikube working, you can use it to
|
||||
## kind
|
||||
|
||||
Like Minikube, [kind](https://kind.sigs.k8s.io/docs/) lets you run Kubernetes on
|
||||
your local compute. Unlike Minikuke, kind only works with a single container runtime:
|
||||
your local computer. Unlike Minikube, kind only works with a single container runtime:
|
||||
it requires that you have [Docker](https://docs.docker.com/get-docker/) installed
|
||||
and configured.
|
||||
|
||||
|
||||
@@ -11,13 +11,18 @@ card:
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
The Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), allows you to run commands against Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For a complete list of kubectl operations, see [Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows
|
||||
you to run commands against Kubernetes clusters.
|
||||
You can use kubectl to deploy applications, inspect and manage cluster resources,
|
||||
and view logs. For a complete list of kubectl operations, see
|
||||
[Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
You must use a kubectl version that is within one minor version difference of your cluster.
|
||||
For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master.
|
||||
Using the latest version of kubectl helps avoid unforeseen issues.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
||||
@@ -45,16 +45,6 @@ Before walking through each tutorial, you may want to bookmark the
|
||||
|
||||
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
* [Set Up a CI/CD Pipeline with Kubernetes Part 1: Overview](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview)
|
||||
|
||||
* [Set Up a CI/CD Pipeline with a Jenkins Pod in Kubernetes (Part 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2)
|
||||
|
||||
* [Run and Scale a Distributed Crossword Puzzle App with CI/CD on Kubernetes (Part 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3)
|
||||
|
||||
* [Set Up CI/CD for a Distributed Crossword Puzzle App on Kubernetes (Part 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4)
|
||||
|
||||
## Clusters
|
||||
|
||||
* [AppArmor](/docs/tutorials/clusters/apparmor/)
|
||||
|
||||
@@ -29,7 +29,7 @@ weight: 10
|
||||
|
||||
<div class="col-md-8">
|
||||
<h2>Kubernetes Pods</h2>
|
||||
<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker or rkt), and some shared resources for those containers. Those resources include:</p>
|
||||
<p>When you created a Deployment in Module <a href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/">2</a>, Kubernetes created a <b>Pod</b> to host your application instance. A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources for those containers. Those resources include:</p>
|
||||
<ul>
|
||||
<li>Shared storage, as Volumes</li>
|
||||
<li>Networking, as a unique cluster IP address</li>
|
||||
@@ -51,7 +51,7 @@ weight: 10
|
||||
</div>
|
||||
<div class="content__box content__box_fill">
|
||||
<p><i>
|
||||
A Pod is a group of one or more application containers (such as Docker or rkt) and includes shared storage (volumes), IP address and information about how to run them.
|
||||
A Pod is a group of one or more application containers (such as Docker) and includes shared storage (volumes), IP address and information about how to run them.
|
||||
</i></p>
|
||||
</div>
|
||||
</div>
|
||||
@@ -79,7 +79,7 @@ weight: 10
|
||||
<p>Every Kubernetes Node runs at least:</p>
|
||||
<ul>
|
||||
<li>Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.</li>
|
||||
<li>A container runtime (like Docker, rkt) responsible for pulling the container image from a registry, unpacking the container, and running the application.</li>
|
||||
<li>A container runtime (like Docker) responsible for pulling the container image from a registry, unpacking the container, and running the application.</li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -150,7 +150,7 @@ ip addr
|
||||
|
||||
…then use `wget` to query the local webserver
|
||||
```shell
|
||||
# Replace 10.0.170.92 with the Pod's IPv4 address
|
||||
# Replace "10.0.170.92" with the IPv4 address of the Service named "clusterip"
|
||||
wget -qO - 10.0.170.92
|
||||
```
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user