add en pages
This commit is contained in:
Karen Bradshaw
@@ -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
|
||||
|
||||
|
||||
|
||||
{{% /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 %}}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -112,11 +112,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 %}}
|
||||
|
||||
|
||||
|
||||
@@ -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 %}}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user