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

resolving conflicts

Browse Source
This commit is contained in:
Savitha Raghunathan
2020-06-16 17:08:15 -04:00
parent 3ad8c45b0b 13ca92d745
commit 7ddedb00a0
1497 changed files with 24525 additions and 14364 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/_index.md
+11 -10
View File
@@ -1,17 +1,17 @@
---
title: Concepts
main_menu: true
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
The Concepts section helps you learn about the parts of the Kubernetes system and the abstractions Kubernetes uses to represent your {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}, and helps you obtain a deeper understanding of how Kubernetes works.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview
@@ -41,7 +41,7 @@ Kubernetes also contains higher-level abstractions that rely on [controllers](/d
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
* [Job](/docs/concepts/workloads/controllers/job/)
## Kubernetes Control Plane
@@ -60,12 +60,13 @@ The Kubernetes master is responsible for maintaining the desired state for your
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
If you would like to write a concept page, see
[Using Page Templates](/docs/home/contribute/page-templates/)
for information about the concept page type and the concept template.
[Page Content Types](/docs/home/contribute/style/page-content-types/#concept)
for information about the concept page types.
{{% /capture %}}
content/en/docs/concepts/architecture/cloud-controller.md
+7 -7
View File
@@ -1,10 +1,10 @@
---
title: Cloud Controller Manager
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
@@ -17,9 +17,9 @@ components.
The cloud-controller-manager is structured using a plugin
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Design
@@ -200,8 +200,9 @@ rules:
- update
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
has instructions on running and managing the cloud controller manager.
@@ -212,4 +213,3 @@ The cloud controller manager uses Go interfaces to allow implementations from an
The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
{{% /capture %}}
content/en/docs/concepts/architecture/control-plane-node-communication.md
+11 -8
View File
@@ -3,22 +3,22 @@ reviewers:
- dchen1107
- liggitt
title: Control Plane-Node Communication
content_template: templates/concept
content_type: concept
weight: 20
aliases:
- master-node-communication
---
{{% capture overview %}}
<!-- overview -->
This document catalogs the communication paths between the control plane (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Node to Control Plane
All communication paths from the nodes to the control plane terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled.
One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed.
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
@@ -31,9 +31,11 @@ The control plane components also communicate with the cluster apiserver over th
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
## Control Plane to node
There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
### apiserver to kubelet
The connections from the apiserver to the kubelet are used for:
* Fetching logs for pods.
@@ -61,9 +63,10 @@ This tunnel ensures that the traffic is not exposed outside of the network in wh
SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.
### Konnectivity service
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to Cluster communication. The Konnectivity consists of two parts, the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the connections.
All control plane to nodes traffic then goes through these connections.
As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server and the Konnectivity agents, running in the control plane network and the nodes network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections.
After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.
See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set it up in your cluster.
Follow the [Konnectivity service task](/docs/tasks/extend-kubernetes/setup-konnectivity/) to set up the Konnectivity service in your cluster.
content/en/docs/concepts/architecture/controller.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: Controllers
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
In robotics and automation, a _control loop_ is
a non-terminating loop that regulates the state of a system.
@@ -18,10 +18,10 @@ closer to the desired state, by turning equipment on or off.
{{< glossary_definition term_id="controller" length="short">}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Controller pattern
@@ -150,11 +150,12 @@ You can run your own controller as a set of Pods,
or externally to Kubernetes. What fits best will depend on what that particular
controller does.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane)
* Discover some of the basic [Kubernetes objects](/docs/concepts/#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.
{{% /capture %}}
content/en/docs/concepts/architecture/nodes.md
+8 -7
View File
@@ -3,11 +3,11 @@ reviewers:
- caesarxuchao
- dchen1107
title: Nodes
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
Kubernetes runs your workload by placing containers into Pods to run on _Nodes_.
A node may be a virtual or physical machine, depending on the cluster. Each node
@@ -23,9 +23,9 @@ The [components](/docs/concepts/overview/components/#node-components) on a node
{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the
{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Management
@@ -332,12 +332,13 @@ the kubelet can use topology hints when making resource assignment decisions.
See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/)
for more information.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node.
* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/).
* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
{{% /capture %}}
content/en/docs/concepts/cluster-administration/addons.md
+5 -5
View File
@@ -1,9 +1,9 @@
---
title: Installing Addons
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
Add-ons extend the functionality of Kubernetes.
@@ -12,10 +12,10 @@ This page lists some of the available add-ons and links to their respective inst
Add-ons in each section are sorted alphabetically - the ordering does not imply any preferential status.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Networking and Network Policy
@@ -55,4 +55,4 @@ There are several other add-ons documented in the deprecated [cluster/addons](ht
Well-maintained ones should be linked to here. PRs welcome!
{{% /capture %}}
content/en/docs/concepts/cluster-administration/certificates.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
title: Certificates
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
When using client certificate authentication, you can generate certificates
manually through `easyrsa`, `openssl` or `cfssl`.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
### easyrsa
@@ -249,4 +249,4 @@ You can use the `certificates.k8s.io` API to provision
x509 certificates to use for authentication as documented
[here](/docs/tasks/tls/managing-tls-in-a-cluster).
{{% /capture %}}
content/en/docs/concepts/cluster-administration/cloud-providers.md
+5 -5
View File
@@ -1,16 +1,16 @@
---
title: Cloud Providers
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This page explains how to manage Kubernetes running on a specific
cloud provider.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
### kubeadm
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) is a popular option for creating kubernetes clusters.
kubeadm has configuration options to specify configuration information for cloud providers. For example a typical
@@ -363,7 +363,7 @@ Kubernetes network plugin and should appear in the `[Route]` section of the
[kubenet]: /docs/concepts/cluster-administration/network-plugins/#kubenet
{{% /capture %}}
## OVirt
content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
+5 -5
View File
@@ -3,16 +3,16 @@ reviewers:
- davidopp
- lavalamp
title: Cluster Administration Overview
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Planning a cluster
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
@@ -68,6 +68,6 @@ Note: Not all distros are actively maintained. Choose distros which have been te
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
{{% /capture %}}
content/en/docs/concepts/cluster-administration/flow-control.md
+7 -7
View File
@@ -1,10 +1,10 @@
---
title: API Priority and Fairness
content_template: templates/concept
content_type: concept
min-kubernetes-server-version: v1.18
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
@@ -33,9 +33,9 @@ the `--max-requests-inflight` flag without the API Priority and
Fairness feature enabled.
{{< /caution >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Enabling API Priority and Fairness
@@ -366,13 +366,13 @@ poorly-behaved workloads that may be harming system health.
request and the PriorityLevel to which it was assigned.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
For background information on design details for API priority and fairness, see
the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
You can make suggestions and feature requests via [SIG API
Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery).
{{% /capture %}}
content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+8 -7
View File
@@ -1,20 +1,20 @@
---
reviewers:
title: Configuring kubelet Garbage Collection
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
Garbage collection is a helpful function of kubelet that will clean up unused images and unused containers. Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes.
External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Image Collection
@@ -77,10 +77,11 @@ Including:
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details.
{{% /capture %}}
content/en/docs/concepts/cluster-administration/logging.md
+5 -5
View File
@@ -3,20 +3,20 @@ reviewers:
- piosz
- x13n
title: Logging Architecture
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. Most modern applications have some kind of logging mechanism; as such, most container engines are likewise designed to support some kind of logging. The easiest and most embraced logging method for containerized applications is to write to the standard output and standard error streams.
However, the native functionality provided by a container engine or runtime is usually not enough for a complete logging solution. For example, if a container crashes, a pod is evicted, or a node dies, you'll usually still want to access your application's logs. As such, logs should have a separate storage and lifecycle independent of nodes, pods, or containers. This concept is called _cluster-level-logging_. Cluster-level logging requires a separate backend to store, analyze, and query logs. Kubernetes provides no native storage solution for log data, but you can integrate many existing logging solutions into your Kubernetes cluster.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Cluster-level logging architectures are described in assumption that
a logging backend is present inside or outside of your cluster. If you're
@@ -267,4 +267,4 @@ You can implement cluster-level logging by exposing or pushing logs directly fro
every application; however, the implementation for such a logging mechanism
is outside the scope of Kubernetes.
{{% /capture %}}
content/en/docs/concepts/cluster-administration/manage-deployment.md
+8 -7
View File
@@ -2,18 +2,18 @@
reviewers:
- janetkuo
title: Managing Resources
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
You've deployed your application and exposed it via a service. Now what? Kubernetes provides a number of tools to help you manage your application deployment, including scaling and updating. Among the features that we will discuss in more depth are [configuration files](/docs/concepts/configuration/overview/) and [labels](/docs/concepts/overview/working-with-objects/labels/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Organizing resource configurations
@@ -449,11 +449,12 @@ kubectl edit deployment/my-nginx
That's it! The Deployment will declaratively update the deployed nginx application progressively behind the scene. It ensures that only a certain number of old replicas may be down while they are being updated, and only a certain number of new replicas may be created above the desired number of pods. To learn more details about it, visit [Deployment page](/docs/concepts/workloads/controllers/deployment/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/).
- See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/).
{{% /capture %}}
content/en/docs/concepts/cluster-administration/monitoring.md
+8 -7
View File
@@ -4,21 +4,21 @@ reviewers:
- brancz
- logicalhan
- RainbowMango
content_template: templates/concept
content_type: concept
weight: 60
aliases:
- controller-metrics.md
---
{{% capture overview %}}
<!-- overview -->
System component metrics can give a better look into what is happening inside them. Metrics are particularly useful for building dashboards and alerts.
Metrics in Kubernetes control plane are emitted in [prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and are human readable.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Metrics in Kubernetes
@@ -124,10 +124,11 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics
* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)
* Read about the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior )
{{% /capture %}}
content/en/docs/concepts/cluster-administration/networking.md
+8 -7
View File
@@ -2,11 +2,11 @@
reviewers:
- thockin
title: Cluster Networking
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
Networking is a central part of Kubernetes, but it can be challenging to
understand exactly how it is expected to work. There are 4 distinct networking
problems to address:
@@ -17,10 +17,10 @@ problems to address:
3. Pod-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
4. External-to-Service communications: this is covered by [services](/docs/concepts/services-networking/service/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetes is all about sharing machines between applications. Typically,
sharing machines requires ensuring that two applications do not try to use the
@@ -312,12 +312,13 @@ Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-pl
or stand-alone. In either version, it doesn't require any configuration or extra code
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
The early design of the networking model and its rationale, and some future
plans are described in more detail in the [networking design
document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md).
{{% /capture %}}
content/en/docs/concepts/cluster-administration/proxies.md
+5 -5
View File
@@ -1,14 +1,14 @@
---
title: Proxies in Kubernetes
content_template: templates/concept
content_type: concept
weight: 90
---
{{% capture overview %}}
<!-- overview -->
This page explains proxies used with Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Proxies
@@ -62,6 +62,6 @@ will typically ensure that the latter types are setup correctly.
Proxies have replaced redirect capabilities. Redirects have been deprecated.
{{% /capture %}}
content/en/docs/concepts/configuration/configmap.md
+11 -10
View File
@@ -1,23 +1,23 @@
---
title: ConfigMaps
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< glossary_definition term_id="configmap" prepend="A ConfigMap is" length="all" >}}
{{< caution >}}
ConfigMap does not provide secrecy or encryption.
ConfigMap does not provide secrecy or encryption.
If the data you want to store are confidential, use a
{{< glossary_tooltip text="Secret" term_id="secret" >}} rather than a ConfigMap,
or use additional (third party) tools to keep your data private.
{{< /caution >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Motivation
Use a ConfigMap for setting configuration data separately from application code.
@@ -85,9 +85,9 @@ These different methods lend themselves to different ways of modeling
the data being consumed.
For the first three methods, the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the data from
the Secret when it launches container(s) for a Pod.
the ConfigMap when it launches container(s) for a Pod.
The fourth method means you have to write code to read the Secret and its data.
The fourth method means you have to write code to read the ConfigMap and its data.
However, because you're using the Kubernetes API directly, your application can
subscribe to get updates whenever the ConfigMap changes, and react
when that happens. By accessing the Kubernetes API directly, this
@@ -243,12 +243,13 @@ Existing Pods maintain a mount point to the deleted ConfigMap - it is recommende
these pods.
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [Secrets](/docs/concepts/configuration/secret/).
* Read [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/).
* Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for
separating code from configuration.
{{% /capture %}}
content/en/docs/concepts/configuration/manage-resources-containers.md
+8 -7
View File
@@ -1,6 +1,6 @@
---
title: Managing Resources for Containers
content_template: templates/concept
content_type: concept
weight: 40
feature:
title: Automatic bin packing
@@ -8,7 +8,7 @@ feature:
Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
---
{{% capture overview %}}
<!-- overview -->
When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how
much of each resource a {{< glossary_tooltip text="Container" term_id="container" >}} needs.
@@ -21,10 +21,10 @@ allowed to use more of that resource than the limit you set. The kubelet also re
at least the _request_ amount of that system resource specifically for that container
to use.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Requests and limits
@@ -740,10 +740,11 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Get hands-on experience [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
@@ -758,4 +759,4 @@ You can see that the Container was terminated because of `reason:OOM Killed`, wh
* Read about [project quotas](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS
{{% /capture %}}
content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+8 -7
View File
@@ -1,10 +1,10 @@
---
title: Organizing Cluster Access Using kubeconfig Files
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
Use kubeconfig files to organize information about clusters, users, namespaces, and
authentication mechanisms. The `kubectl` command-line tool uses kubeconfig files to
@@ -25,10 +25,10 @@ variable or by setting the
For step-by-step instructions on creating and specifying kubeconfig files, see
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Supporting multiple clusters, users, and authentication mechanisms
@@ -143,14 +143,15 @@ File references on the command line are relative to the current working director
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
are stored absolutely.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
{{% /capture %}}
content/en/docs/concepts/configuration/overview.md
+6 -6
View File
@@ -2,17 +2,17 @@
reviewers:
- mikedanese
title: Configuration Best Practices
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
This document highlights and consolidates configuration best practices that are introduced throughout the user guide, Getting Started documentation, and examples.
This is a living document. If you think of something that is not on this list but might be useful to others, please don't hesitate to file an issue or submit a PR.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## General Configuration Tips
- When defining configurations, specify the latest stable API version.
@@ -34,7 +34,7 @@ This is a living document. If you think of something that is not on this list bu
- 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.
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) may also be appropriate.
A Deployment, which both creates a ReplicaSet to ensure that the desired number of Pods is always available, and specifies a strategy to replace Pods (such as [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), is almost always preferable to creating Pods directly, except for some explicit [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) scenarios. A [Job](/docs/concepts/workloads/controllers/job/) may also be appropriate.
## Services
@@ -105,5 +105,5 @@ The caching semantics of the underlying image provider make even `imagePullPolic
- Use `kubectl run` and `kubectl expose` to quickly create single-container Deployments and Services. See [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) for an example.
{{% /capture %}}
content/en/docs/concepts/configuration/pod-overhead.md
+8 -7
View File
@@ -4,11 +4,11 @@ reviewers:
- egernst
- tallclair
title: Pod Overhead
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -19,10 +19,10 @@ _Pod Overhead_ is a feature for accounting for the resources consumed by the Pod
on top of the container requests & limits.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
In Kubernetes, the Pod's overhead is set at
[admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)
@@ -188,11 +188,12 @@ running with a defined Overhead. This functionality is not available in the 1.9
kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics
from source in the meantime.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [RuntimeClass](/docs/concepts/containers/runtime-class/)
* [PodOverhead Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
{{% /capture %}}
content/en/docs/concepts/configuration/pod-priority-preemption.md
+8 -7
View File
@@ -3,11 +3,11 @@ reviewers:
- davidopp
- wojtek-t
title: Pod Priority and Preemption
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.14" state="stable" >}}
@@ -16,9 +16,9 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
scheduler tries to preempt (evict) lower priority Pods to make scheduling of the
pending Pod possible.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
{{< warning >}}
@@ -407,7 +407,8 @@ usage does not exceed their requests. If a Pod with lower priority is not
exceeding its requests, it won't be evicted. Another Pod with higher priority
that exceeds its requests may be evicted.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
{{% /capture %}}
content/en/docs/concepts/configuration/resource-bin-packing.md
+14 -14
View File
@@ -4,19 +4,19 @@ reviewers:
- k82cn
- ahg-g
title: Resource Bin Packing for Extended Resources
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
@@ -132,23 +132,23 @@ CPU: 1
Node Score:
intel.com/foo = resourceScoringFunction((2+1),4)
= (100 - ((4-3)*100/4)
= (100 - 25)
= 75
= rawScoringFunction(75)
= 7
= (100 - ((4-3)*100/4)
= (100 - 25)
= 75 # requested + used = 75% * available
= rawScoringFunction(75)
= 7 # floor(75/10)
Memory = resourceScoringFunction((256+256),1024)
= (100 -((1024-512)*100/1024))
= 50
= 50 # requested + used = 50% * available
= rawScoringFunction(50)
= 5
= 5 # floor(50/10)
CPU = resourceScoringFunction((2+1),8)
= (100 -((8-3)*100/8))
= 37.5
= 37.5 # requested + used = 37.5% * available
= rawScoringFunction(37.5)
= 3
= 3 # floor(37.5/10)
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
= 5
@@ -194,4 +194,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
```
{{% /capture %}}
content/en/docs/concepts/configuration/secret.md
+8 -7
View File
@@ -2,7 +2,7 @@
reviewers:
- mikedanese
title: Secrets
content_template: templates/concept
content_type: concept
feature:
title: Secret and configuration management
description: >
@@ -10,16 +10,16 @@ feature:
weight: 30
---
{{% capture overview %}}
<!-- overview -->
Kubernetes Secrets let you store and manage sensitive information, such
as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret
is safer and more flexible than putting it verbatim in a
{{< glossary_tooltip term_id="pod" >}} definition or in a {{< glossary_tooltip text="container image" term_id="image" >}}. See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview of Secrets
@@ -29,12 +29,13 @@ Pod specification or in an image. Users can create secrets and the system
also creates some secrets.
To use a secret, a Pod needs to reference the secret.
A secret can be used with a Pod in two ways:
A secret can be used with a Pod in three ways:
- As files in a
- As [files](#using-secrets-as-files-from-a-pod) in a
{{< glossary_tooltip text="volume" term_id="volume" >}} mounted on one or more of
its containers.
- By the kubelet when pulling images for the Pod.
- As [container environment variable](#using-secrets-as-environment-variables).
- By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod.
### Built-in Secrets
content/en/docs/concepts/containers/container-environment.md
+8 -7
View File
@@ -3,18 +3,18 @@ reviewers:
- mikedanese
- thockin
title: Container Environment
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This page describes the resources available to Containers in the Container environment.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Container environment
@@ -53,12 +53,13 @@ FOO_SERVICE_PORT=<the port the service is running on>
Services have dedicated IP addresses and are available to the Container via DNS,
if [DNS addon](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled. 
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
{{% /capture %}}
content/en/docs/concepts/containers/container-lifecycle-hooks.md
+8 -7
View File
@@ -3,19 +3,19 @@ reviewers:
- mikedanese
- thockin
title: Container Lifecycle Hooks
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This page describes how kubelet managed Containers can use the Container lifecycle hook framework
to run code triggered by events during their management lifecycle.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview
@@ -112,12 +112,13 @@ Events:
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about the [Container environment](/docs/concepts/containers/container-environment/).
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
{{% /capture %}}
content/en/docs/concepts/containers/images.md
+97 -167
View File
@@ -3,24 +3,56 @@ reviewers:
- erictune
- thockin
title: Images
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
You create your Docker image and push it to a registry before referring to it in a Kubernetes pod.
A container image represents binary data that encapsulates an application and all its
software depencies. Container images are executable software bundles that can run
standalone and that make very well defined assumptions about their runtime environment.
The `image` property of a container supports the same syntax as the `docker` command does, including private registries and tags.
You typically create a container image of your application and push it to a registry
before referring to it in a
{{< glossary_tooltip text="Pod" term_id="pod" >}}
{{% /capture %}}
This page provides an outline of the container image concept.
{{% capture body %}}
<!-- body -->
## Image names
Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`.
Images can also include a registry hostname; for example: `fictional.registry.example/imagename`,
and possible a port number as well; for example: `fictional.registry.example:10443/imagename`.
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
After the image name part you can add a _tag_ (as also using with commands such
as `docker` and `podman`).
Tags let you identify different versions of the same series of images.
Image tags consist of lowercase and uppercase letters, digits, underscores (`_`),
periods (`.`), and dashes (`-`).
There are additional rules about where you can place the separator
characters (`_`, `-`, and `.`) inside an image tag.
If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
{{< caution >}}
You should avoid using the `latest` tag when deploying containers in production,
as it is harder to track which version of the image is running and more difficult
to roll back to a working version.
Instead, specify a meaningful tag such as `v1.42.0`.
{{< /caution >}}
## Updating Images
The default pull policy is `IfNotPresent` which causes the Kubelet to skip
The default pull policy is `IfNotPresent` which causes the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
pulling an image if it already exists. If you would like to always force a pull,
you can do one of the following:
@@ -29,45 +61,16 @@ you can do one of the following:
- omit the `imagePullPolicy` and the tag for the image to use.
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
Note that you should avoid using `:latest` tag, see [Best Practices for Configuration](/docs/concepts/configuration/overview/#container-images) for more information.
## Multi-architecture Images with Manifests
## Building Multi-architecture Images with Manifests
As well as providing binary images, a container registry can also server a [container image manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md). A manifest can reference image manifests for architecture-specific versions of an container. The idea is that you can have a name for an image (for example: `pause`, `example/mycontainer`, `kube-apiserver`) and allow different systems to fetch the right binary image for the machine architecture they are using.
Docker CLI now supports the following command `docker manifest` with sub commands like `create`, `annotate` and `push`. These commands can be used to build and push the manifests. You can use `docker manifest inspect` to view the manifest.
Please see docker documentation here:
https://docs.docker.com/edge/engine/reference/commandline/manifest/
See examples on how we use this in our build harness:
https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=
These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands.
{{< note >}}
Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
{{< /note >}}
If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
For Kubernetes, we have typically used images with suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
Kubernetes itself typically names container images with a suffix `-$(ARCH)`. For backward compatibility, please generate the older images with suffixes. The idea is to generate say `pause` image which has the manifest for all the arch(es) and say `pause-amd64` which is backwards compatible for older configurations or YAML files which may have hard coded the images with suffixes.
## Using a Private Registry
Private registries may require keys to read images from them.
Private registries may require keys to read images from them.
Credentials can be provided in several ways:
- Using Google Container Registry
- Per-cluster
- automatically configured on Google Compute Engine or Google Kubernetes Engine
- all pods can read the project's private registry
- Using Amazon Elastic Container Registry (ECR)
- use IAM roles and policies to control access to ECR repositories
- automatically refreshes ECR login credentials
- Using Oracle Cloud Infrastructure Registry (OCIR)
- use IAM roles and policies to control access to OCIR repositories
- Using Azure Container Registry (ACR)
- Using IBM Cloud Container Registry
- use IAM roles and policies to grant access to IBM Cloud Container Registry
- Configuring Nodes to Authenticate to a Private Registry
- all pods can read any configured private registries
- requires node configuration by cluster administrator
@@ -76,135 +79,59 @@ Credentials can be provided in several ways:
- requires root access to all nodes to setup
- Specifying ImagePullSecrets on a Pod
- only pods which provide own keys can access the private registry
- Vendor-specific or local extensions
- if you're using a custom node configuration, you (or your cloud
provider) can implement your mechanism for authenticating the node
to the container registry.
Each option is described in more detail below.
These options are explaind in more detail below.
### Configuring Nodes to authenticate to a Private Registry
### Using Google Container Registry
If you run Docker on your nodes, you can configure the Docker container
runtuime to authenticate to a private container registry.
Kubernetes has native support for the [Google Container
Registry (GCR)](https://cloud.google.com/tools/container-registry/), when running on Google Compute
Engine (GCE). If you are running your cluster on GCE or Google Kubernetes Engine, simply
use the full image name (e.g. gcr.io/my_project/image:tag).
All pods in a cluster will have read access to images in this registry.
The kubelet will authenticate to GCR using the instance's
Google service account. The service account on the instance
will have a `https://www.googleapis.com/auth/devstorage.read_only`,
so it can pull from the project's GCR, but not push.
### Using Amazon Elastic Container Registry
Kubernetes has native support for the [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), when nodes are AWS EC2 instances.
Simply use the full image name (e.g. `ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag`)
in the Pod definition.
All users of the cluster who can create pods will be able to run pods that use any of the
images in the ECR registry.
The kubelet will fetch and periodically refresh ECR credentials. It needs the following permissions to do this:
- `ecr:GetAuthorizationToken`
- `ecr:BatchCheckLayerAvailability`
- `ecr:GetDownloadUrlForLayer`
- `ecr:GetRepositoryPolicy`
- `ecr:DescribeRepositories`
- `ecr:ListImages`
- `ecr:BatchGetImage`
Requirements:
- You must be using kubelet version `v1.2.0` or newer. (e.g. run `/usr/bin/kubelet --version=true`).
- If your nodes are in region A and your registry is in a different region B, you need version `v1.3.0` or newer.
- ECR must be offered in your region
Troubleshooting:
- Verify all requirements above.
- Get $REGION (e.g. `us-west-2`) credentials on your workstation. SSH into the host and run Docker manually with those creds. Does it work?
- Verify kubelet is running with `--cloud-provider=aws`.
- Increase kubelet log level verbosity to at least 3 and check kubelet logs (e.g. `journalctl -u kubelet`) for log lines like:
- `aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API`
- `aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com`
### Using Azure Container Registry (ACR)
When using [Azure Container Registry](https://azure.microsoft.com/en-us/services/container-registry/)
you can authenticate using either an admin user or a service principal.
In either case, authentication is done via standard Docker authentication. These instructions assume the
[azure-cli](https://github.com/azure/azure-cli) command line tool.
You first need to create a registry and generate credentials, complete documentation for this can be found in
the [Azure container registry documentation](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli).
Once you have created your container registry, you will use the following credentials to login:
* `DOCKER_USER` : service principal, or admin username
* `DOCKER_PASSWORD`: service principal password, or admin user password
* `DOCKER_REGISTRY_SERVER`: `${some-registry-name}.azurecr.io`
* `DOCKER_EMAIL`: `${some-email-address}`
Once you have those variables filled in you can
[configure a Kubernetes Secret and use it to deploy a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
### Using IBM Cloud Container Registry
IBM Cloud Container Registry provides a multi-tenant private image registry that you can use to safely store and share your images. By default, images in your private registry are scanned by the integrated Vulnerability Advisor to detect security issues and potential vulnerabilities. Users in your IBM Cloud account can access your images, or you can use IAM roles and policies to grant access to IBM Cloud Container Registry namespaces.
To install the IBM Cloud Container Registry CLI plug-in and create a namespace for your images, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).
If you are using the same account and region, you can deploy images that are stored in IBM Cloud Container Registry into the default namespace of your IBM Cloud Kubernetes Service cluster without any additional configuration, see [Building containers from images](https://cloud.ibm.com/docs/containers?topic=containers-images). For other configuration options, see [Understanding how to authorize your cluster to pull images from a registry](https://cloud.ibm.com/docs/containers?topic=containers-registry#cluster_registry_auth).
### Configuring Nodes to Authenticate to a Private Registry
This approach is suitable if you can control node configuration.
{{< note >}}
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
{{< /note >}}
{{< note >}}
If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
manage and update the ECR login credentials. You cannot use this approach.
{{< /note >}}
{{< note >}}
This approach is suitable if you can control node configuration. It
will not work reliably on GCE, and any other cloud provider that does automatic
node replacement.
{{< /note >}}
{{< note >}}
Kubernetes as of now only supports the `auths` and `HttpHeaders` section of docker config. This means credential helpers (`credHelpers` or `credsStore`) are not supported.
Kubernetes as only supports the `auths` and `HttpHeaders` section in Docker configuration.
Docker credential helpers (`credHelpers` or `credsStore`) are not supported.
{{< /note >}}
Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file. If you put the same file
in the search paths list below, kubelet uses it as the credential provider when pulling images.
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{cwd of kubelet}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{cwd of kubelet}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{cwd of kubelet}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{cwd of kubelet}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
{{< note >}}
You may have to set `HOME=/root` explicitly in your environment file for kubelet.
You may have to set `HOME=/root` explicitly in the environment of the kubelet process.
{{< /note >}}
Here are the recommended steps to configuring your nodes to use a private registry. In this
example, run these on your desktop/laptop:
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json`.
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json` on your PC.
1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use.
1. Get a list of your nodes, for example:
- if you want the names: `nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')`
- if you want to get the IPs: `nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')`
1. Get a list of your nodes; for example:
- if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
- if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
1. Copy your local `.docker/config.json` to one of the search paths list above.
- for example: `for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done`
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
Verify by creating a pod that uses a private image, e.g.:
{{< note >}}
For production clusers, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
{{< /note >}}
Verify by creating a Pod that uses a private image; for example:
```shell
kubectl apply -f - <<EOF
@@ -253,17 +180,13 @@ registry keys are added to the `.docker/config.json`.
### Pre-pulled Images
{{< note >}}
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
{{< /note >}}
{{< note >}}
This approach is suitable if you can control node configuration. It
will not work reliably on GCE, and any other cloud provider that does automatic
node replacement.
will not work reliably if your cloud provider manages nodes and replaces
them automatically.
{{< /note >}}
By default, the kubelet will try to pull each image from the specified registry.
By default, the kubelet tries to pull each image from the specified registry.
However, if the `imagePullPolicy` property of the container is set to `IfNotPresent` or `Never`,
then a local image is used (preferentially or exclusively, respectively).
@@ -277,11 +200,11 @@ All pods will have read access to any pre-pulled images.
### Specifying ImagePullSecrets on a Pod
{{< note >}}
This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
where node creation is automated.
This is the recommended approach to run containers based on images
in private registries.
{{< /note >}}
Kubernetes supports specifying registry keys on a pod.
Kubernetes supports specifying container image registry keys on a Pod.
#### Creating a Secret with a Docker Config
@@ -292,11 +215,13 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER
```
If you already have a Docker credentials file then, rather than using the above
command, you can import the credentials file as a Kubernetes secret.
command, you can import the credentials file as a Kubernetes
{{< glossary_tooltip text="Secrets" term_id="secret" >}}.
[Create a Secret based on existing Docker credentials](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) explains how to set this up.
This is particularly useful if you are using multiple private container
registries, as `kubectl create secret docker-registry` creates a Secret that will
only work with a single private registry.
registries, as `kubectl create secret docker-registry` creates a Secret that
only works with a single private registry.
{{< note >}}
Pods can only reference image pull secrets in their own namespace,
@@ -306,7 +231,9 @@ so this process needs to be done one time per namespace.
#### Referring to an imagePullSecrets on a Pod
Now, you can create pods which reference that secret by adding an `imagePullSecrets`
section to a pod definition.
section to a Pod definition.
For example:
```shell
cat <<EOF > pod.yaml
@@ -332,13 +259,14 @@ EOF
This needs to be done for each pod that is using a private registry.
However, setting of this field can be automated by setting the imagePullSecrets
in a [serviceAccount](/docs/user-guide/service-accounts) resource.
in a [ServiceAccount](/docs/user-guide/service-accounts) resource.
Check [Add ImagePullSecrets to a Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for detailed instructions.
You can use this in conjunction with a per-node `.docker/config.json`. The credentials
will be merged. This approach will work on Google Kubernetes Engine.
will be merged.
### Use Cases
## Use Cases
There are a number of solutions for configuring private registries. Here are some
common use cases and suggested solutions.
@@ -346,7 +274,7 @@ common use cases and suggested solutions.
1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images.
- Use public images on the Docker hub.
- No configuration required.
- On GCE/Google Kubernetes Engine, a local mirror is automatically used for improved speed and availability.
- Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images.
1. Cluster running some proprietary images which should be hidden to those outside the company, but
visible to all cluster users.
- Use a hosted private [Docker registry](https://docs.docker.com/registry/).
@@ -354,7 +282,7 @@ common use cases and suggested solutions.
- Manually configure .docker/config.json on each node as described above.
- Or, run an internal private registry behind your firewall with open read access.
- No Kubernetes configuration is required.
- Or, when on GCE/Google Kubernetes Engine, use the project's Google Container Registry.
- Use a hosted container image registry service that controls image access
- It will work better with cluster autoscaling than manual node configuration.
- Or, on a cluster where changing the node configuration is inconvenient, use `imagePullSecrets`.
1. Cluster with proprietary images, a few of which require stricter access control.
@@ -370,4 +298,6 @@ common use cases and suggested solutions.
If you need access to multiple registries, you can create one secret for each registry.
Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json`
{{% /capture %}}
## {{% heading "whatsnext" %}}
* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
content/en/docs/concepts/containers/overview.md
+8 -7
View File
@@ -3,11 +3,11 @@ reviewers:
- erictune
- thockin
title: Containers overview
content_template: templates/concept
content_type: concept
weight: 1
---
{{% capture overview %}}
<!-- overview -->
Containers are a technology for packaging the (compiled) code for an
application along with the dependencies it needs at run time. Each
@@ -18,10 +18,10 @@ run it.
Containers decouple applications from underlying host infrastructure.
This makes deployment easier in different cloud or OS environments.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Container images
A [container image](/docs/concepts/containers/images/) is a ready-to-run
@@ -38,8 +38,9 @@ the change, then recreate the container to start from the updated image.
{{< glossary_definition term_id="container-runtime" length="all" >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [container images](/docs/concepts/containers/images/)
* Read about [Pods](/docs/concepts/workloads/pods/)
{{% /capture %}}
content/en/docs/concepts/containers/runtime-class.md
+8 -7
View File
@@ -3,11 +3,11 @@ reviewers:
- tallclair
- dchen1107
title: Runtime Class
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
@@ -16,10 +16,10 @@ This page describes the RuntimeClass resource and runtime selection mechanism.
RuntimeClass is a feature for selecting the container runtime configuration. The container runtime
configuration is used to run a Pod's containers.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Motivation
@@ -180,12 +180,13 @@ Pod overhead is defined in RuntimeClass through the `overhead` fields. Through t
you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads
are accounted for in Kubernetes.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
- [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
- Read about the [Pod Overhead](/docs/concepts/configuration/pod-overhead/) concept
- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
{{% /capture %}}
content/en/docs/concepts/example-concept-template.md
+11 -10
View File
@@ -2,11 +2,11 @@
title: Example Concept Template
reviewers:
- chenopis
content_template: templates/concept
content_type: concept
toc_hide: true
---
{{% capture overview %}}
<!-- overview -->
{{< note >}}
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
@@ -14,9 +14,9 @@ Be sure to also [create an entry in the table of contents](/docs/home/contribute
This page explains ...
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Understanding ...
@@ -26,15 +26,16 @@ Kubernetes provides ...
To use ...
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
**[Optional Section]**
* Learn more about [Writing a New Topic](/docs/home/contribute/write-new-topic/).
* See [Using Page Templates - Concept template](/docs/home/contribute/page-templates/#concept_template) for how to use this template.
{{% /capture %}}
* Learn more about [Writing a New Topic](/docs/home/contribute/style/write-new-topic/).
* See [Page Content Types - Concept](/docs/home/contribute/style/page-concept-types/#concept).
content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+11 -10
View File
@@ -4,20 +4,20 @@ reviewers:
- lavalamp
- cheftako
- chenopis
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs.
The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself.
The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Aggregation layer
@@ -34,13 +34,14 @@ If your extension API server cannot achieve that latency requirement, consider m
`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver
to disable the timeout restriction. This deprecated feature gate will be removed in a future release.
{{% /capture %}}
{{% capture whatsnext %}}
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
## {{% heading "whatsnext" %}}
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/).
* Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+16 -15
View File
@@ -3,19 +3,19 @@ title: Custom Resources
reviewers:
- enisoc
- deads2k
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
*Custom resources* are extensions of the Kubernetes API. This page discusses when to add a custom
resource to your Kubernetes cluster and when to use a standalone service. It describes the two
methods for adding custom resources and how to choose between them.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Custom resources
A *resource* is an endpoint in the [Kubernetes API](/docs/reference/using-api/api-overview/) that stores a collection of
@@ -128,7 +128,7 @@ Regardless of how they are installed, the new resources are referred to as Custo
## CustomResourceDefinitions
The [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
The [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
API resource allows you to define custom resources.
Defining a CRD object creates a new custom resource with a name and schema that you specify.
The Kubernetes API serves and handles the storage of your custom resource.
@@ -178,17 +178,17 @@ Aggregated APIs offer more advanced API features and customization of other feat
| Feature | Description | CRDs | Aggregated API |
| ------- | ----------- | ---- | -------------- |
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | Yes |
| Validation | Help users prevent errors and allow you to evolve your API independently of your clients. These features are most useful when there are many clients who can't all update at the same time. | Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/extend-api-custom-resource-definitions/#validation). Any other validations supported by addition of a [Validating Webhook](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9). | Yes, arbitrary validation checks |
| Defaulting | See above | Yes, either via [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) `default` keyword (GA in 1.17), or via a [Mutating Webhook](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) (though this will not be run when reading from etcd for old objects). | Yes |
| Multi-versioning | Allows serving the same object through two API versions. Can help ease API changes like renaming fields. Less important if you control your client versions. | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | Yes |
| Custom Storage | If you need storage with a different performance mode (for example, a time-series database instead of key-value store) or isolation for security (for example, encryption of sensitive information, etc.) | No | Yes |
| Custom Business Logic | Perform arbitrary checks or actions when creating, reading, updating or deleting an object | Yes, using [Webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). | Yes |
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | Yes |
| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | Yes |
| Scale Subresource | Allows systems like HorizontalPodAutoscaler and PodDisruptionBudget interact with your new resource | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | Yes |
| Status Subresource | Allows fine-grained access control where user writes the spec section and the controller writes the status section. Allows incrementing object Generation on custom resource data mutation (requires separate spec and status sections in the resource) | [Yes](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | Yes |
| Other Subresources | Add operations other than CRUD, such as "logs" or "exec". | No | Yes |
| strategic-merge-patch | The new endpoints support PATCH with `Content-Type: application/strategic-merge-patch+json`. Useful for updating objects that may be modified both locally, and by the server. For more information, see ["Update API Objects in Place Using kubectl patch"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) | No | Yes |
| Protocol Buffers | The new resource supports clients that want to use Protocol Buffers | No | Yes |
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
| OpenAPI Schema | Is there an OpenAPI (swagger) schema for the types that can be dynamically fetched from the server? Is the user protected from misspelling field names by ensuring only allowed fields are set? Are types enforced (in other words, don't put an `int` in a `string` field?) | Yes, based on the [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) schema (GA in 1.16). | Yes |
### Common Features
@@ -246,12 +246,13 @@ When you add a custom resource, you can access it using:
- A REST client that you write.
- A client generated using [Kubernetes client generation tools](https://github.com/kubernetes/code-generator) (generating one is an advanced undertaking, but some projects may provide a client along with the CRD or AA).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/).
* Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+8 -7
View File
@@ -2,11 +2,11 @@
reviewers:
title: Device Plugins
description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup.
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
@@ -19,9 +19,9 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap
and other similar computing resources that may require vendor specific initialization
and setup.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Device plugin registration
@@ -225,12 +225,13 @@ Here are some examples of device plugin implementations:
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin/trunk) for Xilinx FPGA devices
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
+8 -7
View File
@@ -4,12 +4,12 @@ reviewers:
- freehan
- thockin
title: Network Plugins
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="alpha" >}}
{{< caution >}}Alpha features can change rapidly. {{< /caution >}}
@@ -19,9 +19,9 @@ Network plugins in Kubernetes come in a few flavors:
* CNI plugins: adhere to the appc/CNI specification, designed for interoperability.
* Kubenet plugin: implements basic `cbr0` using the `bridge` and `host-local` CNI plugins
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Installation
@@ -166,8 +166,9 @@ This option is provided to the network-plugin; currently **only kubenet supports
* `--network-plugin=kubenet` specifies that we use the `kubenet` network plugin with CNI `bridge` and `host-local` plugins placed in `/opt/cni/bin` or `cni-bin-dir`.
* `--network-plugin-mtu=9001` specifies the MTU to use, currently only used by the `kubenet` network plugin.
{{% /capture %}}
{{% capture whatsnext %}}
{{% /capture %}}
## {{% heading "whatsnext" %}}
content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+8 -7
View File
@@ -5,11 +5,11 @@ reviewers:
- lavalamp
- cheftako
- chenopis
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
Kubernetes is highly configurable and extensible. As a result,
there is rarely a need to fork or submit patches to the Kubernetes
@@ -22,10 +22,10 @@ their work environment. Developers who are prospective {{< glossary_tooltip text
useful as an introduction to what extension points and patterns
exist, and their trade-offs and limitations.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Overview
@@ -194,10 +194,11 @@ The scheduler also supports a
that permits a webhook backend (scheduler extension) to filter and prioritize
the nodes chosen for a pod.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
@@ -207,4 +208,4 @@ the nodes chosen for a pod.
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/operator.md
+7 -7
View File
@@ -1,20 +1,20 @@
---
title: Operator pattern
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
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).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Motivation
@@ -113,9 +113,10 @@ Operator.
You also implement an Operator (that is, a Controller) using any language / runtime
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
@@ -129,4 +130,3 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
* Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md
+8 -7
View File
@@ -1,18 +1,18 @@
---
title: Poseidon-Firmament Scheduler
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
The Poseidon-Firmament scheduler is an alternate scheduler that can be deployed alongside the default Kubernetes scheduler.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -102,10 +102,11 @@ Pod-by-pod schedulers, such as the Kubernetes default scheduler, process Pods in
These downsides of pod-by-pod schedulers are addressed by batching or bulk scheduling in Poseidon-Firmament scheduler. Processing several pods in a batch allows the scheduler to jointly consider their placement, and thus to find the best trade-off for the whole batch instead of one pod. At the same time it amortizes work across pods resulting in much higher throughput.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* See [Poseidon-Firmament](https://github.com/kubernetes-sigs/poseidon#readme) on GitHub for more information.
* See the [design document](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/design/README.md) for Poseidon.
* Read [Firmament: Fast, Centralized Cluster Scheduling at Scale](https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf), the academic paper on the Firmament scheduling design.
* If you'd like to contribute to Poseidon-Firmament, refer to the [developer setup instructions](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/devel/README.md).
{{% /capture %}}
content/en/docs/concepts/extend-kubernetes/service-catalog.md
+8 -7
View File
@@ -2,11 +2,11 @@
title: Service Catalog
reviewers:
- chenopis
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}}
A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
@@ -14,10 +14,10 @@ Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple
Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Example use case
An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster.
@@ -222,16 +222,17 @@ The following example describes how to map secret values into application enviro
key: topic
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
* View [svc-cat.io](https://svc-cat.io/docs/).
{{% /capture %}}
content/en/docs/concepts/overview/components.md
+8 -7
View File
@@ -2,14 +2,14 @@
reviewers:
- lavalamp
title: Kubernetes Components
content_template: templates/concept
content_type: concept
weight: 20
card:
name: concepts
weight: 20
---
{{% capture overview %}}
<!-- overview -->
When you deploy Kubernetes, you get a cluster.
{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
@@ -20,9 +20,9 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
![Components of Kubernetes](/images/docs/components-of-kubernetes.png)
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Control Plane Components
The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
@@ -122,10 +122,11 @@ about containers in a central database, and provides a UI for browsing that data
A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
saving container logs to a central log store with search/browsing interface.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn about [Nodes](/docs/concepts/architecture/nodes/)
* Learn about [Controllers](/docs/concepts/architecture/controller/)
* Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
* Read etcd's official [documentation](https://etcd.io/docs/)
{{% /capture %}}
content/en/docs/concepts/overview/kubernetes-api.md
+11 -11
View File
@@ -2,14 +2,14 @@
reviewers:
- chenopis
title: The Kubernetes API
content_template: templates/concept
content_type: concept
weight: 30
card:
name: concepts
weight: 30
---
{{% capture overview %}}
<!-- overview -->
The core of Kubernetes' {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
is the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. The API server
@@ -21,9 +21,10 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## API changes
@@ -135,10 +136,10 @@ There are several API groups in a cluster:
There are two paths to extending the API with [custom resources](/docs/concepts/api-extension/custom-resources/):
1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)
1. [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)
lets you declaratively define how the API server should provide your chosen resource API.
1. You can also [implement your own extension API server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)
and use the [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)
1. You can also [implement your own extension API server](/docs/tasks/extend-kubernetes/setup-extension-api-server/)
and use the [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
to make it seamless for clients.
## Enabling or disabling API groups
@@ -166,8 +167,9 @@ For example: to enable deployments and daemonsets, set
Kubernetes stores its serialized state in terms of the API resources by writing them into
{{< glossary_tooltip term_id="etcd" >}}.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Controlling API Access](/docs/reference/access-authn-authz/controlling-access/) describes
how the cluster manages authentication and authorization for API access.
@@ -176,5 +178,3 @@ Overall API conventions are described in the
document.
API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
{{% /capture %}}
content/en/docs/concepts/overview/what-is-kubernetes.md
+8 -7
View File
@@ -5,18 +5,18 @@ reviewers:
title: What is Kubernetes?
description: >
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
<!-- overview -->
This page is an overview of Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community.
@@ -86,9 +86,10 @@ Kubernetes:
* Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.
* Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Take a look at the [Kubernetes Components](/docs/concepts/overview/components/)
* Ready to [Get Started](/docs/setup/)?
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/annotations.md
+8 -7
View File
@@ -1,15 +1,15 @@
---
title: Annotations
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
You can use Kubernetes annotations to attach arbitrary non-identifying metadata
to objects. Clients such as tools and libraries can retrieve this metadata.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Attaching metadata to objects
You can use either labels or annotations to attach metadata to Kubernetes
@@ -88,10 +88,11 @@ spec:
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/).
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/common-labels.md
+5 -5
View File
@@ -1,18 +1,18 @@
---
title: Recommended Labels
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
You can visualize and manage Kubernetes objects with more tools than kubectl and
the dashboard. A common set of labels allows tools to work interoperably, describing
objects in a common manner that all tools can understand.
In addition to supporting tooling, the recommended labels describe applications
in a way that can be queried.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
The metadata is organized around the concept of an _application_. Kubernetes is not
a platform as a service (PaaS) and doesn't have or enforce a formal notion of an application.
Instead, applications are informal and described with metadata. The definition of
@@ -170,4 +170,4 @@ metadata:
With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and Wordpress, the broader application, are included.
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: Understanding Kubernetes Objects
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 40
---
{{% capture overview %}}
<!-- overview -->
This page explains how Kubernetes objects are represented in the Kubernetes API, and how you can express them in `.yaml` format.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Understanding Kubernetes objects {#kubernetes-objects}
*Kubernetes objects* are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Specifically, they can describe:
@@ -87,12 +87,13 @@ For example, the `spec` format for a Pod can be found in
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 %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Kubernetes API overview](/docs/reference/using-api/api-overview/) explains some more API concepts
* Learn about the most important basic Kubernetes objects, such as [Pod](/docs/concepts/workloads/pods/pod-overview/).
* Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/labels.md
+5 -5
View File
@@ -2,11 +2,11 @@
reviewers:
- mikedanese
title: Labels and Selectors
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
_Labels_ are key/value pairs that are attached to objects, such as pods.
Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.
@@ -24,10 +24,10 @@ Each object can have a set of key/value labels defined. Each Key must be unique
Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Motivation
@@ -228,4 +228,4 @@ selector:
One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule.
See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information.
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/names.md
+8 -7
View File
@@ -3,11 +3,11 @@ reviewers:
- mikedanese
- thockin
title: Object Names and IDs
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
Each object in your cluster has a [_Name_](#names) that is unique for that type of resource.
Every Kubernetes object also has a [_UID_](#uids) that is unique across your whole cluster.
@@ -16,9 +16,9 @@ For example, you can only have one Pod named `myapp-1234` within the same [names
For non-unique user-provided attributes, Kubernetes provides [labels](/docs/concepts/overview/working-with-objects/labels/) and [annotations](/docs/concepts/overview/working-with-objects/annotations/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Names
@@ -81,8 +81,9 @@ Some resource types have additional restrictions on their names.
Kubernetes UIDs are universally unique identifiers (also known as UUIDs).
UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes.
* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document.
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/namespaces.md
+11 -9
View File
@@ -4,19 +4,19 @@ reviewers:
- mikedanese
- thockin
title: Namespaces
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
Kubernetes supports multiple virtual clusters backed by the same physical cluster.
These virtual clusters are called namespaces.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## When to Use Multiple Namespaces
@@ -58,12 +58,13 @@ kube-public Active 1d
kube-system Active 1d
```
Kubernetes starts with three initial namespaces:
Kubernetes starts with four initial namespaces:
* `default` The default namespace for objects with no other namespace
* `kube-system` The namespace for objects created by the Kubernetes system
* `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
* `kube-node-lease` This namespace for the lease objects associated with each node which improves the performance of the node heartbeats as the cluster scales.
### Setting the namespace for a request
To set the namespace for a current request, use the `--namespace` flag.
@@ -112,11 +113,12 @@ kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace).
* Learn more about [deleting a namespace](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
{{% /capture %}}
content/en/docs/concepts/overview/working-with-objects/object-management.md
+8 -7
View File
@@ -1,17 +1,17 @@
---
title: Kubernetes Object Management
content_template: templates/concept
content_type: concept
weight: 15
---
{{% capture overview %}}
<!-- overview -->
The `kubectl` command-line tool supports several different ways to create and manage
Kubernetes objects. This document provides an overview of the different
approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for
details of managing objects by Kubectl.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Management techniques
@@ -173,9 +173,10 @@ Disadvantages compared to imperative object configuration:
- Declarative object configuration is harder to debug and understand results when they are unexpected.
- Partial updates using diffs create complex merge and patch operations.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/)
@@ -185,4 +186,4 @@ Disadvantages compared to imperative object configuration:
- [Kubectl Book](https://kubectl.docs.kubernetes.io)
- [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{% /capture %}}
content/en/docs/concepts/policy/limit-range.md
+9 -10
View File
@@ -2,20 +2,20 @@
reviewers:
- nelvadas
title: Limit Ranges
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
By default, containers run with unbounded [compute resources](/docs/user-guide/compute-resources) on a Kubernetes cluster.
With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis.
Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
A _LimitRange_ provides constraints that can:
@@ -26,9 +26,7 @@ A _LimitRange_ provides constraints that can:
## Enabling LimitRange
LimitRange support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--enable-admission-plugins=` flag has `LimitRanger` admission controller as
one of its arguments.
LimitRange support has been enabled by default since Kubernetes 1.10.
A LimitRange is enforced in a particular namespace when there is a
LimitRange object in that namespace.
@@ -56,9 +54,10 @@ there may be contention for resources. In this case, the Containers or Pods will
Neither contention nor changes to a LimitRange will affect already created resources.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information.
@@ -72,4 +71,4 @@ For examples on using limits, see:
- a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/).
{{% /capture %}}
content/en/docs/concepts/policy/pod-security-policy.md
+15 -14
View File
@@ -3,21 +3,21 @@ reviewers:
- pweil-
- tallclair
title: Pod Security Policies
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="beta" >}}
Pod Security Policies enable fine-grained authorization of pod creation and
updates.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## What is a Pod Security Policy?
@@ -34,7 +34,7 @@ administrator to control the following:
| Usage of host networking and ports | [`hostNetwork`, `hostPorts`](#host-namespaces) |
| Usage of volume types | [`volumes`](#volumes-and-file-systems) |
| Usage of the host filesystem | [`allowedHostPaths`](#volumes-and-file-systems) |
| White list of FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
| Allow specific FlexVolume drivers | [`allowedFlexVolumes`](#flexvolume-drivers) |
| Allocating an FSGroup that owns the pod's volumes | [`fsGroup`](#volumes-and-file-systems) |
| Requiring the use of a read only root file system | [`readOnlyRootFilesystem`](#volumes-and-file-systems) |
| The user and group IDs of the container | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) |
@@ -401,13 +401,13 @@ namespace. Doing so gives the pod access to the loopback device, services
listening on localhost, and could be used to snoop on network activity of other
pods on the same node.
**HostPorts** - Provides a whitelist of ranges of allowable ports in the host
**HostPorts** - Provides a list of ranges of allowable ports in the host
network namespace. Defined as a list of `HostPortRange`, with `min`(inclusive)
and `max`(inclusive). Defaults to no allowed host ports.
### Volumes and file systems
**Volumes** - Provides a whitelist of allowed volume types. The allowable values
**Volumes** - Provides a list of allowed volume types. The allowable values
correspond to the volume sources that are defined when creating a volume. For
the complete list of volume types, see [Types of
Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*`
@@ -438,7 +438,7 @@ minimum value of the first range as the default. Validates against all ranges.
all ranges if `FSGroups` is set.
- *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.
**AllowedHostPaths** - This specifies a whitelist of host paths that are allowed
**AllowedHostPaths** - This specifies a list of host paths that are allowed
to be used by hostPath volumes. An empty list means there is no restriction on
host paths used. This is defined as a list of objects with a single `pathPrefix`
field, which allows hostPath volumes to mount a path that begins with an
@@ -469,7 +469,7 @@ root filesystem (i.e. no writable layer).
### FlexVolume drivers
This specifies a whitelist of FlexVolume drivers that are allowed to be used
This specifies a list of FlexVolume drivers that are allowed to be used
by flexvolume. An empty list or nil means there is no restriction on the drivers.
Please make sure [`volumes`](#volumes-and-file-systems) field contains the
`flexVolume` volume type; no FlexVolume driver is allowed otherwise.
@@ -555,7 +555,7 @@ the PodSecurityPolicy. For more details on Linux capabilities, see
The following fields take a list of capabilities, specified as the capability
name in ALL_CAPS without the `CAP_` prefix.
**AllowedCapabilities** - Provides a whitelist of capabilities that may be added
**AllowedCapabilities** - Provides a list of capabilities that are allowed to be added
to a container. The default set of capabilities are implicitly allowed. The
empty set means that no additional capabilities may be added beyond the default
set. `*` can be used to allow all capabilities.
@@ -579,7 +579,7 @@ specified.
### AllowedProcMountTypes
`allowedProcMountTypes` is a whitelist of allowed ProcMountTypes.
`allowedProcMountTypes` is a list of allowed ProcMountTypes.
Empty or nil indicates that only the `DefaultProcMountType` may be used.
`DefaultProcMount` uses the container runtime defaults for readonly and masked
@@ -631,12 +631,13 @@ By default, all safe sysctls are allowed.
Refer to the [Sysctl documentation](
/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations.
Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
{{% /capture %}}
content/en/docs/concepts/policy/resource-quotas.md
+8 -7
View File
@@ -2,21 +2,21 @@
reviewers:
- derekwaynecarr
title: Resource Quotas
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
When several users or teams share a cluster with a fixed number of nodes,
there is a concern that one team could use more than its fair share of resources.
Resource quotas are a tool for administrators to address this concern.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
A resource quota, defined by a `ResourceQuota` object, provides constraints that limit
aggregate resource consumption per namespace. It can limit the quantity of objects that can
@@ -595,10 +595,11 @@ See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) and
See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
+10 -11
View File
@@ -4,12 +4,12 @@ reviewers:
- kevin-wangzefeng
- bsalamat
title: Assigning Pods to Nodes
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
{{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes.
@@ -21,9 +21,9 @@ but there are some circumstances where you may want more control on a node where
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
services that communicate a lot into the same availability zone.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## nodeSelector
@@ -213,10 +213,8 @@ as at least one already-running pod that has a label with key "security" and val
on node N if node N has a label with key `failure-domain.beta.kubernetes.io/zone` and some value V
such that there is at least one node in the cluster with key `failure-domain.beta.kubernetes.io/zone` and
value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
rule says that the pod prefers not to be scheduled onto a node if that node is already running a pod with label
having key "security" and value "S2". (If the `topologyKey` were `failure-domain.beta.kubernetes.io/zone` then
it would mean that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
label having key "security" and value "S2".) See the
rule says that the pod cannot be scheduled onto a node if that node is in the same zone as a pod with
label having key "security" and value "S2". See the
[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
@@ -388,9 +386,10 @@ spec:
The above pod will run on the node kube-01.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
@@ -402,4 +401,4 @@ Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-lo
The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can take part in node-level
resource allocation decisions.
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/kube-scheduler.md
+8 -7
View File
@@ -1,18 +1,18 @@
---
title: Kubernetes Scheduler
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
In Kubernetes, _scheduling_ refers to making sure that {{< glossary_tooltip text="Pods" term_id="pod" >}}
are matched to {{< glossary_tooltip text="Nodes" term_id="node" >}} so that
{{< glossary_tooltip term_id="kubelet" >}} can run them.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Scheduling overview {#scheduling}
@@ -86,12 +86,13 @@ of the scheduler:
`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You
can also configure the kube-scheduler to run different profiles.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/)
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+5 -5
View File
@@ -2,11 +2,11 @@
reviewers:
- bsalamat
title: Scheduler Performance Tuning
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.14" state="beta" >}}
@@ -24,9 +24,9 @@ in a process called _Binding_.
This page explains performance tuning optimizations that are relevant for
large Kubernetes clusters.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
In large clusters, you can tune the scheduler's behaviour balancing
scheduling outcomes between latency (new Pods are placed quickly) and
@@ -164,4 +164,4 @@ Node 1, Node 5, Node 2, Node 6, Node 3, Node 4
After going over all the Nodes, it goes back to Node 1.
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
+4 -5
View File
@@ -2,11 +2,11 @@
reviewers:
- ahg-g
title: Scheduling Framework
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
@@ -20,9 +20,9 @@ framework.
[kep]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md
{{% /capture %}}
{{% capture body %}}
<!-- body -->
# Framework workflow
@@ -239,4 +239,3 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a
a scheduler profile and then define multiple profiles to fit various kinds of workload.
Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles).
{{% /capture %}}
content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
+9 -8
View File
@@ -4,12 +4,12 @@ reviewers:
- kevin-wangzefeng
- bsalamat
title: Taints and Tolerations
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
@@ -22,9 +22,9 @@ Taints and tolerations work together to ensure that pods are not scheduled
onto inappropriate nodes. One or more taints are applied to a node; this
marks that the node should not accept any pods that do not tolerate the taints.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Concepts
@@ -250,7 +250,7 @@ tolerations:
Kubernetes automatically adds a toleration for
`node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`
with `tolerationSeconds=300`,
unless you, or a controller, set those tolerations explictly.
unless you, or a controller, set those tolerations explicitly.
These automatically-added tolerations mean that Pods remain bound to
Nodes for 5 minutes after one of these problems is detected.
@@ -282,9 +282,10 @@ tolerations to all daemons, to prevent DaemonSets from breaking.
Adding these tolerations ensures backward compatibility. You can also add
arbitrary tolerations to DaemonSets.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it
* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/)
{{% /capture %}}
content/en/docs/concepts/security/overview.md
+79 -89
View File
@@ -2,60 +2,54 @@
reviewers:
- zparnold
title: Overview of Cloud Native Security
content_template: templates/concept
weight: 1
content_type: concept
weight: 10
---
{{< toc >}}
<!-- overview -->
{{% capture overview %}}
Kubernetes Security (and security in general) is an immense topic that has many
highly interrelated parts. In today's era where open source software is
integrated into many of the systems that help web applications run,
there are some overarching concepts that can help guide your intuition about how you can
think about security holistically. This guide will define a mental model
for some general concepts surrounding Cloud Native Security. The mental model is completely arbitrary
and you should only use it if it helps you think about where to secure your software
stack.
{{% /capture %}}
This overview defines a model for thinking about Kubernetes security in the context of Cloud Native security.
{{% capture body %}}
{{< warning >}}
This container security model provides suggestions, not proven information security policies.
{{< /warning >}}
<!-- body -->
## The 4C's of Cloud Native security
You can think about security in layers. The 4C's of Cloud Native security are Cloud,
Clusters, Containers, and Code.
## The 4C's of Cloud Native Security
Let's start with a diagram that may help you understand how you can think about security in layers.
{{< note >}}
This layered approach augments the [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))
approach to security, which is widely regarded as a best practice for securing
software systems. The 4C's are Cloud, Clusters, Containers, and Code.
computing approach to security, which is widely regarded as a best practice for securing
software systems.
{{< /note >}}
{{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" >}}
As you can see from the above figure,
each one of the 4C's depend on the security of the squares in which they fit. It
is nearly impossibly to safeguard against poor security standards in Cloud, Containers, and Code
by only addressing security at the code level. However, when these areas are dealt
with appropriately, then adding security to your code augments an already strong
base. These areas of concern will now be described in more detail below.
Each layer of the Cloud Native security model builds upon the next outermost layer.
The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
You cannot safeguard against poor security standards in the base layers by addressing
security at the Code level.
## Cloud
In many ways, the Cloud (or co-located servers, or the corporate datacenter) is the
[trusted computing base](https://en.wikipedia.org/wiki/Trusted_computing_base)
of a Kubernetes cluster. If these components themselves are vulnerable (or
configured in a vulnerable way) then there's no real way to guarantee the security
of any components built on top of this base. Each cloud provider has extensive
security recommendations they make to their customers on how to run workloads securely
in their environment. It is out of the scope of this guide to give recommendations
on cloud security since every cloud provider and workload is different. Here are some
links to some of the popular cloud providers' documentation
for security as well as give general guidance for securing the infrastructure that
makes up a Kubernetes cluster.
of a Kubernetes cluster. If the Cloud layer is vulnerable (or
configured in a vulnerable way) then there is no guarantee that the components built
on top of this base are secure. Each cloud provider makes security recommendations
for running workloads securely in their environment.
### Cloud Provider Security Table
### Cloud provider security
If you are running a Kubernetes cluster on your own hardware or a different cloud provider,
consult your documentation for security best practices.
Here are links to some of the popular cloud providers' security documentation:
{{< table caption="Cloud provider security" >}}
IaaS Provider | Link |
-------------------- | ------------ |
@@ -66,46 +60,48 @@ IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
{{< /table >}}
If you are running on your own hardware or a different cloud provider you will need to
consult your documentation for security best practices.
### Infrastructure security {#infrastructure-security}
### General Infrastructure Guidance Table
Suggestions for securing your infrastructure in a Kubernetes cluster:
{{< table caption="Infrastructure security" >}}
Area of Concern for Kubernetes Infrastructure | Recommendation |
--------------------------------------------- | ------------ |
Network access to API Server (Masters) | Ideally all access to the Kubernetes Masters is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
Kubernetes access to Cloud Provider API | Each cloud provider will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security
--------------------------------------------- | -------------- |
Network access to API Server (Control plane) | All access to the Kubernetes control plane is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.|
Network access to Nodes (nodes) | Nodes should be configured to _only_ accept connections (via network access control lists)from the control plane on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely.
Kubernetes access to Cloud Provider API | Each cloud provider needs to grant a different set of permissions to the Kubernetes control plane and nodes. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. The [Kops documentation](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles) provides information about IAM policies and roles.
Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the control plane only. Depending on your configuration, you should attempt to use etcd over TLS. More information can be found in the [etcd documentation](https://github.com/etcd-io/etcd/tree/master/Documentation).
etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest.
{{< /table >}}
## Cluster
This section will provide links for securing
workloads in Kubernetes. There are two areas of concern for securing
Kubernetes:
There are two areas of concern for securing Kubernetes:
* Securing the components that are configurable which make up the cluster
* Securing the components which run in the cluster
* Securing the cluster components that are configurable
* Securing the applications which run in the cluster
### Components of the Cluster {#cluster-components}
### Components _of_ the Cluster
If you want to protect your cluster from accidental or malicious access, and adopt
If you want to protect your cluster from accidental or malicious access and adopt
good information practices, read and follow the advice about
[securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/).
### Components _in_ the Cluster (your application)
### Components in the cluster (your application) {#cluster-applications}
Depending on the attack surface of your application, you may want to focus on specific
aspects of security. For example, if you are running a service (Service A) that is critical
aspects of security. For example: If you are running a service (Service A) that is critical
in a chain of other resources and a separate workload (Service B) which is
vulnerable to a resource exhaustion attack, by not putting resource limits on
Service B you run the risk of also compromising Service A. Below is a table of
links of things to consider when securing workloads running in Kubernetes.
vulnerable to a resource exhaustion attack then the risk of compromising Service A
is high if you do not limit the resources of Service B. The following table lists
areas of security concerns and recommendations for securing workloads running in Kubernetes:
Area of Concern for Workload Security | Recommendation |
------------------------------ | ------------ |
------------------------------ | --------------------- |
RBAC Authorization (Access to the Kubernetes API) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Authentication | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
Application secrets management (and encrypting them in etcd at rest) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
@@ -114,51 +110,45 @@ Quality of Service (and Cluster resource management) | https://kubernetes.io/doc
Network Policies | https://kubernetes.io/docs/concepts/services-networking/network-policies/
TLS For Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
## Container
In order to run software in Kubernetes, it must be in a container. Because of this,
there are certain security considerations that must be taken into account in order
to benefit from the workload security primitives of Kubernetes. Container security
is also outside the scope of this guide, but here is a table of general
recommendations and links for further exploration of this topic.
Container security is outside the scope of this guide. Here are general recommendations and
links to explore this topic:
Area of Concern for Containers | Recommendation |
------------------------------ | ------------ |
Container Vulnerability Scanning and OS Dependency Security | As part of an image build step or on a regular basis you should scan your containers for known vulnerabilities with a tool such as [CoreOS's Clair](https://github.com/coreos/clair/)
Image Signing and Enforcement | Two other CNCF Projects (TUF and Notary) are useful tools for signing container images and maintaining a system of trust for the content of your containers. If you use Docker, it is built in to the Docker Engine as [Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/). On the enforcement piece, [IBM's Portieris](https://github.com/IBM/portieris) project is a tool that runs as a Kubernetes Dynamic Admission Controller to ensure that images are properly signed via Notary before being admitted to the Cluster.
------------------------------ | -------------- |
Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
## Code
Finally moving down into the application code level, this is one of the primary attack
surfaces over which you have the most control. This is also outside of the scope
of Kubernetes but here are a few recommendations:
Application code is one of the primary attack surfaces over which you have the most control.
While securing application code is outside of the Kubernetes security topic, here
are recommendations to protect application code:
### General Code Security Guidance Table
### Code security
{{< table caption="Code security" >}}
Area of Concern for Code | Recommendation |
--------------------------------------------- | ------------ |
Access over TLS only | If your code needs to communicate via TCP, ideally it would be performing a TLS handshake with the client ahead of time. With the exception of a few cases, the default behavior should be to encrypt everything in transit. Going one step further, even "behind the firewall" in our VPC's it's still a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. There are numerous tools that can be used to accomplish this in Kubernetes such as [Linkerd](https://linkerd.io/) and [Istio](https://istio.io/). |
-------------------------| -------------- |
Access over TLS only | If your code needs to communicate by TCP, perform a TLS handshake with the client ahead of time. With the exception of a few cases, encrypt everything in transit. Going one step further, it's a good idea to encrypt network traffic between services. This can be done through a process known as mutual or [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) which performs a two sided verification of communication between two certificate holding services. |
Limiting port ranges of communication | This recommendation may be a bit self-explanatory, but wherever possible you should only expose the ports on your service that are absolutely essential for communication or metric gathering. |
3rd Party Dependency Security | Since our applications tend to have dependencies outside of our own codebases, it is a good practice to regularly scan the code's dependencies to ensure that they are still secure with no vulnerabilities currently filed against them. Each language has a tool for performing this check automatically. |
Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found here: https://owasp.org/www-community/Source_Code_Analysis_Tools |
Dynamic probing attacks | There are a few automated tools that are able to be run against your service to try some of the well known attacks that commonly befall services. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the OWASP Zed Attack proxy https://owasp.org/www-project-zap/ |
3rd Party Dependency Security | It is a good practice to regularly scan your application's third party libraries for known security vulnerabilities. Each programming language has a tool for performing this check automatically. |
Static Code Analysis | Most languages provide a way for a snippet of code to be analyzed for any potentially unsafe coding practices. Whenever possible you should perform checks using automated tooling that can scan codebases for common security errors. Some of the tools can be found at: https://owasp.org/www-community/Source_Code_Analysis_Tools |
Dynamic probing attacks | There are a few automated tools that you can run against your service to try some of the well known service attacks. These include SQL injection, CSRF, and XSS. One of the most popular dynamic analysis tools is the [OWASP Zed Attack proxy](https://owasp.org/www-project-zap/) tool. |
{{< /table >}}
## Robust automation
## {{% heading "whatsnext" %}}
Most of the above mentioned suggestions can actually be automated in your code
delivery pipeline as part of a series of checks in security. To learn about a
more "Continuous Hacking" approach to software delivery, [this article](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/) provides more detail.
Learn about related Kubernetes security topics:
{{% /capture %}}
{{% capture whatsnext %}}
* Read about [network policies for Pods](/docs/concepts/services-networking/network-policies/)
* Read about [securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
* Read about [API access control](/docs/reference/access-authn-authz/controlling-access/)
* Read about [data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* Read about [data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
* Read about [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
{{% /capture %}}
* [Pod security standards](/docs/concepts/security/pod-security-standards/)
* [Network policies for Pods](/docs/concepts/services-networking/network-policies/)
* [Securing your cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
* [API access control](/docs/reference/access-authn-authz/controlling-access/)
* [Data encryption in transit](/docs/tasks/tls/managing-tls-in-a-cluster/) for the control plane
* [Data encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
* [Secrets in Kubernetes](/docs/concepts/configuration/secret/)
content/en/docs/concepts/security/pod-security-standards.md
+13 -13
View File
@@ -2,11 +2,11 @@
reviewers:
- tallclair
title: Pod Security Standards
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
Security settings for Pods are typically applied by using [security
contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the
@@ -21,9 +21,9 @@ However, numerous means of policy enforcement have arisen that augment or replac
PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled
from any specific instantiation.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Policy Types
@@ -43,9 +43,9 @@ should range from highly restricted to highly flexible:
The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically
aimed at system- and infrastructure-level workloads managed by privileged, trusted users.
The privileged policy is defined by an absence of restrictions. For blacklist-oriented enforcement
The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement
mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints
rather than an instantiated policy. In contrast, for a whitelist oriented mechanism (such as Pod
rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod
Security Policy) the privileged policy should enable all controls (disable all restrictions).
### Baseline/Default
@@ -90,7 +90,7 @@ enforced/disallowed:
<br><b>Restricted Fields:</b><br>
spec.containers[*].securityContext.capabilities.add<br>
spec.initContainers[*].securityContext.capabilities.add<br>
<br><b>Allowed Values:</b> empty (optionally whitelisted defaults)<br>
<br><b>Allowed Values:</b> empty (or restricted to a known list)<br>
</td>
</tr>
<tr>
@@ -105,17 +105,17 @@ enforced/disallowed:
<tr>
<td>Host Ports</td>
<td>
HostPorts should be disallowed, or at minimum restricted to a whitelist.<br>
HostPorts should be disallowed, or at minimum restricted to a known list.<br>
<br><b>Restricted Fields:</b><br>
spec.containers[*].ports[*].hostPort<br>
spec.initContainers[*].ports[*].hostPort<br>
<br><b>Allowed Values:</b> 0, undefined, (whitelisted)<br>
<br><b>Allowed Values:</b> 0, undefined (or restricted to a known list)<br>
</td>
</tr>
<tr>
<td>AppArmor <em>(optional)</em></td>
<td>
On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to a whitelisted set of profiles.<br>
On supported hosts, the 'runtime/default' AppArmor profile is applied by default. The default policy should prevent overriding or disabling the policy, or restrict overrides to an allowed set of profiles.<br>
<br><b>Restricted Fields:</b><br>
metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']<br>
<br><b>Allowed Values:</b> 'runtime/default', undefined<br>
@@ -145,7 +145,7 @@ enforced/disallowed:
<tr>
<td>Sysctls</td>
<td>
Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for a whitelisted "safe" subset.
Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset.
A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.<br>
<br><b>Restricted Fields:</b><br>
spec.securityContext.sysctls<br>
@@ -249,7 +249,7 @@ well as lower-trust users.The following listed controls should be enforced/disal
<tr>
<td>Seccomp</td>
<td>
The 'runtime/default' seccomp profile must be required, or allow additional whitelisted values.<br>
The 'runtime/default' seccomp profile must be required, or allow specific additional profiles.<br>
<br><b>Restricted Fields:</b><br>
metadata.annotations['seccomp.security.alpha.kubernetes.io/pod']<br>
metadata.annotations['container.seccomp.security.alpha.kubernetes.io/*']<br>
@@ -322,4 +322,4 @@ kernel. This allows for workloads requiring heightened permissions to still be i
Additionally, the protection of sandboxed workloads is highly dependent on the method of
sandboxing. As such, no single ‘recommended’ policy is recommended for all sandboxed workloads.
{{% /capture %}}
content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md
+33 -32
View File
@@ -3,29 +3,30 @@ reviewers:
- rickypai
- thockin
title: Adding entries to Pod /etc/hosts with HostAliases
content_template: templates/concept
content_type: concept
weight: 60
min-kubernetes-server-version: 1.7
---
{{< toc >}}
{{% capture overview %}}
Adding entries to a Pod's /etc/hosts file provides Pod-level override of hostname resolution when DNS and other options are not applicable. In 1.7, users can add these custom entries with the HostAliases field in PodSpec.
<!-- overview -->
Modification not using HostAliases is not suggested because the file is managed by Kubelet and can be overwritten on during Pod creation/restart.
{{% /capture %}}
Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostname resolution when DNS and other options are not applicable. You can add these custom entries with the HostAliases field in PodSpec.
{{% capture body %}}
Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart.
## Default Hosts File Content
Let's start an Nginx Pod which is assigned a Pod IP:
<!-- body -->
## Default hosts file content
Start an Nginx Pod which is assigned a Pod IP:
```shell
kubectl run nginx --image nginx --generator=run-pod/v1
```
```shell
```
pod/nginx created
```
@@ -35,7 +36,7 @@ Examine a Pod IP:
kubectl get pods --output=wide
```
```shell
```
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
```
@@ -46,7 +47,7 @@ The hosts file content would look like this:
kubectl exec nginx -- cat /etc/hosts
```
```none
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -60,43 +61,44 @@ fe00::2 ip6-allrouters
By default, the `hosts` file only includes IPv4 and IPv6 boilerplates like
`localhost` and its own hostname.
## Adding Additional Entries with HostAliases
## Adding additional entries with hostAliases
In addition to the default boilerplate, we can add additional entries to the
`hosts` file to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
`bar.remote` to `10.1.2.3`, we can by adding HostAliases to the Pod under
In addition to the default boilerplate, you can add additional entries to the
`hosts` file.
For example: to resolve `foo.local`, `bar.local` to `127.0.0.1` and `foo.remote`,
`bar.remote` to `10.1.2.3`, you can configure HostAliases for a Pod under
`.spec.hostAliases`:
{{< codenew file="service/networking/hostaliases-pod.yaml" >}}
This Pod can be started with the following commands:
Yoyu can start a Pod with that configuration by running:
```shell
kubectl apply -f hostaliases-pod.yaml
kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml
```
```shell
```
pod/hostaliases-pod created
```
Examine a Pod IP and status:
Examine a Pod's details to see its IPv4 address and its status:
```shell
kubectl get pod --output=wide
```
```shell
```
NAME READY STATUS RESTARTS AGE IP NODE
hostaliases-pod 0/1 Completed 0 6s 10.200.0.5 worker0
```
The `hosts` file content would look like this:
The `hosts` file content looks like this:
```shell
kubectl logs hostaliases-pod
```
```none
```
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -111,19 +113,18 @@ fe00::2 ip6-allrouters
10.1.2.3 foo.remote bar.remote
```
With the additional entries specified at the bottom.
with the additional entries specified at the bottom.
## Why Does Kubelet Manage the Hosts File?
## Why does the kubelet manage the hosts file? {#why-does-kubelet-manage-the-hosts-file}
Kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
The kubelet [manages](https://github.com/kubernetes/kubernetes/issues/14633) the
`hosts` file for each container of the Pod to prevent Docker from
[modifying](https://github.com/moby/moby/issues/17190) the file after the
containers have already been started.
Because of the managed-nature of the file, any user-written content will be
overwritten whenever the `hosts` file is remounted by Kubelet in the event of
a container restart or a Pod reschedule. Thus, it is not suggested to modify
the contents of the file.
{{% /capture %}}
{{< caution >}}
Avoid making manual changes to the hosts file inside a container.
If you make manual changes to the hosts file,
those changes are lost when the container exits.
{{< /caution >}}
content/en/docs/concepts/services-networking/connect-applications-service.md
+10 -9
View File
@@ -4,12 +4,12 @@ reviewers:
- lavalamp
- thockin
title: Connecting Applications with Services
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
## The Kubernetes model for connecting containers
@@ -21,9 +21,9 @@ Coordinating port allocations across multiple developers or teams that provide c
This guide uses a simple nginx server to demonstrate proof of concept.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Exposing pods to the cluster
@@ -394,8 +394,8 @@ kubectl edit svc my-nginx
kubectl get svc my-nginx
```
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s
```
```
curl https://<EXTERNAL-IP> -k
@@ -418,12 +418,13 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
...
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Using a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
* Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/)
* Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
{{% /capture %}}
content/en/docs/concepts/services-networking/dns-pod-service.md
+14 -7
View File
@@ -3,14 +3,14 @@ reviewers:
- davidopp
- thockin
title: DNS for Services and Pods
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of DNS support by Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -66,6 +66,13 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`
## Pods
### A/AAAA records
Any pods created by a Deployment or DaemonSet have the following
DNS resolution available:
`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.`
### Pod's hostname and subdomain fields
Currently when a pod is created, its hostname is the Pod's `metadata.name` value.
@@ -262,11 +269,11 @@ The availability of Pod DNS Config and DNS Policy "`None`" is shown as below.
| 1.10 | Beta (on by default)|
| 1.9 | Alpha |
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
For guidance on administering DNS configurations, check
[Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/)
{{% /capture %}}
content/en/docs/concepts/services-networking/dual-stack.md
+8 -7
View File
@@ -9,11 +9,11 @@ feature:
description: >
Allocation of IPv4 and IPv6 addresses to Pods and Services
content_template: templates/concept
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
@@ -21,9 +21,9 @@ weight: 70
If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Supported Features
@@ -103,10 +103,11 @@ The use of publicly routable and non-publicly routable IPv6 address blocks is ac
* Kubenet forces IPv4,IPv6 positional reporting of IPs (--cluster-cidr)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
{{% /capture %}}
content/en/docs/concepts/services-networking/endpoint-slices.md
+8 -7
View File
@@ -2,12 +2,12 @@
reviewers:
- freehan
title: EndpointSlices
content_template: templates/concept
content_type: concept
weight: 15
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
@@ -15,9 +15,9 @@ _EndpointSlices_ provide a simple way to track network endpoints within a
Kubernetes cluster. They offer a more scalable and extensible alternative to
Endpoints.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Motivation
@@ -175,11 +175,12 @@ necessary soon anyway. Rolling updates of Deployments also provide a natural
repacking of EndpointSlices with all pods and their corresponding endpoints
getting replaced.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
content/en/docs/concepts/services-networking/ingress-controllers.md
+8 -7
View File
@@ -1,11 +1,11 @@
---
title: Ingress Controllers
reviewers:
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
In order for the Ingress resource to work, the cluster must have an ingress controller running.
@@ -16,9 +16,9 @@ that best fits your cluster.
Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and
[nginx](https://git.k8s.io/ingress-nginx/README.md) controllers.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Additional controllers
@@ -64,11 +64,12 @@ controllers operate slightly differently.
Make sure you review your ingress controller's documentation to understand the caveats of choosing it.
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Ingress](/docs/concepts/services-networking/ingress/).
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube).
{{% /capture %}}
content/en/docs/concepts/services-networking/ingress.md
+8 -7
View File
@@ -2,16 +2,16 @@
reviewers:
- bprashanth
title: Ingress
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.1" state="beta" >}}
{{< glossary_definition term_id="ingress" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Terminology
@@ -542,10 +542,11 @@ You can expose a Service in multiple ways that don't directly involve the Ingres
* Use [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)
* Use [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn about the [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)
* Learn about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube)
{{% /capture %}}
content/en/docs/concepts/services-networking/network-policies.md
+10 -9
View File
@@ -4,20 +4,20 @@ reviewers:
- caseydavenport
- danwinship
title: Network Policies
content_template: templates/concept
content_type: concept
weight: 50
---
{{< toc >}}
{{% capture overview %}}
<!-- overview -->
A network policy is a specification of how groups of {{< glossary_tooltip text="pods" term_id="pod">}} are allowed to communicate with each other and other network endpoints.
NetworkPolicy resources use {{< glossary_tooltip text="labels" term_id="label">}} to select pods and define rules which specify what traffic is allowed to the selected pods.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Prerequisites
Network policies are implemented by the [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect.
@@ -89,9 +89,9 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g
__policyTypes__: Each NetworkPolicy includes a `policyTypes` list which may include either `Ingress`, `Egress`, or both. The `policyTypes` field indicates whether or not the given policy applies to ingress traffic to selected pod, egress traffic from selected pods, or both. If no `policyTypes` are specified on a NetworkPolicy then by default `Ingress` will always be set and `Egress` will be set if the NetworkPolicy has any egress rules.
__ingress__: Each NetworkPolicy may include a list of whitelist `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
__ingress__: Each NetworkPolicy may include a list of allowed `ingress` rules. Each rule allows traffic which matches both the `from` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port, from one of three sources, the first specified via an `ipBlock`, the second via a `namespaceSelector` and the third via a `podSelector`.
__egress__: Each NetworkPolicy may include a list of whitelist `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
__egress__: Each NetworkPolicy may include a list of allowed `egress` rules. Each rule allows traffic which matches both the `to` and `ports` sections. The example policy contains a single rule, which matches traffic on a single port to any destination in `10.0.0.0/24`.
So, the example NetworkPolicy:
@@ -215,12 +215,13 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha
{{< /note >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
- See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/)
walkthrough for further examples.
- See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource.
{{% /capture %}}
content/en/docs/concepts/services-networking/service-topology.md
+8 -7
View File
@@ -8,12 +8,12 @@ feature:
description: >
Routing of service traffic based upon cluster topology.
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
@@ -22,9 +22,9 @@ topology of the cluster. For example, a service can specify that traffic be
preferentially routed to endpoints that are on the same Node as the client, or
in the same availability zone.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -192,11 +192,12 @@ spec:
```
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology)
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
{{% /capture %}}
content/en/docs/concepts/services-networking/service.md
+8 -7
View File
@@ -7,12 +7,12 @@ feature:
description: >
No need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
{{< glossary_definition term_id="service" length="short" >}}
@@ -20,9 +20,9 @@ With Kubernetes you don't need to modify your application to use an unfamiliar s
Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods,
and can load-balance across them.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Motivation
@@ -1227,12 +1227,13 @@ SCTP is not supported on Windows based nodes.
The kube-proxy does not support the management of SCTP associations when it is in userspace mode.
{{< /warning >}}
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)
* Read about [Ingress](/docs/concepts/services-networking/ingress/)
* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)
{{% /capture %}}
content/en/docs/concepts/storage/dynamic-provisioning.md
+5 -5
View File
@@ -5,11 +5,11 @@ reviewers:
- thockin
- msau42
title: Dynamic Volume Provisioning
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
Dynamic volume provisioning allows storage volumes to be created on-demand.
Without dynamic provisioning, cluster administrators have to manually make
@@ -19,10 +19,10 @@ to represent them in Kubernetes. The dynamic provisioning feature eliminates
the need for cluster administrators to pre-provision storage. Instead, it
automatically provisions storage when it is requested by users.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Background
@@ -133,4 +133,4 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
{{% /capture %}}
content/en/docs/concepts/storage/persistent-volumes.md
+7 -7
View File
@@ -11,18 +11,18 @@ feature:
description: >
Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as <a href="https://cloud.google.com/storage/">GCP</a> or <a href="https://aws.amazon.com/products/storage/">AWS</a>, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This document describes the current state of _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -746,8 +746,9 @@ and need persistent storage, it is recommended that you use the following patter
dynamic storage support (in which case the user should create a matching PV)
or the cluster has no storage system (in which case the user cannot deploy
config requiring PVCs).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
@@ -759,4 +760,3 @@ and need persistent storage, it is recommended that you use the following patter
* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core)
* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core)
{{% /capture %}}
content/en/docs/concepts/storage/storage-classes.md
+5 -5
View File
@@ -5,19 +5,19 @@ reviewers:
- thockin
- msau42
title: Storage Classes
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This document describes the concept of a StorageClass in Kubernetes. Familiarity
with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -821,4 +821,4 @@ Delaying volume binding allows the scheduler to consider all of a Pod's
scheduling constraints when choosing an appropriate PersistentVolume for a
PersistentVolumeClaim.
{{% /capture %}}
content/en/docs/concepts/storage/storage-limits.md
+5 -5
View File
@@ -5,10 +5,10 @@ reviewers:
- thockin
- msau42
title: Node-specific Volume Limits
content_template: templates/concept
content_type: concept
---
{{% capture overview %}}
<!-- overview -->
This page describes the maximum number of volumes that can be attached
to a Node for various cloud providers.
@@ -18,9 +18,9 @@ how many volumes can be attached to a Node. It is important for Kubernetes to
respect those limits. Otherwise, Pods scheduled on a Node could get stuck
waiting for volumes to attach.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Kubernetes default limits
@@ -78,4 +78,4 @@ Refer to the [CSI specifications](https://github.com/container-storage-interface
* For volumes managed by in-tree plugins that have been migrated to a CSI driver, the maximum number of volumes will be the one reported by the CSI driver.
{{% /capture %}}
content/en/docs/concepts/storage/volume-pvc-datasource.md
+5 -5
View File
@@ -5,18 +5,18 @@ reviewers:
- thockin
- msau42
title: CSI Volume Cloning
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -70,4 +70,4 @@ The result is a new PVC with the name `clone-of-pvc-1` that has the exact same c
Upon availability of the new PVC, the cloned PVC is consumed the same as other PVC. It's also expected at this point that the newly created PVC is an independent object. It can be consumed, cloned, snapshotted, or deleted independently and without consideration for it's original dataSource PVC. This also implies that the source is not linked in any way to the newly created clone, it may also be modified or deleted without affecting the newly created clone.
{{% /capture %}}
content/en/docs/concepts/storage/volume-snapshot-classes.md
+5 -5
View File
@@ -7,20 +7,20 @@ reviewers:
- xing-yang
- yuxiangqian
title: Volume Snapshot Classes
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
This document describes the concept of `VolumeSnapshotClass` in Kubernetes. Familiarity
with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
[storage classes](/docs/concepts/storage/storage-classes) is suggested.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -69,4 +69,4 @@ Volume snapshot classes have parameters that describe volume snapshots belonging
the volume snapshot class. Different parameters may be accepted depending on the
`driver`.
{{% /capture %}}
content/en/docs/concepts/storage/volume-snapshots.md
+5 -5
View File
@@ -7,19 +7,19 @@ reviewers:
- xing-yang
- yuxiangqian
title: Volume Snapshots
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.17" state="beta" >}}
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Introduction
@@ -154,4 +154,4 @@ the *dataSource* field in the `PersistentVolumeClaim` object.
For more details, see
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
{{% /capture %}}
content/en/docs/concepts/storage/volumes.md
+8 -7
View File
@@ -5,11 +5,11 @@ reviewers:
- thockin
- msau42
title: Volumes
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
On-disk files in a Container are ephemeral, which presents some problems for
non-trivial applications when running in Containers. First, when a Container
@@ -20,15 +20,15 @@ Kubernetes `Volume` abstraction solves both of these problems.
Familiarity with [Pods](/docs/user-guide/pods) is suggested.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Background
Docker also has a concept of
[volumes](https://docs.docker.com/engine/admin/volumes/), though it is
[volumes](https://docs.docker.com/storage/), though it is
somewhat looser and less managed. In Docker, a volume is simply a directory on
disk or in another Container. Lifetimes are not managed and until very
recently there were only local-disk-backed volumes. Docker now provides volume
@@ -1480,6 +1480,7 @@ sudo systemctl restart docker
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/cron-jobs.md
+9 -8
View File
@@ -4,11 +4,11 @@ reviewers:
- soltysh
- janetkuo
title: CronJob
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.8" state="beta" >}}
@@ -33,8 +33,8 @@ append 11 characters to the job name provided and there is a constraint that the
maximum length of a Job name is no more than 63 characters.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## CronJob
@@ -82,12 +82,13 @@ be down for the same period as the previous example (`08:29:00` to `10:21:00`,)
The CronJob is only responsible for creating Jobs that match its schedule, and
the Job in turn is responsible for the management of the Pods it represents.
{{% /capture %}}
{{% capture whatsnext %}}
[Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)
## {{% heading "whatsnext" %}}
[Cron expression format](https://en.wikipedia.org/wiki/Cron)
documents the format of CronJob `schedule` fields.
For instructions on creating and working with cron jobs, and for an example of CronJob
manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/daemonset.md
+5 -5
View File
@@ -6,11 +6,11 @@ reviewers:
- janetkuo
- kow3ns
title: DaemonSet
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
A _DaemonSet_ ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the
cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage
@@ -26,10 +26,10 @@ In a simple case, one DaemonSet, covering all nodes, would be used for each type
A more complex setup might use multiple DaemonSets for a single type of daemon, but with
different flags and/or different memory and cpu requests for different hardware types.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Writing a DaemonSet Spec
@@ -229,4 +229,4 @@ number of replicas and rolling out updates are more important than controlling e
the Pod runs on. Use a DaemonSet when it is important that a copy of a Pod always run on
all or certain hosts, and when it needs to start before other Pods.
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/deployment.md
+5 -5
View File
@@ -7,11 +7,11 @@ feature:
description: >
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_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
A _Deployment_ provides declarative updates for [Pods](/docs/concepts/workloads/pods/pod/) and
[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/).
@@ -22,10 +22,10 @@ You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_
Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
{{< /note >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Use Case
@@ -1166,4 +1166,4 @@ a paused Deployment and one that is not paused, is that any changes into the Pod
Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
it is created.
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/garbage-collection.md
+6 -13
View File
@@ -1,18 +1,16 @@
---
title: Garbage Collection
content_template: templates/concept
weight: 60
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
The role of the Kubernetes garbage collector is to delete certain objects
that once had an owner, but no longer have an owner.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Owners and dependents
@@ -168,16 +166,11 @@ See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment
Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md → content/en/docs/concepts/workloads/controllers/job.md
+18 -19
View File
@@ -2,16 +2,16 @@
reviewers:
- erictune
- soltysh
title: Jobs - Run to Completion
content_template: templates/concept
title: Jobs
content_type: concept
feature:
title: Batch execution
description: >
In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
weight: 70
weight: 60
---
{{% capture overview %}}
<!-- overview -->
A Job creates one or more Pods and ensures that a specified number of them successfully terminate.
As pods successfully complete, the Job tracks the successful completions. When a specified number
@@ -24,10 +24,10 @@ due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Running an example Job
@@ -111,7 +111,7 @@ The output is similar to this:
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
## Writing a Job Spec
## Writing a Job spec
As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields.
Its name must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -129,13 +129,13 @@ labels (see [pod selector](#pod-selector)) and an appropriate restart policy.
Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed.
### Pod Selector
### Pod selector
The `.spec.selector` field is optional. In almost all cases you should not specify it.
See section [specifying your own pod selector](#specifying-your-own-pod-selector).
### Parallel Jobs
### Parallel execution for Jobs {#parallel-jobs}
There are three main types of task suitable to run as a Job:
@@ -166,7 +166,7 @@ a non-negative integer.
For more information about how to make use of the different types of job, see the [job patterns](#job-patterns) section.
#### Controlling Parallelism
#### Controlling parallelism
The requested parallelism (`.spec.parallelism`) can be set to any non-negative value.
If it is unspecified, it defaults to 1.
@@ -184,7 +184,7 @@ parallelism, for a variety of reasons:
- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job.
- When a Pod is gracefully shut down, it takes time to stop.
## Handling Pod and Container Failures
## Handling Pod and container failures
A container in a Pod may fail for a number of reasons, such as because the process in it exited with
a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this
@@ -228,7 +228,7 @@ will be terminated once the job backoff limit has been reached. This can make de
from failed Jobs is not lost inadvertently.
{{< /note >}}
## Job Termination and Cleanup
## Job termination and cleanup
When a Job completes, no more Pods are created, but the Pods are not deleted either. Keeping them around
allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output.
@@ -269,7 +269,7 @@ Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads
Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: there is no automatic Job restart once the Job status is `type: Failed`.
That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
## Clean Up Finished Jobs Automatically
## Clean up finished jobs automatically
Finished Jobs are usually no longer needed in the system. Keeping them around in
the system will put pressure on the API server. If the Jobs are managed directly
@@ -277,7 +277,7 @@ by a higher level controller, such as
[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be
cleaned up by CronJobs based on the specified capacity-based cleanup policy.
### TTL Mechanism for Finished Jobs
### TTL mechanism for finished Jobs
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
@@ -322,7 +322,7 @@ more information, see the documentation for
[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for
finished resources.
## Job Patterns
## Job patterns
The Job object can be used to support reliable parallel execution of Pods. The Job object is not
designed to support closely-communicating parallel processes, as commonly found in scientific
@@ -374,9 +374,9 @@ Here, `W` is the number of work items.
| Single Job with Static Work Assignment | W | any |
## Advanced Usage
## Advanced usage
### Specifying your own pod selector
### Specifying your own Pod selector
Normally, when you create a Job object, you do not specify `.spec.selector`.
The system defaulting logic adds this field when the Job is created.
@@ -461,7 +461,7 @@ As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `
for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
(Note: If `RestartPolicy` is not set, the default value is `Always`.)
### Single Job starts Controller Pod
### Single Job starts controller Pod
Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort
of custom controller for those Pods. This allows the most flexibility, but may be somewhat
@@ -478,4 +478,3 @@ object, but maintains complete control over what Pods are created and how work i
You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/replicaset.md
+5 -5
View File
@@ -4,19 +4,19 @@ reviewers:
- bprashanth
- madhusudancs
title: ReplicaSet
content_template: templates/concept
content_type: concept
weight: 10
---
{{% capture overview %}}
<!-- overview -->
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often
used to guarantee the availability of a specified number of identical Pods.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## How a ReplicaSet works
@@ -366,4 +366,4 @@ The two serve the same purpose, and behave similarly, except that a ReplicationC
selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors).
As such, ReplicaSets are preferred over ReplicationControllers
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+5 -5
View File
@@ -9,11 +9,11 @@ feature:
description: >
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_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
{{< note >}}
A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
@@ -23,10 +23,10 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru
time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is
always up and available.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## How a ReplicationController Works
@@ -285,4 +285,4 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/statefulset.md
+8 -7
View File
@@ -7,18 +7,18 @@ reviewers:
- kow3ns
- smarterclayton
title: StatefulSets
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
StatefulSet is the workload API object used to manage stateful applications.
{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Using StatefulSets
@@ -270,12 +270,13 @@ After reverting the template, you must also delete any Pods that StatefulSet had
already attempted to run with the bad configuration.
StatefulSet will then begin to recreate the Pods using the reverted template.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
{{% /capture %}}
content/en/docs/concepts/workloads/controllers/ttlafterfinished.md
+12 -11
View File
@@ -2,18 +2,18 @@
reviewers:
- janetkuo
title: TTL Controller for Finished Resources
content_template: templates/concept
weight: 65
content_type: concept
weight: 70
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource
objects that have finished execution. TTL controller only handles
[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) for
now, and may be expanded to handle other resources that will finish execution,
{{< glossary_tooltip text="Jobs" term_id="job" >}} for now,
and may be expanded to handle other resources that will finish execution,
such as Pods and custom resources.
Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager
@@ -21,19 +21,19 @@ Alpha Disclaimer: this feature is currently alpha, and can be enabled with both
`TTLAfterFinished`.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## TTL Controller
The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean
up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
`.spec.ttlSecondsAfterFinished` field of a Job, as in this
[example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
[example](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
The TTL controller will assume that a resource is eligible to be cleaned up
TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete
@@ -78,12 +78,13 @@ In Kubernetes, it's required to run NTP on all nodes
to avoid time skew. Clocks aren't always correct, but the difference should be
very small. Please be aware of this risk when setting a non-zero TTL.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
[Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/disruptions.md
+8 -7
View File
@@ -4,11 +4,11 @@ reviewers:
- foxish
- davidopp
title: Disruptions
content_template: templates/concept
content_type: concept
weight: 60
---
{{% capture overview %}}
<!-- overview -->
This guide is for application owners who want to build
highly available applications, and thus need to understand
what types of Disruptions can happen to Pods.
@@ -16,10 +16,10 @@ what types of Disruptions can happen to Pods.
It is also for Cluster Administrators who want to perform automated
cluster actions, like upgrading and autoscaling clusters.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Voluntary and Involuntary Disruptions
@@ -262,13 +262,14 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
disruptions largely overlaps with work to support autoscaling and tolerating
involuntary disruptions.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
* Learn more about [draining nodes](/docs/tasks/administer-cluster/safely-drain-node/)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/ephemeral-containers.md
+5 -5
View File
@@ -3,11 +3,11 @@ reviewers:
- verb
- yujuhong
title: Ephemeral Containers
content_template: templates/concept
content_type: concept
weight: 80
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
@@ -23,9 +23,9 @@ clusters. In accordance with the [Kubernetes Deprecation Policy](
significantly in the future or be removed entirely.
{{< /warning >}}
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Understanding ephemeral containers
@@ -192,4 +192,4 @@ example:
kubectl attach -it example-pod -c debugger
```
{{% /capture %}}
content/en/docs/concepts/workloads/pods/init-containers.md
+8 -7
View File
@@ -2,20 +2,20 @@
reviewers:
- erictune
title: Init Containers
content_template: templates/concept
content_type: concept
weight: 40
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of init containers: specialized containers that run
before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
Init containers can contain utilities or setup scripts not present in an app image.
You can specify init containers in the Pod specification alongside the `containers`
array (which describes app containers).
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Understanding init containers
@@ -317,12 +317,13 @@ reasons:
forcing a restart, and the init container completion record has been lost due
to garbage collection.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+9 -8
View File
@@ -1,20 +1,20 @@
---
title: Pod Lifecycle
content_template: templates/concept
content_type: concept
weight: 30
---
{{% capture overview %}}
<!-- overview -->
{{< comment >}}Updated: 4/14/2015{{< /comment >}}
{{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}}
This page describes the lifecycle of a Pod.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Pod phase
@@ -216,7 +216,7 @@ a list of additional conditions that the kubelet evaluates for Pod readiness.
Readiness gates are determined by the current state of `status.condition`
fields for the Pod. If Kubernetes cannot find such a
condition in the `status.conditions` field of a Pod, the status of the condition
is defaulted to "`False`". Below is an example:
is defaulted to "`False`".
Here is an example:
@@ -390,10 +390,11 @@ spec:
* Node controller sets Pod `phase` to Failed.
* If running under a controller, Pod is recreated elsewhere.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Get hands-on experience
[attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
@@ -403,7 +404,7 @@ spec:
* Learn more about [Container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/).
{{% /capture %}}
content/en/docs/concepts/workloads/pods/pod-overview.md
+8 -7
View File
@@ -2,19 +2,19 @@
reviewers:
- erictune
title: Pod Overview
content_template: templates/concept
content_type: concept
weight: 10
card:
name: concepts
weight: 60
---
{{% capture overview %}}
<!-- overview -->
This page provides an overview of `Pod`, the smallest deployable object in the Kubernetes object model.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Understanding Pods
A *Pod* is the basic execution unit of a Kubernetes application--the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your {{< glossary_tooltip term_id="cluster" text="cluster" >}}.
@@ -111,12 +111,13 @@ For example, a Deployment controller ensures that the running Pods match the cur
On Nodes, the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} does not directly observe or manage any of the details around pod templates and updates; those details are abstracted away. That abstraction and separation of concerns simplifies system semantics, and makes it feasible to extend the cluster's behavior without changing existing code.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* Learn more about [Pods](/docs/concepts/workloads/pods/pod/)
* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container
* Learn more about Pod behavior:
* [Pod Termination](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+6 -7
View File
@@ -1,18 +1,18 @@
---
title: Pod Topology Spread Constraints
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Prerequisites
@@ -236,8 +236,7 @@ scheduled - more packed or more scattered.
The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
topology domains - to achieve high availability or cost-saving. This can also help on rolling update
workloads and scaling out replicas smoothly.
See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
workloads and scaling out replicas smoothly. See [Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation) for more details.
## Known Limitations
@@ -246,4 +245,4 @@ As of 1.18, at which this feature is Beta, there are some known limitations:
- Scaling down a Deployment may result in imbalanced Pods distribution.
- Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
{{% /capture %}}
content/en/docs/concepts/workloads/pods/pod.md
+5 -5
View File
@@ -1,19 +1,19 @@
---
reviewers:
title: Pods
content_template: templates/concept
content_type: concept
weight: 20
---
{{% capture overview %}}
<!-- overview -->
_Pods_ are the smallest deployable units of computing that can be created and
managed in Kubernetes.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## What is a Pod?
@@ -206,4 +206,4 @@ describes the object in detail.
When creating the manifest for a Pod object, make sure the name specified is a valid
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
{{% /capture %}}
content/en/docs/concepts/workloads/pods/podpreset.md
+8 -7
View File
@@ -2,20 +2,20 @@
reviewers:
- jessfraz
title: Pod Preset
content_template: templates/concept
content_type: concept
weight: 50
---
{{% capture overview %}}
<!-- overview -->
{{< feature-state for_k8s_version="v1.6" state="alpha" >}}
This page provides an overview of PodPresets, which are objects for injecting
certain information into pods at creation time. The information can include
secrets, volumes, volume mounts, and environment variables.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Understanding Pod presets
A PodPreset is an API resource for injecting additional runtime requirements
@@ -82,12 +82,13 @@ There may be instances where you wish for a Pod to not be altered by any Pod
Preset mutations. In these cases, you can add an annotation in the Pod Spec
of the form: `podpreset.admission.kubernetes.io/exclude: "true"`.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/)
For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
{{% /capture %}}
content/en/docs/contribute/_index.md
+6 -6
View File
@@ -1,5 +1,5 @@
---
content_template: templates/concept
content_type: concept
title: Contribute to Kubernetes docs
linktitle: Contribute
main_menu: true
@@ -10,7 +10,7 @@ card:
title: Start contributing
---
{{% capture overview %}}
<!-- overview -->
This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs).
@@ -23,9 +23,9 @@ Kubernetes documentation contributors:
Kubernetes documentation welcomes improvements from all contributors, new and experienced!
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Getting started
@@ -48,7 +48,7 @@ roles and permissions.
- [Open a pull request using GitHub](/docs/contribute/new-content/new-content/#changes-using-github) to existing documentation and learn more about filing issues in GitHub.
- [Review pull requests](/docs/contribute/review/reviewing-prs/) from other Kubernetes community members for accuracy and language.
- Read the Kubernetes [content](/docs/contribute/style/content-guide/) and [style guides](/docs/contribute/style/style-guide/) so you can leave informed comments.
- Learn how to [use page templates](/docs/contribute/style/page-templates/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) to make bigger changes.
- Learn about [page content types](/docs/contribute/style/page-content-types/) and [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/).
## Next steps
@@ -75,4 +75,4 @@ SIG Docs communicates with different methods:
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
{{% /capture %}}
content/en/docs/contribute/advanced.md
+5 -5
View File
@@ -1,11 +1,11 @@
---
title: Advanced contributing
slug: advanced
content_template: templates/concept
content_type: concept
weight: 98
---
{{% capture overview %}}
<!-- overview -->
This page assumes that you understand how to
[contribute to new content](/docs/contribute/new-content/overview) and
@@ -13,9 +13,9 @@ This page assumes that you understand how to
to learn about more ways to contribute. You need to use the Git command line
client and other tools for some of these tasks.
{{% /capture %}}
{{% capture body %}}
<!-- body -->
## Be the PR Wrangler for a week
@@ -245,4 +245,4 @@ When you’re ready to stop recording, click Stop.
The video uploads automatically to YouTube.
{{% /capture %}}
content/en/docs/contribute/generate-ref-docs/contribute-upstream.md
+11 -9
View File
@@ -1,10 +1,10 @@
---
title: Contributing to the Upstream Kubernetes Code
content_template: templates/task
content_type: task
weight: 20
---
{{% capture overview %}}
<!-- overview -->
This page shows how to contribute to the upstream `kubernetes/kubernetes` project.
You can fix bugs found in the Kubernetes API documentation or the content of
@@ -16,9 +16,10 @@ API or the `kube-*` components from the upstream code, see the following instruc
- [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
- [Generating Reference Documentation for the Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
- You need to have these tools installed:
@@ -35,9 +36,9 @@ API or the `kube-*` components from the upstream code, see the following instruc
For more information, see [Creating a Pull Request](https://help.github.com/articles/creating-a-pull-request/)
and [GitHub Standard Fork & Pull Request Workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962).
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## The big picture
@@ -230,12 +231,13 @@ the API reference documentation.
You are now ready to follow the [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) guide to generate the
[published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
{{% /capture %}}
content/en/docs/contribute/generate-ref-docs/kubectl.md
+11 -9
View File
@@ -1,10 +1,10 @@
---
title: Generating Reference Documentation for kubectl Commands
content_template: templates/task
content_type: task
weight: 90
---
{{% capture overview %}}
<!-- overview -->
This page shows how to generate the `kubectl` command reference.
@@ -21,15 +21,16 @@ reference page, see
[Generating Reference Pages for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/).
{{< /note >}}
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "prerequisites-ref-docs.md" >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Setting up the local repositories
@@ -253,12 +254,13 @@ A few minutes after your pull request is merged, your updated reference
topics will be visible in the
[published documentation](/docs/home).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
{{% /capture %}}
content/en/docs/contribute/generate-ref-docs/kubernetes-api.md
+11 -9
View File
@@ -1,10 +1,10 @@
---
title: Generating Reference Documentation for the Kubernetes API
content_template: templates/task
content_type: task
weight: 50
---
{{% capture overview %}}
<!-- overview -->
This page shows how to update the Kubernetes API reference documentation.
@@ -18,15 +18,16 @@ If you find bugs in the generated documentation, you need to
If you need only to regenerate the reference documentation from the [OpenAPI](https://github.com/OAI/OpenAPI-Specification)
spec, continue reading this page.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "prerequisites-ref-docs.md" >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Setting up the local repositories
@@ -194,12 +195,13 @@ Submit your changes as a
Monitor your pull request, and respond to reviewer comments as needed. Continue
to monitor your pull request until it has been merged.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
{{% /capture %}}
content/en/docs/contribute/generate-ref-docs/kubernetes-components.md
+11 -9
View File
@@ -1,34 +1,36 @@
---
title: Generating Reference Pages for Kubernetes Components and Tools
content_template: templates/task
content_type: task
weight: 120
---
{{% capture overview %}}
<!-- overview -->
This page shows how to build the Kubernetes component and tool reference pages.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)
in the Reference Documentation Quickstart guide.
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
to generate the Kubernetes component and tool reference pages.
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
* [Generating Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/)
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
* [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/)
{{% /capture %}}
content/en/docs/contribute/generate-ref-docs/quickstart.md
+11 -9
View File
@@ -1,24 +1,25 @@
---
title: Quickstart
content_template: templates/task
content_type: task
weight: 40
---
{{% capture overview %}}
<!-- overview -->
This page shows how to use the `update-imported-docs` script to generate
the Kubernetes reference documentation. The script automates
the build setup and generates the reference documentation for a release.
{{% /capture %}}
{{% capture prerequisites %}}
## {{% heading "prerequisites" %}}
{{< include "prerequisites-ref-docs.md" >}}
{{% /capture %}}
{{% capture steps %}}
<!-- steps -->
## Getting the docs repository
@@ -246,9 +247,10 @@ A few minutes after your pull request is merged, your updated reference
topics will be visible in the
[published documentation](/docs/home/).
{{% /capture %}}
{{% capture whatsnext %}}
## {{% heading "whatsnext" %}}
To generate the individual reference documentation by manually setting up the required build repositories and
running the build targets, see the following guides:
@@ -257,4 +259,4 @@ running the build targets, see the following guides:
* [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/)
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/)
{{% /capture %}}

Some files were not shown because too many files have changed in this diff Show More