Apply templates to all concepts and tasks to fix double bullets in TOC (#9149)
* Apply concept template to fix double bullet issue. * Apply concept template * Apply templates to tasks
This commit is contained in:
Steve Perry
committed by
k8s-ci-robot
k8s-ci-robot
parent
ec15f3fab9
commit
75f00dfc60
@@ -3,15 +3,22 @@ reviewers:
|
||||
- lavalamp
|
||||
- thockin
|
||||
title: Cluster Management
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
|
||||
This document describes several topics related to the lifecycle of a cluster: creating a new cluster,
|
||||
upgrading your cluster's
|
||||
master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a
|
||||
running cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Creating and configuring a Cluster
|
||||
|
||||
To install Kubernetes on a set of machines, consult one of the existing [Getting Started guides](/docs/setup/) depending on your environment.
|
||||
@@ -211,3 +218,5 @@ kubectl convert -f pod.yaml --output-version v1
|
||||
```
|
||||
|
||||
For more options, please refer to the usage of [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands/#convert) command.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -3,8 +3,11 @@ reviewers:
|
||||
- davidopp
|
||||
- madhusudancs
|
||||
title: Configure Multiple Schedulers
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
|
||||
If the default scheduler does not suit your needs you can implement your own scheduler.
|
||||
Not just that, you can even run multiple schedulers simultaneously alongside the default
|
||||
@@ -16,7 +19,19 @@ document. Please refer to the kube-scheduler implementation in
|
||||
[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
|
||||
in the Kubernetes source directory for a canonical example.
|
||||
|
||||
### 1. Package the scheduler
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Package the scheduler
|
||||
|
||||
Package your scheduler binary into a container image. For the purposes of this example,
|
||||
let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
|
||||
@@ -48,7 +63,7 @@ docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .
|
||||
gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0
|
||||
```
|
||||
|
||||
### 2. Define a Kubernetes Deployment for the scheduler
|
||||
## Define a Kubernetes Deployment for the scheduler
|
||||
|
||||
Now that we have our scheduler in a container image, we can just create a pod
|
||||
config for it and run it in our Kubernetes cluster. But instead of creating a pod
|
||||
@@ -70,7 +85,7 @@ Please see the
|
||||
[kube-scheduler documentation](/docs/admin/kube-scheduler/) for
|
||||
detailed description of other command line arguments.
|
||||
|
||||
### 3. Run the second scheduler in the cluster
|
||||
## Run the second scheduler in the cluster
|
||||
|
||||
In order to run your scheduler in a Kubernetes cluster, just create the deployment
|
||||
specified in the config above in a Kubernetes cluster:
|
||||
@@ -126,7 +141,7 @@ $ kubectl edit clusterrole system:kube-scheduler
|
||||
- update
|
||||
```
|
||||
|
||||
### 4. Specify schedulers for pods
|
||||
## Specify schedulers for pods
|
||||
|
||||
Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the
|
||||
scheduler in that pod spec. Let's look at three examples.
|
||||
@@ -178,6 +193,10 @@ kubectl create -f pod3.yaml
|
||||
kubectl get pods
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
### Verifying that the pods were scheduled using the desired schedulers
|
||||
|
||||
In order to make it easier to work through these examples, we did not verify that the
|
||||
@@ -195,3 +214,5 @@ verify that the pods were scheduled by the desired schedulers.
|
||||
```shell
|
||||
kubectl get events
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -3,16 +3,24 @@ reviewers:
|
||||
- mml
|
||||
- wojtek-t
|
||||
title: Operating etcd clusters for Kubernetes
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< glossary_definition term_id="etcd" length="all" prepend="etcd is a ">}}
|
||||
|
||||
<!-- TODO(mml): Write this doc.
|
||||
{{% /capture %}}
|
||||
|
||||
For the mechanics behind how kubernetes builds, distributes and deploys etcd,
|
||||
see _some doc_.
|
||||
{{< toc >}}
|
||||
|
||||
-->
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -276,6 +284,10 @@ be back with new resource version. That would mean that restarting node
|
||||
components is not needed. But the assumptions here may not hold forever.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
### Design
|
||||
|
||||
This section describes how we are going to do the migration, given the
|
||||
@@ -399,3 +411,5 @@ you can talk to your cluster's etcd), try:
|
||||
```shell
|
||||
curl -X PUT "http://${host}:${port}/v2/keys/_test"
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -4,11 +4,12 @@ reviewers:
|
||||
- sjenning
|
||||
- ConnorDoyle
|
||||
- balajismaniam
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{< feature-state state="beta" >}}
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< toc >}}
|
||||
{{< feature-state state="beta" >}}
|
||||
|
||||
Kubernetes keeps many aspects of how pods execute on nodes abstracted
|
||||
from the user. This is by design. However, some workloads require
|
||||
@@ -17,6 +18,18 @@ acceptably. The kubelet provides methods to enable more complex workload
|
||||
placement policies while keeping the abstraction free from explicit placement
|
||||
directives.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## CPU Management Policies
|
||||
|
||||
By default, the kubelet uses [CFS quota](https://en.wikipedia.org/wiki/Completely_Fair_Scheduler)
|
||||
@@ -197,3 +210,4 @@ and `requests` are set equal to `limits` when not explicitly specified. And the
|
||||
container's resource limit for the CPU resource is an integer greater than or
|
||||
equal to one. The `nginx` container is granted 2 exclusive CPUs.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -21,6 +21,11 @@ You'll need to have a Kubernetes cluster in place, with network policy support.
|
||||
**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
|
||||
@@ -4,20 +4,23 @@ reviewers:
|
||||
- thockin
|
||||
- wlan0
|
||||
title: Developing Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
**Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will
|
||||
be the preferred way to integrate Kubernetes with any cloud. This will ensure cloud providers
|
||||
can develop their features independently from the core Kubernetes release cycles.**
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Background
|
||||
{{< feature-state for_k8s_version="1.8" state="alpha" >}}
|
||||
|
||||
Before going into how to build your own cloud controller manager, some background on how it works under the hood is helpful. The cloud controller manager is code from `kube-controller-manager` utilizing Go interfaces to allow implementations from any cloud to be plugged in. Most of the scaffolding and generic controller implementations will be in core, but it will always exec out to the cloud interfaces it is provided, so long as the [cloud provider interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go#L29-L50) is satisfied.
|
||||
|
||||
To dive a little deeper into implementation details, all cloud controller managers will import packages from Kubernetes core, the only difference being each project will register their own cloud providers by calling [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/plugins.go#L42-L52) where a global variable of available cloud providers is updated.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Developing
|
||||
|
||||
### Out of Tree
|
||||
@@ -33,3 +36,5 @@ Using existing out-of-tree cloud providers as an example may be helpful. You can
|
||||
### In Tree
|
||||
|
||||
For in-tree cloud providers, you can run the in-tree cloud controller manager as a [Daemonset](/docs/tasks/administer-cluster/cloud-controller-manager-daemonset-example.yaml) in your cluster. See the [running cloud controller manager docs](/docs/tasks/administer-cluster/running-cloud-controller.md) for more details.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -18,6 +18,12 @@ Kubernetes cluster.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Determining whether DNS horizontal autoscaling is already enabled
|
||||
|
||||
@@ -21,6 +21,14 @@ This page shows how to enable and configure encryption of secret data at rest.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Configuration and determining whether encryption at rest is already enabled
|
||||
|
||||
+10
-3
@@ -4,11 +4,10 @@ reviewers:
|
||||
- filipg
|
||||
- piosz
|
||||
title: Guaranteed Scheduling For Critical Add-On Pods
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Overview
|
||||
{{% capture overview %}}
|
||||
|
||||
In addition to Kubernetes core components like api-server, scheduler, controller-manager running on a master machine
|
||||
there are a number of add-ons which, for various reasons, must run on a regular cluster node (rather than the Kubernetes master).
|
||||
@@ -17,6 +16,12 @@ A cluster may stop working properly if a critical add-on is evicted (either manu
|
||||
and becomes pending (for example when the cluster is highly utilized and either there are other pending pods that schedule into the space
|
||||
vacated by the evicted critical add-on pod or the amount of resources available on the node changed for some other reason).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Rescheduler: guaranteed scheduling of critical add-ons
|
||||
**Rescheduler is deprecated as of Kubernetes 1.10 and will be removed in version 1.12 in
|
||||
accordance with the [deprecation policy](/docs/reference/deprecation-policy) for beta features.**
|
||||
@@ -62,3 +67,5 @@ A pod could also be considered critical, if its priority is greater than or equa
|
||||
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and
|
||||
|
||||
* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,12 +2,27 @@
|
||||
reviewers:
|
||||
- jszczepkowski
|
||||
title: Set up High-Availability Kubernetes Masters
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.5" state="alpha" >}}
|
||||
|
||||
You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
|
||||
This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
Kubernetes version 1.5 adds alpha support for replicating Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine.
|
||||
This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE.
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Starting an HA-compatible cluster
|
||||
|
||||
@@ -104,6 +119,10 @@ If the cluster is large, it may take a long time to duplicate its state.
|
||||
This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration)
|
||||
(we are considering adding support for etcd data dir migration in future).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Implementation notes
|
||||
|
||||
|
||||
@@ -154,3 +173,5 @@ To make such deployment secure, communication between etcd instances is authoriz
|
||||
## Additional reading
|
||||
|
||||
[Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -3,8 +3,10 @@ reviewers:
|
||||
- derekwaynecarr
|
||||
- janetkuo
|
||||
title: Namespaces Walkthrough
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster.
|
||||
|
||||
It does this by providing the following:
|
||||
@@ -16,14 +18,26 @@ Use of multiple namespaces is optional.
|
||||
|
||||
This example demonstrates how to use Kubernetes namespaces to subdivide your cluster.
|
||||
|
||||
### Step Zero: Prerequisites
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
This example assumes the following:
|
||||
|
||||
1. You have an [existing Kubernetes cluster](/docs/setup/).
|
||||
2. You have a basic understanding of Kubernetes _[Pods](/docs/concepts/workloads/pods/pod/)_, _[Services](/docs/concepts/services-networking/service/)_, and _[Deployments](/docs/concepts/workloads/controllers/deployment/)_.
|
||||
|
||||
### Step One: Understand the default namespace
|
||||
## Understand the default namespace
|
||||
|
||||
By default, a Kubernetes cluster will instantiate a default namespace when provisioning the cluster to hold the default set of Pods,
|
||||
Services, and Deployments used by the cluster.
|
||||
@@ -36,7 +50,7 @@ NAME STATUS AGE
|
||||
default Active 13m
|
||||
```
|
||||
|
||||
### Step Two: Create new namespaces
|
||||
## Create new namespaces
|
||||
|
||||
For this exercise, we will create two additional Kubernetes namespaces to hold our content.
|
||||
|
||||
@@ -83,7 +97,7 @@ development Active 29s name=development
|
||||
production Active 23s name=production
|
||||
```
|
||||
|
||||
### Step Three: Create pods in each namespace
|
||||
## Create pods in each namespace
|
||||
|
||||
A Kubernetes namespace provides the scope for Pods, Services, and Deployments in the cluster.
|
||||
|
||||
@@ -251,3 +265,5 @@ At this point, it should be clear that the resources users create in one namespa
|
||||
|
||||
As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different
|
||||
authorization rules for each namespace.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -4,9 +4,10 @@ reviewers:
|
||||
- vishh
|
||||
- timstclair
|
||||
title: Configure Out Of Resource Handling
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
|
||||
This page explains how to configure out of resource handling with `kubelet`.
|
||||
|
||||
@@ -15,6 +16,12 @@ are low. This is especially important when dealing with incompressible
|
||||
compute resources, such as memory or disk space. If such resources are exhausted,
|
||||
nodes become unstable.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Eviction Policy
|
||||
|
||||
The `kubelet` can proactively monitor for and prevent total starvation of a
|
||||
@@ -369,3 +376,5 @@ to prevent system OOMs, and promote eviction of workloads so cluster state can r
|
||||
|
||||
The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding
|
||||
the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -4,9 +4,10 @@ reviewers:
|
||||
- derekwaynecarr
|
||||
- dashpole
|
||||
title: Reserve Compute Resources for System Daemons
|
||||
content_template: templates/task
|
||||
---
|
||||
|
||||
{{< toc >}}
|
||||
{{% capture overview %}}
|
||||
|
||||
Kubernetes nodes can be scheduled to `Capacity`. Pods can consume all the
|
||||
available capacity on a node by default. This is an issue because nodes
|
||||
@@ -20,6 +21,18 @@ compute resources for system daemons. Kubernetes recommends cluster
|
||||
administrators to configure `Node Allocatable` based on their workload density
|
||||
on each node.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Node Allocatable
|
||||
|
||||
```text
|
||||
@@ -185,6 +198,10 @@ more features are added. Over time, kubernetes project will attempt to bring
|
||||
down utilization of node system daemons, but that is not a priority as of now.
|
||||
So expect a drop in `Allocatable` capacity in future releases.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture discussion %}}
|
||||
|
||||
## Example Scenario
|
||||
|
||||
Here is an example to illustrate Node Allocatable computation:
|
||||
@@ -230,3 +247,5 @@ the proper part of the cgroup hierarchy.
|
||||
|
||||
As of Kubernetes version 1.7, `kubelet` supports specifying `storage` as a resource
|
||||
for `kube-reserved` and `system-reserved`.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -4,18 +4,23 @@ reviewers:
|
||||
- thockin
|
||||
- wlan0
|
||||
title: Kubernetes Cloud Controller Manager
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
## Cloud Controller Manager
|
||||
|
||||
Kubernetes v1.6 introduced a new binary called `cloud-controller-manager`. `cloud-controller-manager` is a daemon that embeds cloud-specific control loops. These cloud-specific control loops were originally in the `kube-controller-manager`. Since cloud providers develop and release at a different pace compared to the Kubernetes project, abstracting the provider-specific code to the `cloud-controller-manager` binary allows cloud vendors to evolve independently from the core Kubernetes code.
|
||||
|
||||
The `cloud-controller-manager` can be linked to any cloud provider that satisfies [cloudprovider.Interface](https://git.k8s.io/kubernetes/pkg/cloudprovider/cloud.go). For backwards compatibility, the [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) provided in the core Kubernetes project uses the same cloud libraries as `kube-controller-manager`. Cloud providers already supported in Kubernetes core are expected to use the in-tree cloud-controller-manager to transition out of Kubernetes core. In future Kubernetes releases, all cloud controller managers will be developed outside of the core Kubernetes project managed by sig leads or cloud vendors.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Administration
|
||||
|
||||
### Requirements
|
||||
@@ -91,3 +96,5 @@ As this initiative evolves, changes will be made to address these issues in upco
|
||||
## Developing your own Cloud Controller Manager
|
||||
|
||||
To build and develop your own cloud controller manager, read the [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md) doc.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,8 +2,11 @@
|
||||
reviewers:
|
||||
- jsafrane
|
||||
title: Static Pods
|
||||
content_template: templates/concept
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
**If you are running clustered Kubernetes and are using static pods to run a pod on every node, you should probably be using a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)!**
|
||||
|
||||
*Static pods* are managed directly by kubelet daemon on a specific node, without the API server observing it. It does not have an associated replication controller, and kubelet daemon itself watches it and restarts it when it crashes. There is no health check. Static pods are always bound to one kubelet daemon and always run on the same node with it.
|
||||
@@ -11,6 +14,12 @@ title: Static Pods
|
||||
Kubelet automatically tries to create a *mirror pod* on the Kubernetes API server for each static pod.
|
||||
This means that the pods are visible on the API server but cannot be controlled from there.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{< toc >}}
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Static pod creation
|
||||
|
||||
Static pod can be created in two ways: either by using configuration file(s) or by HTTP.
|
||||
@@ -108,7 +117,7 @@ static-web-my-node1 1/1 Running 0 12s
|
||||
|
||||
Back to our `my-node1` host, we can try to stop the container manually and see, that kubelet automatically restarts it in a while:
|
||||
|
||||
```shell
|
||||
```none
|
||||
[joe@host ~] $ ssh my-node1
|
||||
[joe@my-node1 ~] $ docker stop f6d05272b57e
|
||||
[joe@my-node1 ~] $ sleep 20
|
||||
@@ -132,3 +141,5 @@ Running kubelet periodically scans the configured directory (`/etc/kubelet.d` in
|
||||
CONTAINER ID IMAGE COMMAND CREATED ...
|
||||
e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user