mirror of
https://github.com/k3s-io/kubernetes.git
synced 2025-07-29 22:46:12 +00:00
Add ToC to some longer documents.
This commit is contained in:
Eric Tune
parent
ee8513f1bb
commit
921619ab38
@ -14,6 +14,27 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Admission Controllers
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Admission Controllers](#admission-controllers)
|
||||
- [What are they?](#what-are-they?)
|
||||
- [Why do I need them?](#why-do-i-need-them?)
|
||||
- [How do I turn on an admission control plug-in?](#how-do-i-turn-on-an-admission-control-plug-in?)
|
||||
- [What does each plug-in do?](#what-does-each-plug-in-do?)
|
||||
- [AlwaysAdmit](#alwaysadmit)
|
||||
- [AlwaysDeny](#alwaysdeny)
|
||||
- [DenyExecOnPrivileged](#denyexeconprivileged)
|
||||
- [ServiceAccount](#serviceaccount)
|
||||
- [SecurityContextDeny](#securitycontextdeny)
|
||||
- [ResourceQuota](#resourcequota)
|
||||
- [LimitRanger](#limitranger)
|
||||
- [NamespaceExists](#namespaceexists)
|
||||
- [NamespaceAutoProvision (deprecated)](#namespaceautoprovision-(deprecated))
|
||||
- [NamespaceLifecycle](#namespacelifecycle)
|
||||
- [Is there a recommended set of plug-ins to use?](#is-there-a-recommended-set-of-plug-ins-to-use?)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## What are they?
|
||||
|
||||
An admission control plug-in is a piece of code that intercepts requests to the Kubernetes
|
||||
|
||||
@ -21,6 +21,38 @@ Updated: 4/16/2015
|
||||
API structure, and developers wanting to extend the kubernetes API. An introduction to
|
||||
using resources with kubectl can be found in (working_with_resources.md).*
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Types (Kinds)](#types-(kinds))
|
||||
- [Resources](#resources)
|
||||
- [Objects](#objects)
|
||||
- [Metadata](#metadata)
|
||||
- [Spec and Status](#spec-and-status)
|
||||
- [Typical status properties](#typical-status-properties)
|
||||
- [References to related objects](#references-to-related-objects)
|
||||
- [Lists of named subobjects preferred over maps](#lists-of-named-subobjects-preferred-over-maps)
|
||||
- [Constants](#constants)
|
||||
- [Lists and Simple kinds](#lists-and-simple-kinds)
|
||||
- [Differing Representations](#differing-representations)
|
||||
- [Verbs on Resources](#verbs-on-resources)
|
||||
- [PATCH operations](#patch-operations)
|
||||
- [Strategic Merge Patch](#strategic-merge-patch)
|
||||
- [List Operations](#list-operations)
|
||||
- [Map Operations](#map-operations)
|
||||
- [Idempotency](#idempotency)
|
||||
- [Defaulting](#defaulting)
|
||||
- [Late Initialization](#late-initialization)
|
||||
- [Concurrency Control and Consistency](#concurrency-control-and-consistency)
|
||||
- [Serialization Format](#serialization-format)
|
||||
- [Units](#units)
|
||||
- [Selecting Fields](#selecting-fields)
|
||||
- [HTTP Status codes](#http-status-codes)
|
||||
- [Success codes](#success-codes)
|
||||
- [Error codes](#error-codes)
|
||||
- [Response Status Kind](#response-status-kind)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
The conventions of the [Kubernetes API](api.md) (and related APIs in the ecosystem) are intended to ease client development and ensure that configuration mechanisms can be implemented that work across a diverse set of use cases consistently.
|
||||
|
||||
The general style of the Kubernetes API is RESTful - clients create, update, delete, or retrieve a description of an object via the standard HTTP verbs (POST, PUT, DELETE, and GET) - and those APIs preferentially accept and return JSON. Kubernetes also exposes additional endpoints for non-standard verbs and allows alternative content types. All of the JSON accepted and returned by the server has a schema, identified by the "kind" and "apiVersion" fields. Where relevant HTTP header fields exist, they should mirror the content of JSON fields, but the information should not be represented only in the HTTP header.
|
||||
@ -37,8 +69,7 @@ Each resource typically accepts and returns data of a single kind. A kind may b
|
||||
Resource collections should be all lowercase and plural, whereas kinds are CamelCase and singular.
|
||||
|
||||
|
||||
Types (Kinds)
|
||||
-------------
|
||||
## Types (Kinds)
|
||||
|
||||
Kinds are grouped into three categories:
|
||||
|
||||
@ -174,8 +205,7 @@ Every list or simple kind SHOULD have the following metadata in a nested object
|
||||
Every simple kind returned by the server, and any simple kind sent to the server that must support idempotency or optimistic concurrency should return this value.Since simple resources are often used as input alternate actions that modify objects, the resource version of the simple resource should correspond to the resource version of the object.
|
||||
|
||||
|
||||
Differing Representations
|
||||
-------------------------
|
||||
## Differing Representations
|
||||
|
||||
An API may represent a single entity in different ways for different clients, or transform an object after certain transitions in the system occur. In these cases, one request object may have two representations available as different resources, or different kinds.
|
||||
|
||||
@ -186,8 +216,7 @@ As another example, a "pod status" resource may accept a PUT with the "pod" kind
|
||||
Future versions of Kubernetes may allow alternative encodings of objects beyond JSON.
|
||||
|
||||
|
||||
Verbs on Resources
|
||||
------------------
|
||||
## Verbs on Resources
|
||||
|
||||
API resources should use the traditional REST pattern:
|
||||
|
||||
@ -293,15 +322,13 @@ labels:
|
||||
```
|
||||
|
||||
|
||||
Idempotency
|
||||
-----------
|
||||
## Idempotency
|
||||
|
||||
All compatible Kubernetes APIs MUST support "name idempotency" and respond with an HTTP status code 409 when a request is made to POST an object that has the same name as an existing object in the system. See [identifiers.md](identifiers.md) for details.
|
||||
|
||||
Names generated by the system may be requested using `metadata.generateName`. GenerateName indicates that the name should be made unique by the server prior to persisting it. A non-empty value for the field indicates the name will be made unique (and the name returned to the client will be different than the name passed). The value of this field will be combined with a unique suffix on the server if the Name field has not been provided. The provided value must be valid within the rules for Name, and may be truncated by the length of the suffix required to make the value unique on the server. If this field is specified, and Name is not present, the server will NOT return a 409 if the generated name exists - instead, it will either return 201 Created or 504 with Reason `ServerTimeout` indicating a unique name could not be found in the time allotted, and the client should retry (optionally after the time indicated in the Retry-After header).
|
||||
|
||||
Defaulting
|
||||
----------
|
||||
## Defaulting
|
||||
|
||||
Default resource values are API version-specific, and they are applied during
|
||||
the conversion from API-versioned declarative configuration to internal objects
|
||||
@ -314,8 +341,8 @@ achieve the state, and for the user to know what to anticipate.
|
||||
|
||||
API version-specific default values are set by the API server.
|
||||
|
||||
Late Initialization
|
||||
-------------------
|
||||
## Late Initialization
|
||||
|
||||
Late initialization is when resource fields are set by a system controller
|
||||
after an object is created/updated.
|
||||
|
||||
@ -339,8 +366,7 @@ Although the apiserver Admission Control stage acts prior to object creation,
|
||||
Admission Control plugins should follow the Late Initialization conventions
|
||||
too, to allow their implementation to be later moved to a 'controller', or to client libraries.
|
||||
|
||||
Concurrency Control and Consistency
|
||||
-----------------------------------
|
||||
## Concurrency Control and Consistency
|
||||
|
||||
Kubernetes leverages the concept of *resource versions* to achieve optimistic concurrency. All Kubernetes resources have a "resourceVersion" field as part of their metadata. This resourceVersion is a string that identifies the internal version of an object that can be used by clients to determine when objects have changed. When a record is about to be updated, it's version is checked against a pre-saved value, and if it doesn't match, the update fails with a StatusConflict (HTTP status code 409).
|
||||
|
||||
@ -368,22 +394,19 @@ resourceVersion may be used as a precondition for other operations (e.g., GET, D
|
||||
"Watch" operations specify resourceVersion using a query parameter. It is used to specify the point at which to begin watching the specified resources. This may be used to ensure that no mutations are missed between a GET of a resource (or list of resources) and a subsequent Watch, even if the current version of the resource is more recent. This is currently the main reason that list operations (GET on a collection) return resourceVersion.
|
||||
|
||||
|
||||
Serialization Format
|
||||
--------------------
|
||||
## Serialization Format
|
||||
|
||||
APIs may return alternative representations of any resource in response to an Accept header or under alternative endpoints, but the default serialization for input and output of API responses MUST be JSON.
|
||||
|
||||
All dates should be serialized as RFC3339 strings.
|
||||
|
||||
|
||||
Units
|
||||
-----
|
||||
## Units
|
||||
|
||||
Units must either be explicit in the field name (e.g., `timeoutSeconds`), or must be specified as part of the value (e.g., `resource.Quantity`). Which approach is preferred is TBD.
|
||||
|
||||
|
||||
Selecting Fields
|
||||
----------------
|
||||
## Selecting Fields
|
||||
|
||||
Some APIs may need to identify which field in a JSON object is invalid, or to reference a value to extract from a separate resource. The current recommendation is to use standard JavaScript syntax for accessing that field, assuming the JSON object was transformed into a JavaScript object.
|
||||
|
||||
@ -394,8 +417,7 @@ Examples:
|
||||
TODO: Plugins, extensions, nested kinds, headers
|
||||
|
||||
|
||||
HTTP Status codes
|
||||
-----------------
|
||||
## HTTP Status codes
|
||||
|
||||
The server will respond with HTTP status codes that match the HTTP spec. See the section below for a breakdown of the types of status codes the server will send.
|
||||
|
||||
@ -466,8 +488,7 @@ The following HTTP status codes may be returned by the API.
|
||||
* Suggested client recovery behavior:
|
||||
* Increase the value of the timeout param and retry with exponential backoff
|
||||
|
||||
Response Status Kind
|
||||
--------------------
|
||||
## Response Status Kind
|
||||
|
||||
Kubernetes will always return the ```Status``` kind from any API endpoint when an error occurs.
|
||||
Clients SHOULD handle these types of objects when appropriate.
|
||||
@ -598,8 +619,7 @@ Possible values for the ```reason``` and ```details``` fields:
|
||||
`code` may contain the suggested HTTP return code for this status.
|
||||
|
||||
|
||||
Events
|
||||
------
|
||||
## Events
|
||||
|
||||
TODO: Document events (refer to another doc for details)
|
||||
|
||||
|
||||
@ -18,6 +18,15 @@ This guide is to help users debug applications that are deployed into Kubernetes
|
||||
This is *not* a guide for people who want to debug their cluster. For that you should check out
|
||||
[this guide](cluster-troubleshooting.md)
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Application Troubleshooting.](#application-troubleshooting.)
|
||||
- [FAQ](#faq)
|
||||
- [Diagnosing the problem](#diagnosing-the-problem)
|
||||
- [Debugging Pods](#debugging-pods)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## FAQ
|
||||
Users are highly encouraged to check out our [FAQ](https://github.com/GoogleCloudPlatform/kubernetes/wiki/User-FAQ)
|
||||
|
||||
|
||||
@ -15,6 +15,22 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
# Kubernetes Container Environment
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Kubernetes Container Environment](#kubernetes-container-environment)
|
||||
- [Overview](#overview)
|
||||
- [Cluster Information](#cluster-information)
|
||||
- [Container Information](#container-information)
|
||||
- [Cluster Information](#cluster-information)
|
||||
- [Container Hooks](#container-hooks)
|
||||
- [Hook Details](#hook-details)
|
||||
- [Hook Handler Execution](#hook-handler-execution)
|
||||
- [Hook delivery guarantees](#hook-delivery-guarantees)
|
||||
- [Hook Handler Implementations](#hook-handler-implementations)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
|
||||
## Overview
|
||||
This document describes the environment for Kubelet managed containers on a Kubernetes node (kNode). In contrast to the Kubernetes cluster API, which provides an API for creating and managing containers, the Kubernetes container environment provides the container access to information about what else is going on in the cluster.
|
||||
|
||||
|
||||
@ -29,44 +29,27 @@ steps that existing cluster setup scripts are making.
|
||||
|
||||
**Table of Contents**
|
||||
|
||||
- [Designing and Preparing](#designing-and-preparing)
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Designing and Preparing](#designing-and-preparing)
|
||||
- [Learning](#learning)
|
||||
- [Cloud Provider](#cloud-provider)
|
||||
- [Nodes](#nodes)
|
||||
- [Network](#network)
|
||||
- [Cluster Naming](#cluster-naming)
|
||||
- [Software Binaries](#software-binaries)
|
||||
- [Downloading and Extracting Kubernetes Binaries](#downloading-and-extracting-kubernetes-binaries)
|
||||
- [Selecting Images](#selecting-images)
|
||||
- [Downloading and Extracting Kubernetes Binaries](#downloading-and-extracting-kubernetes-binaries)
|
||||
- [Selecting Images](#selecting-images)
|
||||
- [Security Models](#security-models)
|
||||
- [Preparing Certs](#preparing-certs)
|
||||
- [Preparing Credentials](#preparing-credentials)
|
||||
- [Configuring and Installing Base Software on Nodes](#configuring-and-installing-base-software-on-nodes)
|
||||
- [Preparing Certs](#preparing-certs)
|
||||
- [Preparing Credentials](#preparing-credentials)
|
||||
- [Configuring and Installing Base Software on Nodes](#configuring-and-installing-base-software-on-nodes)
|
||||
- [Docker](#docker)
|
||||
- [rkt](#rkt)
|
||||
- [kubelet](#kubelet)
|
||||
- [kube-proxy](#kube-proxy)
|
||||
- [Networking](#networking)
|
||||
- [Other](#other)
|
||||
- [Using Configuration Management](#using-configuration-management)
|
||||
- [Bootstrapping the Cluster](#bootstrapping-the-cluster)
|
||||
- [etcd](#etcd)
|
||||
- [Apiserver](#apiserver)
|
||||
- [Apiserver pod template](#apiserver-pod-template)
|
||||
- [Starting Apiserver](#starting-apiserver)
|
||||
- [Scheduler](#scheduler)
|
||||
- [Controller Manager](#controller-manager)
|
||||
- [DNS](#dns)
|
||||
- [Logging](#logging)
|
||||
- [Monitoring](#monitoring)
|
||||
- [Miscellaneous Resources](#miscelaneous-resources)
|
||||
- [Troubleshooting](#troubleshooting)
|
||||
- [Running validate-cluster](#running-validate-cluster)
|
||||
- [Inspect pods and services](#inspect-pods-and-services)
|
||||
- [Try Examples](#try-examples)
|
||||
- [Running the Conformance Test](#running-the-conformance-test)
|
||||
- [Networking](#networking)
|
||||
- [Getting Help](#getting-help)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Designing and Preparing
|
||||
|
||||
|
||||
@ -14,6 +14,16 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# High Availability Kubernetes Clusters
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [High Availability Kubernetes Clusters](#high-availability-kubernetes-clusters)
|
||||
- [Introduction](#introduction)
|
||||
- [Overview](#overview)
|
||||
- [Initial set-up](#initial-set-up)
|
||||
- [Reliable nodes](#reliable-nodes)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Introduction
|
||||
This document describes how to build a high-availability (HA) Kubernetes cluster. This is a fairly advanced topic.
|
||||
Users who merely want to experiment with Kubernetes are encouraged to use configurations that are simpler to set up such as
|
||||
|
||||
@ -13,12 +13,26 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Images
|
||||
|
||||
Each container in a pod has its own image. Currently, the only type of image supported is a [Docker Image](https://docs.docker.com/userguide/dockerimages/).
|
||||
|
||||
You create your Docker image and push it to a registry before referring to it in a kubernetes pod.
|
||||
|
||||
The `image` property of a container supports the same syntax as the `docker` command does, including private registries and tags.
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Images](#images)
|
||||
- [Updating Images](#updating-images)
|
||||
- [Using a Private Registry](#using-a-private-registry)
|
||||
- [Using Google Container Registry](#using-google-container-registry)
|
||||
- [Configuring Nodes to Authenticate to a Private Repository](#configuring-nodes-to-authenticate-to-a-private-repository)
|
||||
- [Pre-pulling Images](#pre-pulling-images)
|
||||
- [Specifying ImagePullSecrets on a Pod](#specifying-imagepullsecrets-on-a-pod)
|
||||
- [Use Cases](#use-cases)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Updating Images
|
||||
|
||||
The default pull policy is `PullIfNotPresent` which causes the Kubelet to not
|
||||
|
||||
@ -13,6 +13,7 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Networking in Kubernetes
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Networking in Kubernetes](#networking-in-kubernetes)
|
||||
|
||||
18
docs/node.md
18
docs/node.md
@ -14,6 +14,24 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Node
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Node](#node)
|
||||
- [What is a node?](#what-is-a-node?)
|
||||
- [Node Status](#node-status)
|
||||
- [Node Addresses](#node-addresses)
|
||||
- [Node Phase](#node-phase)
|
||||
- [Node Condition](#node-condition)
|
||||
- [Node Capacity](#node-capacity)
|
||||
- [Node Info](#node-info)
|
||||
- [Node Management](#node-management)
|
||||
- [Node Controller](#node-controller)
|
||||
- [Self-Registration of nodes](#self-registration-of-nodes)
|
||||
- [Manual Node Administration](#manual-node-administration)
|
||||
- [Node capacity](#node-capacity)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## What is a node?
|
||||
|
||||
`Node` is a worker machine in Kubernetes, previously known as `Minion`. Node
|
||||
|
||||
@ -16,6 +16,31 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](volumes.md) is suggested.
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Persistent Volumes and Claims](#persistent-volumes-and-claims)
|
||||
- [Introduction](#introduction)
|
||||
- [Lifecycle of a volume and claim](#lifecycle-of-a-volume-and-claim)
|
||||
- [Provisioning](#provisioning)
|
||||
- [Binding](#binding)
|
||||
- [Using](#using)
|
||||
- [Releasing](#releasing)
|
||||
- [Reclaiming](#reclaiming)
|
||||
- [Types of Persistent Volumes](#types-of-persistent-volumes)
|
||||
- [Persistent Volumes](#persistent-volumes)
|
||||
- [Capacity](#capacity)
|
||||
- [Access Modes](#access-modes)
|
||||
- [Recycling Policy](#recycling-policy)
|
||||
- [Phase](#phase)
|
||||
- [PersistentVolumeClaims](#persistentvolumeclaims)
|
||||
- [Access Modes](#access-modes)
|
||||
- [Resources](#resources)
|
||||
- [<a name="claims-as-volumes"></a> Claims As Volumes](#<a-name="claims-as-volumes"></a>-claims-as-volumes)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Introduction
|
||||
|
||||
Managing storage is a distinct problem from managing compute. The `PersistentVolume` subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this we introduce two new API resources: `PersistentVolume` and `PersistentVolumeClaim`.
|
||||
|
||||
A `PersistentVolume` (PV) is a piece of networked storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
|
||||
|
||||
@ -14,6 +14,22 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Replication Controller
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Replication Controller](#replication-controller)
|
||||
- [What is a _replication controller_?](#what-is-a-_replication-controller_?)
|
||||
- [How does a replication controller work?](#how-does-a-replication-controller-work?)
|
||||
- [Pod template](#pod-template)
|
||||
- [Labels](#labels)
|
||||
- [Responsibilities of the replication controller](#responsibilities-of-the-replication-controller)
|
||||
- [Common usage patterns](#common-usage-patterns)
|
||||
- [Rescheduling](#rescheduling)
|
||||
- [Scaling](#scaling)
|
||||
- [Rolling updates](#rolling-updates)
|
||||
- [Multiple release tracks](#multiple-release-tracks)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## What is a _replication controller_?
|
||||
|
||||
A _replication controller_ ensures that a specified number of pod "replicas" are running at any one time. If there are too many, it will kill some. If there are too few, it will start more. Unlike in the case where a user directly created pods, a replication controller replaces pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a replication controller even if your application requires only a single pod. Think of it similarly to a process supervisor, only it supervises multiple pods across multiple nodes instead of individual processes on a single node. A replication controller delegates local container restarts to some agent on the node (e.g., Kubelet or Docker).
|
||||
|
||||
@ -19,6 +19,29 @@ passwords, OAuth tokens, and ssh keys. Putting this information in a `secret`
|
||||
is safer and more flexible than putting it verbatim in a `pod` definition or in
|
||||
a docker image.
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Secrets](#secrets)
|
||||
- [Overview of Secrets](#overview-of-secrets)
|
||||
- [Service Accounts Automatically Create and Use Secrets with API Credentials](#service-accounts-automatically-create-and-use-secrets-with-api-credentials)
|
||||
- [Creating a Secret Manually](#creating-a-secret-manually)
|
||||
- [Manually specifying a Secret to be Mounted on a Pod](#manually-specifying-a-secret-to-be-mounted-on-a-pod)
|
||||
- [Manually specifying an imagePullSecret](#manually-specifying-an-imagepullsecret)
|
||||
- [Automatic use of Manually Created Secrets](#automatic-use-of-manually-created-secrets)
|
||||
- [Details](#details)
|
||||
- [Restrictions](#restrictions)
|
||||
- [Consuming Secret Values](#consuming-secret-values)
|
||||
- [Secret and Pod Lifetime interaction](#secret-and-pod-lifetime-interaction)
|
||||
- [Use cases](#use-cases)
|
||||
- [Use-Case: Pod with ssh keys](#use-case:-pod-with-ssh-keys)
|
||||
- [Use-Case: Pods with prod / test credentials](#use-case:-pods-with-prod-/-test-credentials)
|
||||
- [Use-case: Secret visible to one container in a pod](#use-case:-secret-visible-to-one-container-in-a-pod)
|
||||
- [Security Properties](#security-properties)
|
||||
- [Protections](#protections)
|
||||
- [Risks](#risks)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Overview of Secrets
|
||||
|
||||
|
||||
|
||||
@ -14,6 +14,31 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Services in Kubernetes
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Services in Kubernetes](#services-in-kubernetes)
|
||||
- [Overview](#overview)
|
||||
- [Defining a service](#defining-a-service)
|
||||
- [Services without selectors](#services-without-selectors)
|
||||
- [Virtual IPs and service proxies](#virtual-ips-and-service-proxies)
|
||||
- [Multi-Port Services](#multi-port-services)
|
||||
- [Choosing your own IP address](#choosing-your-own-ip-address)
|
||||
- [Why not use round-robin DNS?](#why-not-use-round-robin-dns?)
|
||||
- [Discovering services](#discovering-services)
|
||||
- [Environment variables](#environment-variables)
|
||||
- [DNS](#dns)
|
||||
- [Headless services](#headless-services)
|
||||
- [<a name="external"></a>External services](#<a-name="external"></a>external-services)
|
||||
- [Type = NodePort](#type-=-nodeport)
|
||||
- [Type = LoadBalancer](#type-=-loadbalancer)
|
||||
- [Shortcomings](#shortcomings)
|
||||
- [Future work](#future-work)
|
||||
- [The gory details of virtual IPs](#the-gory-details-of-virtual-ips)
|
||||
- [Avoiding collisions](#avoiding-collisions)
|
||||
- [IPs and VIPs](#ips-and-vips)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Overview
|
||||
|
||||
Kubernetes [`Pods`](pods.md) are mortal. They are born and they die, and they
|
||||
|
||||
@ -14,6 +14,19 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Kubernetes User Guide: Managing Applications: Configuring and launching containers
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Kubernetes User Guide: Managing Applications: Configuring and launching containers](#kubernetes-user-guide:-managing-applications:-configuring-and-launching-containers)
|
||||
- [Configuration in Kubernetes](#configuration-in-kubernetes)
|
||||
- [Launching a container using a configuration file](#launching-a-container-using-a-configuration-file)
|
||||
- [Validating configuration](#validating-configuration)
|
||||
- [Environment variables and variable expansion](#environment-variables-and-variable-expansion)
|
||||
- [Viewing pod status](#viewing-pod-status)
|
||||
- [Viewing pod output](#viewing-pod-output)
|
||||
- [Deleting pods](#deleting-pods)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Configuration in Kubernetes
|
||||
|
||||
In addition to the imperative-style commands, such as `kubectl run` and `kubectl expose`, described [elsewhere](quick-start.md), Kubernetes supports declarative configuration. Often times, configuration files are preferable to imperative commands, since they can be checked into version control and changes to the files can be code reviewed, which is especially important for more complex configurations, producing a more robust, reliable and archival system.
|
||||
|
||||
@ -14,6 +14,21 @@ certainly want the docs that go with that version.</h1>
|
||||
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
||||
# Kubernetes User Guide: Managing Applications: Connecting applications
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Kubernetes User Guide: Managing Applications: Connecting applications](#kubernetes-user-guide:-managing-applications:-connecting-applications)
|
||||
- [The Kubernetes model for connecting Containers](#the-kubernetes-model-for-connecting-containers)
|
||||
- [Exposing nginx pods to the cluster](#exposing-nginx-pods-to-the-cluster)
|
||||
- [Creating a Service for the pods](#creating-a-service-for-the-pods)
|
||||
- [Accessing the Service from other pods in the cluster](#accessing-the-service-from-other-pods-in-the-cluster)
|
||||
- [Environment Variables:](#environment-variables:)
|
||||
- [DNS:](#dns:)
|
||||
- [Exposing the Service to the internet](#exposing-the-service-to-the-internet)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
# The Kubernetes model for connecting Containers
|
||||
|
||||
Now that you have a continuously running, replicated application you can expose it on a network. Before discussing the Kubernetes approach to networking, it is worthwhile to contrast it with the "normal" way networking works with Docker.
|
||||
|
||||
By default, Docker uses host-private networking, so containers can talk to other containers only if they are on the same machine. In order for Docker containers to communicate across nodes, they must be allocated ports on the machine's own IP address, which are then forwarded or proxied to the containers. This obviously means that containers must either coordinate which ports they use very carefully or else be allocated ports dynamically.
|
||||
|
||||
@ -18,6 +18,15 @@ Once your application is running, you’ll inevitably need to debug problems wit
|
||||
Earlier we described how you can use ```kubectl get pods``` to retrieve simple status information about
|
||||
your pods. But there are a number of ways to get even more information about your application.
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Kubernetes User Guide: Managing Applications: Application Introspection and Debugging](#kubernetes-user-guide:-managing-applications:-application-introspection-and-debugging)
|
||||
- [Using ```kubectl describe pod``` to fetch details about pods](#using-```kubectl-describe-pod```-to-fetch-details-about-pods)
|
||||
- [Example: debugging Pending Pods](#example:-debugging-pending-pods)
|
||||
- [Example: debugging a down/unreachable node](#example:-debugging-a-down/unreachable-node)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Using ```kubectl describe pod``` to fetch details about pods
|
||||
|
||||
For this example we’ll use a ReplicationController to create two pods, similar to the earlier example.
|
||||
|
||||
@ -16,6 +16,21 @@ certainly want the docs that go with that version.</h1>
|
||||
|
||||
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 we’ll discuss in more depth are [configuration files](configuring-containers.md#configuration-in-kubernetes) and [labels](deploying-applications.md#labels).
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Kubernetes User Guide: Managing Applications: Managing deployments](#kubernetes-user-guide:-managing-applications:-managing-deployments)
|
||||
- [Organizing resource configurations](#organizing-resource-configurations)
|
||||
- [Bulk operations in kubectl](#bulk-operations-in-kubectl)
|
||||
- [Using labels effectively](#using-labels-effectively)
|
||||
- [Canary deployments](#canary-deployments)
|
||||
- [Updating labels](#updating-labels)
|
||||
- [Scaling your application](#scaling-your-application)
|
||||
- [Updating your application without a service outage](#updating-your-application-without-a-service-outage)
|
||||
- [In-place updates of resources](#in-place-updates-of-resources)
|
||||
- [Disruptive updates](#disruptive-updates)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Organizing resource configurations
|
||||
|
||||
Many applications require multiple resources to be created, such as a Replication Controller and a Service. Management of multiple resources can be simplified by grouping them together in the same file (separated by `---` in YAML). For example:
|
||||
|
||||
@ -23,6 +23,30 @@ Kubernetes `Volume` abstraction solves both of these problems.
|
||||
|
||||
Familiarity with [pods](pods.md) is suggested.
|
||||
|
||||
**Table of Contents**
|
||||
<!-- BEGIN MUNGE: GENERATED_TOC -->
|
||||
- [Volumes](#volumes)
|
||||
- [Background](#background)
|
||||
- [Types of Volumes](#types-of-volumes)
|
||||
- [emptyDir](#emptydir)
|
||||
- [hostPath](#hostpath)
|
||||
- [gcePersistentDisk](#gcepersistentdisk)
|
||||
- [Creating a PD](#creating-a-pd)
|
||||
- [Example pod](#example-pod)
|
||||
- [awsElasticBlockStore](#awselasticblockstore)
|
||||
- [Creating an EBS volume](#creating-an-ebs-volume)
|
||||
- [AWS EBS Example configuration:](#aws-ebs-example-configuration:)
|
||||
- [nfs](#nfs)
|
||||
- [iscsi](#iscsi)
|
||||
- [glusterfs](#glusterfs)
|
||||
- [rbd](#rbd)
|
||||
- [gitRepo](#gitrepo)
|
||||
- [Secrets](#secrets)
|
||||
- [persistentVolumeClaim](#persistentvolumeclaim)
|
||||
- [Resources](#resources)
|
||||
|
||||
<!-- END MUNGE: GENERATED_TOC -->
|
||||
|
||||
## Background
|
||||
|
||||
Docker also has a concept of
|
||||
|
||||
Loading…
Reference in New Issue
Block a user