diff --git a/docs/admission_controllers.md b/docs/admission_controllers.md index 5ac39b179a1..243f2550411 100644 --- a/docs/admission_controllers.md +++ b/docs/admission_controllers.md @@ -14,6 +14,27 @@ certainly want the docs that go with that version. # Admission Controllers +**Table of Contents** + +- [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?) + + + ## What are they? An admission control plug-in is a piece of code that intercepts requests to the Kubernetes diff --git a/docs/api-conventions.md b/docs/api-conventions.md index 45f55a5d92f..83a09f5a961 100644 --- a/docs/api-conventions.md +++ b/docs/api-conventions.md @@ -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** + + - [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) + + + 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) diff --git a/docs/application-troubleshooting.md b/docs/application-troubleshooting.md index 323e58aac81..c3443f01c41 100644 --- a/docs/application-troubleshooting.md +++ b/docs/application-troubleshooting.md @@ -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** + +- [Application Troubleshooting.](#application-troubleshooting.) + - [FAQ](#faq) + - [Diagnosing the problem](#diagnosing-the-problem) + - [Debugging Pods](#debugging-pods) + + + ## FAQ Users are highly encouraged to check out our [FAQ](https://github.com/GoogleCloudPlatform/kubernetes/wiki/User-FAQ) diff --git a/docs/container-environment.md b/docs/container-environment.md index f7b11076fd4..510cc319c45 100644 --- a/docs/container-environment.md +++ b/docs/container-environment.md @@ -15,6 +15,22 @@ certainly want the docs that go with that version. # Kubernetes Container Environment +**Table of Contents** + +- [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) + + + + ## 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.  diff --git a/docs/getting-started-guides/scratch.md b/docs/getting-started-guides/scratch.md index 4635e26c193..eefa17d879c 100644 --- a/docs/getting-started-guides/scratch.md +++ b/docs/getting-started-guides/scratch.md @@ -29,44 +29,27 @@ steps that existing cluster setup scripts are making. **Table of Contents** -- [Designing and Preparing](#designing-and-preparing) + + - [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) + + ## Designing and Preparing diff --git a/docs/high-availability.md b/docs/high-availability.md index d5886a4b57f..1e18868b311 100644 --- a/docs/high-availability.md +++ b/docs/high-availability.md @@ -14,6 +14,16 @@ certainly want the docs that go with that version. # High Availability Kubernetes Clusters +**Table of Contents** + +- [High Availability Kubernetes Clusters](#high-availability-kubernetes-clusters) + - [Introduction](#introduction) + - [Overview](#overview) + - [Initial set-up](#initial-set-up) + - [Reliable nodes](#reliable-nodes) + + + ## 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 diff --git a/docs/images.md b/docs/images.md index 3429cea5545..36c7f29d645 100644 --- a/docs/images.md +++ b/docs/images.md @@ -13,12 +13,26 @@ certainly want the docs that go with that version. # 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** + +- [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) + + + ## Updating Images The default pull policy is `PullIfNotPresent` which causes the Kubelet to not diff --git a/docs/networking.md b/docs/networking.md index 9879bc9cfd8..d3007322aba 100644 --- a/docs/networking.md +++ b/docs/networking.md @@ -13,6 +13,7 @@ certainly want the docs that go with that version. # Networking in Kubernetes + **Table of Contents** - [Networking in Kubernetes](#networking-in-kubernetes) diff --git a/docs/node.md b/docs/node.md index c708f446ef1..4fd9d6299c0 100644 --- a/docs/node.md +++ b/docs/node.md @@ -14,6 +14,24 @@ certainly want the docs that go with that version. # Node +**Table of Contents** + +- [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) + + + ## What is a node? `Node` is a worker machine in Kubernetes, previously known as `Minion`. Node diff --git a/docs/persistent-volumes.md b/docs/persistent-volumes.md index e843570840e..17716a24b3e 100644 --- a/docs/persistent-volumes.md +++ b/docs/persistent-volumes.md @@ -16,6 +16,31 @@ certainly want the docs that go with that version. This document describes the current state of `PersistentVolumes` in Kubernetes. Familiarity with [volumes](volumes.md) is suggested. +**Table of Contents** + +- [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) + - [ Claims As Volumes](#-claims-as-volumes) + + + +## 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. diff --git a/docs/replication-controller.md b/docs/replication-controller.md index 1c6ea5fa0c1..e811878b9cf 100644 --- a/docs/replication-controller.md +++ b/docs/replication-controller.md @@ -14,6 +14,22 @@ certainly want the docs that go with that version. # Replication Controller +**Table of Contents** + +- [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) + + + ## 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). diff --git a/docs/secrets.md b/docs/secrets.md index 19c07c4611d..141089c3c0a 100644 --- a/docs/secrets.md +++ b/docs/secrets.md @@ -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** + +- [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) + + + ## Overview of Secrets diff --git a/docs/services.md b/docs/services.md index 6bb47a87c98..0c760aa396e 100644 --- a/docs/services.md +++ b/docs/services.md @@ -14,6 +14,31 @@ certainly want the docs that go with that version. # Services in Kubernetes +**Table of Contents** + +- [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) + - [External services](#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) + + + ## Overview Kubernetes [`Pods`](pods.md) are mortal. They are born and they die, and they diff --git a/docs/user-guide/configuring-containers.md b/docs/user-guide/configuring-containers.md index 301abc22638..bf3c0a97558 100644 --- a/docs/user-guide/configuring-containers.md +++ b/docs/user-guide/configuring-containers.md @@ -14,6 +14,19 @@ certainly want the docs that go with that version. # Kubernetes User Guide: Managing Applications: Configuring and launching containers +**Table of Contents** + +- [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) + + + ## 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. diff --git a/docs/user-guide/connecting-applications.md b/docs/user-guide/connecting-applications.md index 376ef20d1a9..798d70913c7 100644 --- a/docs/user-guide/connecting-applications.md +++ b/docs/user-guide/connecting-applications.md @@ -14,6 +14,21 @@ certainly want the docs that go with that version. # Kubernetes User Guide: Managing Applications: Connecting applications +**Table of Contents** + +- [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) + + + +# 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. diff --git a/docs/user-guide/introspection-and-debugging.md b/docs/user-guide/introspection-and-debugging.md index e34a28f6deb..e68ce4ba91b 100644 --- a/docs/user-guide/introspection-and-debugging.md +++ b/docs/user-guide/introspection-and-debugging.md @@ -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** + +- [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) + + + ## 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. diff --git a/docs/user-guide/managing-deployments.md b/docs/user-guide/managing-deployments.md index 93b49842801..655a4342b14 100644 --- a/docs/user-guide/managing-deployments.md +++ b/docs/user-guide/managing-deployments.md @@ -16,6 +16,21 @@ certainly want the docs that go with that version. 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** + +- [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) + + + ## 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: diff --git a/docs/volumes.md b/docs/volumes.md index 5a3d03aa165..7fba3b5adcd 100644 --- a/docs/volumes.md +++ b/docs/volumes.md @@ -23,6 +23,30 @@ Kubernetes `Volume` abstraction solves both of these problems. Familiarity with [pods](pods.md) is suggested. +**Table of Contents** + +- [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) + + + ## Background Docker also has a concept of