Merge branch 'master' into france_minikube
This commit is contained in:
@@ -65,8 +65,8 @@ footer {
|
||||
.button {
|
||||
display: inline-block;
|
||||
border-radius: 6px;
|
||||
padding: 0 20px;
|
||||
line-height: 40px;
|
||||
padding: 6px 20px;
|
||||
line-height: 1.3rem;
|
||||
color: white;
|
||||
background-color: $blue;
|
||||
text-decoration: none;
|
||||
|
||||
@@ -38,7 +38,7 @@ Minikube unterstützt die folgenden Treiber:
|
||||
* kvm ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#kvm-driver))
|
||||
* hyperkit ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
|
||||
* xhyve ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#xhyve-driver)) (deprecated)
|
||||
* hyperv ([Treiber installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
|
||||
* hyperv ([Treiber installation](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver))
|
||||
Beachten Sie, dass die unten angegebene IP-Adresse dynamisch ist und sich ändern kann. Sie kann mit `minikube ip` abgerufen werden.
|
||||
* none (Führt die Kubernetes-Komponenten auf dem Host und nicht in einer VM aus. Die Verwendung dieses Treibers erfordert Docker ([Docker installieren](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) und eine Linux-Umgebung)
|
||||
|
||||
|
||||
@@ -12,61 +12,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview
|
||||
|
||||
To work with Kubernetes, you use *Kubernetes API objects* to describe your cluster's *desired state*: what applications or other workloads you want to run, what container images they use, the number of replicas, what network and disk resources you want to make available, and more. You set your desired state by creating objects using the Kubernetes API, typically via the command-line interface, `kubectl`. You can also use the Kubernetes API directly to interact with the cluster and set or modify your desired state.
|
||||
|
||||
Once you've set your desired state, the *Kubernetes Control Plane* makes the cluster's current state match the desired state via the Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-lifecycle-event-generator.md)). To do so, Kubernetes performs a variety of tasks automatically--such as starting or restarting containers, scaling the number of replicas of a given application, and more. The Kubernetes Control Plane consists of a collection of processes running on your cluster:
|
||||
|
||||
* The **Kubernetes Master** is a collection of three processes that run on a single node in your cluster, which is designated as the master node. Those processes are: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) and [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
* Each individual non-master node in your cluster runs two processes:
|
||||
* **[kubelet](/docs/admin/kubelet/)**, which communicates with the Kubernetes Master.
|
||||
* **[kube-proxy](/docs/admin/kube-proxy/)**, a network proxy which reflects Kubernetes networking services on each node.
|
||||
|
||||
## Kubernetes objects
|
||||
|
||||
Kubernetes contains a number of abstractions that represent the state of your system: deployed containerized applications and workloads, their associated network and disk resources, and other information about what your cluster is doing. These abstractions are represented by objects in the Kubernetes API. See [Understanding Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) for more details.
|
||||
|
||||
The basic Kubernetes objects include:
|
||||
|
||||
* [Pod](/docs/concepts/workloads/pods/pod-overview/)
|
||||
* [Service](/docs/concepts/services-networking/service/)
|
||||
* [Volume](/docs/concepts/storage/volumes/)
|
||||
* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/)
|
||||
|
||||
Kubernetes also contains higher-level abstractions that rely on [controllers](/docs/concepts/architecture/controller/) to build upon the basic objects, and provide additional functionality and convenience features. These include:
|
||||
|
||||
* [Deployment](/docs/concepts/workloads/controllers/deployment/)
|
||||
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [Job](/docs/concepts/workloads/controllers/job/)
|
||||
|
||||
## Kubernetes Control Plane
|
||||
|
||||
The various parts of the Kubernetes Control Plane, such as the Kubernetes Master and kubelet processes, govern how Kubernetes communicates with your cluster. The Control Plane maintains a record of all of the Kubernetes Objects in the system, and runs continuous control loops to manage those objects' state. At any given time, the Control Plane's control loops will respond to changes in the cluster and work to make the actual state of all the objects in the system match the desired state that you provided.
|
||||
|
||||
For example, when you use the Kubernetes API to create a Deployment, you provide a new desired state for the system. The Kubernetes Control Plane records that object creation, and carries out your instructions by starting the required applications and scheduling them to cluster nodes--thus making the cluster's actual state match the desired state.
|
||||
|
||||
### Kubernetes Master
|
||||
|
||||
The Kubernetes master is responsible for maintaining the desired state for your cluster. When you interact with Kubernetes, such as by using the `kubectl` command-line interface, you're communicating with your cluster's Kubernetes master.
|
||||
|
||||
> The "master" refers to a collection of processes managing the cluster state. Typically all these processes run on a single node in the cluster, and this node is also referred to as the master. The master can also be replicated for availability and redundancy.
|
||||
|
||||
### Kubernetes Nodes
|
||||
|
||||
The nodes in a cluster are the machines (VMs, physical servers, etc) that run your applications and cloud workflows. The Kubernetes master controls each node; you'll rarely interact with nodes directly.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
If you would like to write a concept page, see
|
||||
[Page Content Types](/docs/contribute/style/page-content-types/#concept)
|
||||
for information about the concept page types.
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Cluster Architecture"
|
||||
weight: 30
|
||||
description: >
|
||||
The architectural concepts behind Kubernetes.
|
||||
---
|
||||
|
||||
|
||||
Executable → Regular
+70
-1
@@ -1,5 +1,74 @@
|
||||
---
|
||||
title: "Cluster Administration"
|
||||
title: Cluster Administration
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
weight: 100
|
||||
content_type: concept
|
||||
description: >
|
||||
Lower-level detail relevant to creating or administering a Kubernetes cluster.
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Planning a cluster
|
||||
|
||||
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
|
||||
|
||||
{{< note >}}
|
||||
Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
{{< /note >}}
|
||||
|
||||
Before choosing a guide, here are some considerations:
|
||||
|
||||
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
|
||||
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
|
||||
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
|
||||
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
|
||||
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
|
||||
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
|
||||
latter, choose an actively-developed distro. Some distros only use binary releases, but
|
||||
offer a greater variety of choices.
|
||||
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
|
||||
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) 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.
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
|
||||
## Securing a cluster
|
||||
|
||||
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
|
||||
|
||||
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
|
||||
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
|
||||
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
|
||||
|
||||
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
|
||||
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
|
||||
|
||||
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
|
||||
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
|
||||
### Securing the kubelet
|
||||
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## Optional Cluster Services
|
||||
|
||||
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
|
||||
|
||||
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
|
||||
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
title: Cluster Administration Overview
|
||||
content_type: concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
The cluster administration overview is for anyone creating or administering a Kubernetes cluster.
|
||||
It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/).
|
||||
|
||||
|
||||
<!-- body -->
|
||||
## Planning a cluster
|
||||
|
||||
See the guides in [Setup](/docs/setup/) for examples of how to plan, set up, and configure Kubernetes clusters. The solutions listed in this article are called *distros*.
|
||||
|
||||
Before choosing a guide, here are some considerations:
|
||||
|
||||
- Do you just want to try out Kubernetes on your computer, or do you want to build a high-availability, multi-node cluster? Choose distros best suited for your needs.
|
||||
- Will you be using **a hosted Kubernetes cluster**, such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or **hosting your own cluster**?
|
||||
- Will your cluster be **on-premises**, or **in the cloud (IaaS)**? Kubernetes does not directly support hybrid clusters. Instead, you can set up multiple clusters.
|
||||
- **If you are configuring Kubernetes on-premises**, consider which [networking model](/docs/concepts/cluster-administration/networking/) fits best.
|
||||
- Will you be running Kubernetes on **"bare metal" hardware** or on **virtual machines (VMs)**?
|
||||
- Do you **just want to run a cluster**, or do you expect to do **active development of Kubernetes project code**? If the
|
||||
latter, choose an actively-developed distro. Some distros only use binary releases, but
|
||||
offer a greater variety of choices.
|
||||
- Familiarize yourself with the [components](/docs/admin/cluster-components/) needed to run a cluster.
|
||||
|
||||
Note: Not all distros are actively maintained. Choose distros which have been tested with a recent version of Kubernetes.
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) 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.
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/nodes/node/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
|
||||
## Securing a cluster
|
||||
|
||||
* [Certificates](/docs/concepts/cluster-administration/certificates/) describes the steps to generate certificates using different tool chains.
|
||||
|
||||
* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) describes the environment for Kubelet managed containers on a Kubernetes node.
|
||||
|
||||
* [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) describes how to set up permissions for users and service accounts.
|
||||
|
||||
* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
|
||||
|
||||
* [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
|
||||
|
||||
* [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
|
||||
|
||||
* [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
|
||||
|
||||
* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
|
||||
|
||||
### Securing the kubelet
|
||||
* [Master-Node communication](/docs/concepts/architecture/master-node-communication/)
|
||||
* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## Optional Cluster Services
|
||||
|
||||
* [DNS Integration](/docs/concepts/services-networking/dns-pod-service/) describes how to resolve a DNS name directly to a Kubernetes service.
|
||||
|
||||
* [Logging and Monitoring Cluster Activity](/docs/concepts/cluster-administration/logging/) explains how logging in Kubernetes works and how to implement it.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Configuration"
|
||||
weight: 80
|
||||
description: >
|
||||
Resources that Kubernetes provides for configuring Pods.
|
||||
---
|
||||
|
||||
|
||||
Executable → Regular
+40
-1
@@ -1,5 +1,44 @@
|
||||
---
|
||||
title: "Containers"
|
||||
title: Containers
|
||||
weight: 40
|
||||
description: Technology for packaging an application along with its runtime dependencies.
|
||||
reviewers:
|
||||
- erictune
|
||||
- thockin
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Each container that you run is repeatable; the standardization from having
|
||||
dependencies included means that you get the same behavior wherever you
|
||||
run it.
|
||||
|
||||
Containers decouple applications from underlying host infrastructure.
|
||||
This makes deployment easier in different cloud or OS environments.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Container images
|
||||
A [container image](/docs/concepts/containers/images/) is a ready-to-run
|
||||
software package, containing everything needed to run an application:
|
||||
the code and any runtime it requires, application and system libraries,
|
||||
and default values for any essential settings.
|
||||
|
||||
By design, a container is immutable: you cannot change the code of a
|
||||
container that is already running. If you have a containerized application
|
||||
and want to make changes, you need to build a new container that includes
|
||||
the change, then recreate the container to start from the updated image.
|
||||
|
||||
## Container runtimes
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [container images](/docs/concepts/containers/images/)
|
||||
* Read about [Pods](/docs/concepts/workloads/pods/)
|
||||
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
reviewers:
|
||||
- erictune
|
||||
- thockin
|
||||
title: Containers overview
|
||||
content_type: concept
|
||||
weight: 1
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Containers are a technology for packaging the (compiled) code for an
|
||||
application along with the dependencies it needs at run time. Each
|
||||
container that you run is repeatable; the standardization from having
|
||||
dependencies included means that you get the same behavior wherever you
|
||||
run it.
|
||||
|
||||
Containers decouple applications from underlying host infrastructure.
|
||||
This makes deployment easier in different cloud or OS environments.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Container images
|
||||
A [container image](/docs/concepts/containers/images/) is a ready-to-run
|
||||
software package, containing everything needed to run an application:
|
||||
the code and any runtime it requires, application and system libraries,
|
||||
and default values for any essential settings.
|
||||
|
||||
By design, a container is immutable: you cannot change the code of a
|
||||
container that is already running. If you have a containerized application
|
||||
and want to make changes, you need to build a new container that includes
|
||||
the change, then recreate the container to start from the updated image.
|
||||
|
||||
## Container runtimes
|
||||
|
||||
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [container images](/docs/concepts/containers/images/)
|
||||
* Read about [Pods](/docs/concepts/workloads/pods/)
|
||||
|
||||
@@ -1,4 +1,212 @@
|
||||
---
|
||||
title: Extending Kubernetes
|
||||
weight: 110
|
||||
description: Different ways to change the behavior of your Kubernetes cluster.
|
||||
reviewers:
|
||||
- erictune
|
||||
- lavalamp
|
||||
- cheftako
|
||||
- chenopis
|
||||
content_type: concept
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Kubernetes is highly configurable and extensible. As a result,
|
||||
there is rarely a need to fork or submit patches to the Kubernetes
|
||||
project code.
|
||||
|
||||
This guide describes the options for customizing a Kubernetes
|
||||
cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to
|
||||
understand how to adapt their Kubernetes cluster to the needs of
|
||||
their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it
|
||||
useful as an introduction to what extension points and patterns
|
||||
exist, and their trade-offs and limitations.
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Overview
|
||||
|
||||
Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions.
|
||||
|
||||
## Configuration
|
||||
|
||||
*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
|
||||
|
||||
* [kubelet](/docs/admin/kubelet/)
|
||||
* [kube-apiserver](/docs/admin/kube-apiserver/)
|
||||
* [kube-controller-manager](/docs/admin/kube-controller-manager/)
|
||||
* [kube-scheduler](/docs/admin/kube-scheduler/).
|
||||
|
||||
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
|
||||
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
|
||||
## Extensions
|
||||
|
||||
Extensions are software components that extend and deeply integrate with Kubernetes.
|
||||
They adapt it to support new types and new kinds of hardware.
|
||||
|
||||
Most cluster administrators will use a hosted or distribution
|
||||
instance of Kubernetes. As a result, most Kubernetes users will not need to
|
||||
install extensions and fewer will need to author new ones.
|
||||
|
||||
## Extension Patterns
|
||||
|
||||
Kubernetes is designed to be automated by writing client programs. Any
|
||||
program that reads and/or writes to the Kubernetes API can provide useful
|
||||
automation. *Automation* can run on the cluster or off it. By following
|
||||
the guidance in this doc you can write highly available and robust automation.
|
||||
Automation generally works with any Kubernetes cluster, including hosted
|
||||
clusters and managed installations.
|
||||
|
||||
There is a specific pattern for writing client programs that work well with
|
||||
Kubernetes called the *Controller* pattern. Controllers typically read an
|
||||
object's `.spec`, possibly do things, and then update the object's `.status`.
|
||||
|
||||
A controller is a client of Kubernetes. When Kubernetes is the client and
|
||||
calls out to a remote service, it is called a *Webhook*. The remote service
|
||||
is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
|
||||
failure.
|
||||
|
||||
In the webhook model, Kubernetes makes a network request to a remote service.
|
||||
In the *Binary Plugin* model, Kubernetes executes a binary (program).
|
||||
Binary plugins are used by the kubelet (e.g. [Flex Volume
|
||||
Plugins](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
|
||||
and [Network
|
||||
Plugins](/docs/concepts/cluster-administration/network-plugins/))
|
||||
and by kubectl.
|
||||
|
||||
Below is a diagram showing how the extension points interact with the
|
||||
Kubernetes control plane.
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
|
||||
|
||||
<!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
|
||||
|
||||
|
||||
## Extension Points
|
||||
|
||||
This diagram shows the extension points in a Kubernetes system.
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
|
||||
|
||||
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
|
||||
|
||||
1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.
|
||||
2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/overview/extending#api-access-extensions) section.
|
||||
3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
|
||||
4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section.
|
||||
5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.
|
||||
6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/overview/extending#network-plugins) allow for different implementations of pod networking.
|
||||
7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/overview/extending#storage-plugins).
|
||||
|
||||
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
|
||||
|
||||
|
||||
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
|
||||
|
||||
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
|
||||
|
||||
## API Extensions
|
||||
### User-Defined Types
|
||||
|
||||
Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`.
|
||||
|
||||
Do not use a Custom Resource as data storage for application, user, or monitoring data.
|
||||
|
||||
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
|
||||
|
||||
|
||||
### Combining New APIs with Automation
|
||||
|
||||
The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies.
|
||||
|
||||
### Changing Built-in Resources
|
||||
|
||||
When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups.
|
||||
Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do.
|
||||
|
||||
|
||||
### API Access Extensions
|
||||
|
||||
When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/) for more on this flow.
|
||||
|
||||
Each of these steps offers extension points.
|
||||
|
||||
Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
|
||||
|
||||
### Authentication
|
||||
|
||||
[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
|
||||
|
||||
Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
|
||||
|
||||
|
||||
### Authorization
|
||||
|
||||
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
|
||||
|
||||
|
||||
### Dynamic Admission Control
|
||||
|
||||
After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions:
|
||||
|
||||
* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers.
|
||||
* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates.
|
||||
|
||||
## Infrastructure Extensions
|
||||
|
||||
|
||||
### Storage Plugins
|
||||
|
||||
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
|
||||
) allow users to mount volume types without built-in support by having the
|
||||
Kubelet call a Binary Plugin to mount the volume.
|
||||
|
||||
|
||||
### Device Plugins
|
||||
|
||||
Device plugins allow a node to discover new Node resources (in addition to the
|
||||
builtin ones like cpu and memory) via a [Device
|
||||
Plugin](/docs/concepts/cluster-administration/device-plugins/).
|
||||
|
||||
|
||||
### Network Plugins
|
||||
|
||||
Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
|
||||
|
||||
### Scheduler Extensions
|
||||
|
||||
The scheduler is a special type of controller that watches pods, and assigns
|
||||
pods to nodes. The default scheduler can be replaced entirely, while
|
||||
continuing to use other Kubernetes components, or [multiple
|
||||
schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/)
|
||||
can run at the same time.
|
||||
|
||||
This is a significant undertaking, and almost all Kubernetes users find they
|
||||
do not need to modify the scheduler.
|
||||
|
||||
The scheduler also supports a
|
||||
[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)
|
||||
that permits a webhook backend (scheduler extension) to filter and prioritize
|
||||
the nodes chosen for a pod.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
|
||||
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
* Learn more about Infrastructure extensions
|
||||
* [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
|
||||
* [Device Plugins](/docs/concepts/cluster-administration/device-plugins/)
|
||||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
---
|
||||
title: "Overview"
|
||||
weight: 20
|
||||
---
|
||||
description: Get a high-level outline of Kubernetes and the components it is built from.
|
||||
---
|
||||
|
||||
@@ -3,6 +3,9 @@ reviewers:
|
||||
- lavalamp
|
||||
title: Kubernetes Components
|
||||
content_type: concept
|
||||
description: >
|
||||
A Kubernetes cluster consists of the components that represent the control plane
|
||||
and a set of machines called nodes.
|
||||
weight: 20
|
||||
card:
|
||||
name: concepts
|
||||
|
||||
@@ -4,6 +4,9 @@ reviewers:
|
||||
title: The Kubernetes API
|
||||
content_type: concept
|
||||
weight: 30
|
||||
description: >
|
||||
The Kubernetes API lets you query and manipulate the state of objects in Kubernetes.
|
||||
The core of Kubernetes' control plane is the API server and the HTTP API that it exposes. Users, the different parts of your cluster, and external components all communicate with one another through the API server.
|
||||
card:
|
||||
name: concepts
|
||||
weight: 30
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Working with Kubernetes Objects"
|
||||
weight: 40
|
||||
description: >
|
||||
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster.
|
||||
Learn about the Kubernetes object model and how to work with these objects.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: "Policies"
|
||||
weight: 90
|
||||
description: >
|
||||
Policies you can configure that apply to groups of resources.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
---
|
||||
title: "Scheduling and Eviction"
|
||||
weight: 90
|
||||
description: >
|
||||
In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them.
|
||||
Eviction is the process of proactively failing one or more Pods on resource-starved Nodes.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
---
|
||||
title: "Security"
|
||||
weight: 81
|
||||
description: >
|
||||
Concepts for keeping your cloud-native workload secure.
|
||||
---
|
||||
|
||||
@@ -1,5 +1,12 @@
|
||||
---
|
||||
title: "Services, Load Balancing, and Networking"
|
||||
weight: 60
|
||||
description: >
|
||||
Concepts and resources behind networking in Kubernetes.
|
||||
---
|
||||
|
||||
Kubernetes networking addresses four concerns:
|
||||
- Containers within a Pod use networking to communicate via loopback.
|
||||
- Cluster networking provides communication between different Pods.
|
||||
- The Service resource lets you expose an application running in Pods to be reachable from outside your cluster.
|
||||
- You can also use Services to publish services only for consumption inside your cluster.
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Storage"
|
||||
weight: 70
|
||||
description: >
|
||||
Ways to provide both long-term and temporary storage to Pods in your cluster.
|
||||
---
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
---
|
||||
title: "Workloads"
|
||||
weight: 50
|
||||
description: >
|
||||
Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
|
||||
---
|
||||
|
||||
|
||||
@@ -254,6 +254,7 @@ spec:
|
||||
request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
|
||||
usages:
|
||||
- client auth
|
||||
EOF
|
||||
```
|
||||
|
||||
Some points to note:
|
||||
|
||||
@@ -101,12 +101,12 @@ If needed, you can expand the **Advanced options** section where you can specify
|
||||
|
||||
Example:
|
||||
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
```conf
|
||||
release=1.0
|
||||
tier=frontend
|
||||
environment=pod
|
||||
track=stable
|
||||
```
|
||||
|
||||
- **Namespace**: Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called [namespaces](/docs/tasks/administer-cluster/namespaces/). They let you partition resources into logically named groups.
|
||||
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Volume
|
||||
id: volume
|
||||
date: 2018-04-12
|
||||
full_link: /fr/docs/concepts/storage/volumes/
|
||||
short_description: >
|
||||
Un répertoire contenant des données, accessible aux conteneurs d'un pod.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
Un répertoire contenant des données, accessible aux {{< glossary_tooltip text="conteneurs" term_id="container" >}} d'un {{< glossary_tooltip term_id="pod" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Un volume Kubernetes vit aussi longtemps que le pod qui le contient. Par conséquent, un volume survit à tous les conteneurs qui s'exécutent dans le pod, et les données contenues dans le volume sont préservées lors des redémarrages du conteneur.
|
||||
|
||||
Voir [stockage](/fr/docs/concepts/storage/) pour plus d'informations.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Workload
|
||||
id: workloads
|
||||
date: 2019-02-13
|
||||
full_link: /fr/docs/concepts/workloads/
|
||||
short_description: >
|
||||
Une charge de travail (workload) est une application exécutée sur Kubernetes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Une charge de travail (workload) est une application exécutée sur Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Divers objets de base qui représentent différents types ou parties d'une charge de travail
|
||||
incluent les objets DaemonSet, Deployment, Job, ReplicaSet et StatefulSet.
|
||||
|
||||
Par exemple, une charge de travail constituée d'un serveur Web et d'une base de données peut exécuter la
|
||||
base de données dans un {{< glossary_tooltip term_id="StatefulSet" >}} et le serveur web
|
||||
dans un {{< glossary_tooltip term_id="Deployment" >}}.
|
||||
@@ -235,13 +235,13 @@ minikube start --vm-driver=<nom_du_pilote>
|
||||
|
||||
Minikube prend en charge les pilotes suivants:
|
||||
{{< note >}}
|
||||
Voir [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) pour plus de détails sur les pilotes pris en charge et comment installer les plugins.
|
||||
Voir [DRIVERS](https://minikube.sigs.k8s.io/docs/drivers/) pour plus de détails sur les pilotes pris en charge et comment installer les plugins.
|
||||
{{< /note >}}
|
||||
|
||||
* virtualbox
|
||||
* vmwarefusion
|
||||
* kvm2 ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver))
|
||||
* hyperkit ([installation du pilote](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
|
||||
* kvm2 ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#kvm2-driver))
|
||||
* hyperkit ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperkit-driver))
|
||||
* hyperv ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#hyperv-driver))
|
||||
Notez que l'adresse IP ci-dessous est dynamique et peut changer. Il peut être récupéré avec `minikube ip`.
|
||||
* vmware ([installation du pilote](https://minikube.sigs.k8s.io/docs/drivers/#vmware-unified-driver)) (VMware unified driver)
|
||||
|
||||
@@ -0,0 +1,283 @@
|
||||
---
|
||||
title: Configurer les comptes de service pour les pods
|
||||
content_template: templates/task
|
||||
weight: 90
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Un ServiceAccount (compte de service) fournit une identité pour les processus qui s'exécutent dans un Pod.
|
||||
|
||||
*Ceci est une introduction aux comptes de service pour les utilisateurs. Voir aussi
|
||||
[Guide de l'administrateur du cluster des comptes de service](/docs/reference/access-authn-authz/service-accounts-admin/).*
|
||||
|
||||
{{< note >}}
|
||||
Ce document décrit le comportement des comptes de service dans un cluster mis en place conformément aux recommandations du projet Kubernetes. L'administrateur de votre cluster a peut-être personnalisé le comportement dans votre cluster, dans ce cas cette documentation pourrait être non applicable.
|
||||
{{< /note >}}
|
||||
|
||||
Lorsque vous (un humain) accédez au cluster (par exemple, en utilisant `kubectl`), vous êtes
|
||||
authentifié par l'apiserver en tant que compte d'utilisateur particulier (actuellement, il s'agit
|
||||
généralement de l'utilisateur `admin`, à moins que votre administrateur de cluster n'ait personnalisé votre cluster). Les processus dans les conteneurs dans les Pods peuvent également contacter l'apiserver. Dans ce cas, ils sont authentifiés en tant que compte de service particulier (par exemple, `default`).
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## Utiliser le compte de service par défaut pour accéder au API server.
|
||||
|
||||
Si vous obtenez le raw json ou yaml pour un Pod que vous avez créé (par exemple, `kubectl get pods/<podname> -o yaml`), vous pouvez voir que le champ `spec.serviceAccountName` a été [automatiquement assigné](/docs/user-guide/working-with-resources/#resources-are-automatically-modified).
|
||||
|
||||
Vous pouvez accéder à l'API depuis l'intérieur d'un Pod en utilisant les identifiants de compte de service montés automatiquement, comme décrit dans [Accès au cluster](/docs/user-guide/accessing-the-cluster/#accessing-the-api-from-a-pod).
|
||||
Les permissions API du compte de service dépendent du [plugin d'autorisation et de la politique](/docs/reference/access-authn-authz/authorization/#authorization-modules) en usage.
|
||||
|
||||
Dans la version 1.6+, vous pouvez choisir de ne pas utiliser le montage automatique des identifiants API pour un compte de service en définissant `automountServiceAccountToken: false` sur le compte de service :
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: build-robot
|
||||
automountServiceAccountToken: false
|
||||
...
|
||||
```
|
||||
|
||||
Dans la version 1.6+, vous pouvez également choisir de ne pas monter automatiquement les identifiants API pour un Pod particulier :
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: my-pod
|
||||
spec:
|
||||
serviceAccountName: build-robot
|
||||
automountServiceAccountToken: false
|
||||
...
|
||||
```
|
||||
|
||||
La spéc de Pod a prépondérance par rapport au compte de service si les deux spécifient la valeur `automountServiceAccountToken`.
|
||||
|
||||
## Utiliser plusieurs comptes de services.
|
||||
|
||||
Chaque Namespace possède une ressource ServiceAccount par défaut appelée `default`.
|
||||
Vous pouvez lister cette ressource et toutes les autres ressources de ServiceAccount dans le Namespace avec cette commande :
|
||||
|
||||
```shell
|
||||
kubectl get serviceAccounts
|
||||
```
|
||||
La sortie est comme la suivante :
|
||||
|
||||
```
|
||||
NAME SECRETS AGE
|
||||
default 1 1d
|
||||
```
|
||||
|
||||
Vous pouvez créer des objets ServiceAccount supplémentaires comme ceci :
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: build-robot
|
||||
EOF
|
||||
```
|
||||
|
||||
Si vous obtenez un dump complet de l'objet compte de service, par exemple :
|
||||
|
||||
```shell
|
||||
kubectl get serviceaccounts/build-robot -o yaml
|
||||
```
|
||||
La sortie est comme la suivante :
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
creationTimestamp: 2015-06-16T00:12:59Z
|
||||
name: build-robot
|
||||
namespace: default
|
||||
resourceVersion: "272500"
|
||||
selfLink: /api/v1/namespaces/default/serviceaccounts/build-robot
|
||||
uid: 721ab723-13bc-11e5-aec2-42010af0021e
|
||||
secrets:
|
||||
- name: build-robot-token-bvbk5
|
||||
```
|
||||
|
||||
vous verrez alors qu'un token a été automatiquement créé et est référencé par le compte de service.
|
||||
|
||||
Vous pouvez utiliser des plugins d'autorisation pour [définir les permissions sur les comptes de service](/docs/reference/access-authn-authz/rbac/#service-account-permissions).
|
||||
|
||||
Pour utiliser un compte de service autre que par défaut, il suffit de spécifier le `spec.serviceAccountName` d'un Pod au nom du compte de service que vous souhaitez utiliser.
|
||||
|
||||
Le compte de service doit exister au moment de la création du Pod, sinon il sera rejeté.
|
||||
|
||||
Vous ne pouvez pas mettre à jour le compte de service d'un Pod déjà créé.
|
||||
|
||||
Vous pouvez supprimer le compte de service de cet exemple comme ceci :
|
||||
|
||||
```shell
|
||||
kubectl delete serviceaccount/build-robot
|
||||
```
|
||||
|
||||
## Créez manuellement un API token de compte de service.
|
||||
|
||||
Supposons que nous ayons un compte de service existant nommé "build-robot" comme mentionné ci-dessus,et que nous allons créer un nouveau Secret manuellement.
|
||||
|
||||
```shell
|
||||
kubectl apply -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: build-robot-secret
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: build-robot
|
||||
type: kubernetes.io/service-account-token
|
||||
EOF
|
||||
```
|
||||
|
||||
Vous pouvez maintenant confirmer que le Secret nouvellement construit est rempli d'un API token pour le compte de service "build-robot".
|
||||
|
||||
Tous les tokens pour des comptes de service non-existants seront nettoyés par le contrôleur de token.
|
||||
|
||||
```shell
|
||||
kubectl describe secrets/build-robot-secret
|
||||
```
|
||||
La sortie est comme la suivante :
|
||||
|
||||
```
|
||||
Name: build-robot-secret
|
||||
Namespace: default
|
||||
Labels: <none>
|
||||
Annotations: kubernetes.io/service-account.name=build-robot
|
||||
kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
|
||||
|
||||
Type: kubernetes.io/service-account-token
|
||||
|
||||
Data
|
||||
====
|
||||
ca.crt: 1338 bytes
|
||||
namespace: 7 bytes
|
||||
token: ...
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Le contenu de `token` est éludé ici.
|
||||
{{< /note >}}
|
||||
|
||||
## Ajouter ImagePullSecrets à un compte de service
|
||||
|
||||
Tout d'abord, créez un imagePullSecret, comme décrit [ici](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
Puis, vérifiez qu'il a été créé. Par exemple :
|
||||
|
||||
```shell
|
||||
kubectl get secrets myregistrykey
|
||||
```
|
||||
|
||||
La sortie est comme la suivante :
|
||||
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
myregistrykey kubernetes.io/.dockerconfigjson 1 1d
|
||||
```
|
||||
|
||||
Ensuite, modifiez le compte de service par défaut du Namespace pour utiliser ce Secret comme un `imagePullSecret`.
|
||||
|
||||
```shell
|
||||
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
|
||||
```
|
||||
|
||||
La version interactive nécessite un traitement manuel :
|
||||
|
||||
```shell
|
||||
kubectl get serviceaccounts default -o yaml > ./sa.yaml
|
||||
```
|
||||
|
||||
La sortie du fichier `sa.yaml` est similaire à celle-ci :
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
creationTimestamp: 2015-08-07T22:02:39Z
|
||||
name: default
|
||||
namespace: default
|
||||
resourceVersion: "243024"
|
||||
selfLink: /api/v1/namespaces/default/serviceaccounts/default
|
||||
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
|
||||
secrets:
|
||||
- name: default-token-uudge
|
||||
```
|
||||
|
||||
En utilisant l'éditeur de votre choix (par exemple `vi`), ouvrez le fichier `sa.yaml`, supprimez la ligne avec la clé `resourceVersion`, ajoutez les lignes avec `imagePullSecrets:` et sauvegardez.
|
||||
|
||||
La sortie du fichier `sa.yaml` est similaire à celle-ci :
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
creationTimestamp: 2015-08-07T22:02:39Z
|
||||
name: default
|
||||
namespace: default
|
||||
selfLink: /api/v1/namespaces/default/serviceaccounts/default
|
||||
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
|
||||
secrets:
|
||||
- name: default-token-uudge
|
||||
imagePullSecrets:
|
||||
- name: myregistrykey
|
||||
```
|
||||
|
||||
Enfin, remplacez le compte de service par le nouveau fichier `sa.yaml` mis à jour.
|
||||
|
||||
```shell
|
||||
kubectl replace serviceaccount default -f ./sa.yaml
|
||||
```
|
||||
|
||||
Maintenant, tous les nouveaux Pods créés dans le Namespace courant auront ceci ajouté à leurs spécifications :
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
imagePullSecrets:
|
||||
- name: myregistrykey
|
||||
```
|
||||
|
||||
## Projection du volume des tokens de compte de service
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
Ce ServiceAccountTokenVolumeProjection est __beta__ en 1.12 et
|
||||
activé en passant tous les paramètres suivants au serveur API :
|
||||
|
||||
* `--service-account-issuer`
|
||||
* `--service-account-signing-key-file`
|
||||
* `--service-account-api-audiences`
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
Kubelet peut également projeter un token de compte de service dans un Pod. Vous pouvez spécifier les propriétés souhaitées du token, telles que l'audience et la durée de validité.
|
||||
Ces propriétés ne sont pas configurables sur le compte de service par défaut. Le token de compte de service devient également invalide par l'API lorsque le Pod ou le ServiceAccount est supprimé
|
||||
|
||||
Ce comportement est configuré sur un PodSpec utilisant un type de ProjectedVolume appelé
|
||||
[ServiceAccountToken](/docs/concepts/storage/volumes/#projected). Pour fournir un
|
||||
Pod avec un token avec une audience de "vault" et une durée de validité de deux heures, vous devriez configurer ce qui suit dans votre PodSpec :
|
||||
|
||||
{{< codenew file="pods/pod-projected-svc-token.yaml" >}}
|
||||
|
||||
Créez le Pod
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
|
||||
```
|
||||
|
||||
Kubelet demandera et stockera le token a la place du Pod, rendra le token disponible pour le Pod à un chemin d'accès configurable, et rafraîchissez le token à l'approche de son expiration. Kubelet fait tourner le token de manière proactive s'il est plus vieux que 80% de son TTL total, ou si le token est plus vieux que 24 heures.
|
||||
|
||||
L'application est responsable du rechargement du token lorsque celui ci est renouvelé. Un rechargement périodique (par ex. toutes les 5 minutes) est suffisant pour la plupart des cas d'utilisation.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -78,7 +78,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise
|
||||
Pod utilise un conteneur basé sur l'image Docker fournie.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node
|
||||
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
|
||||
```
|
||||
|
||||
2. Affichez le déploiement :
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
volumeMounts:
|
||||
- mountPath: /var/run/secrets/tokens
|
||||
name: vault-token
|
||||
serviceAccountName: build-robot
|
||||
volumes:
|
||||
- name: vault-token
|
||||
projected:
|
||||
sources:
|
||||
- serviceAccountToken:
|
||||
path: vault-token
|
||||
expirationSeconds: 7200
|
||||
audience: vault
|
||||
@@ -40,7 +40,7 @@ dan objek yang sudah dibuat tidak dapat diubah lagi definisinya.
|
||||
|
||||
Administrator dapat memberikan spesifikasi StorageClass _default_ bagi
|
||||
PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_:
|
||||
kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#class-1)
|
||||
kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)
|
||||
untuk penjelasan lebih lanjut.
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -3,7 +3,7 @@ title: 理解 Kubernetes 对象
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: 概念
|
||||
name: concepts
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
@@ -150,7 +150,7 @@ The following resource types are supported:
|
||||
In addition to the resources mentioned above, in release 1.10, quota support for
|
||||
[extended resources](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) is added.
|
||||
-->
|
||||
除上述资源外,在 Kubernetes 1.10 版本中,还添加了对[扩展资源](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)的支持。
|
||||
除上述资源外,在 Kubernetes 1.10 版本中,还添加了对[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#扩展资源-extended-resources)的支持。
|
||||
|
||||
<!--
|
||||
As overcommit is not allowed for extended resources, it makes no sense to specify both `requests`
|
||||
@@ -820,7 +820,7 @@ plugins:
|
||||
limitedResources:
|
||||
- resource: pods
|
||||
matchScopes:
|
||||
- scopeName: PriorityClass
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
@@ -839,7 +839,7 @@ plugins:
|
||||
limitedResources:
|
||||
- resource: pods
|
||||
matchScopes:
|
||||
- scopeName: PriorityClass
|
||||
- scopeName: PriorityClass
|
||||
operator: In
|
||||
values: ["cluster-services"]
|
||||
```
|
||||
@@ -888,5 +888,3 @@ See a [detailed example for how to use resource quota](/docs/tasks/administer-cl
|
||||
See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information.
|
||||
-->
|
||||
查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。
|
||||
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Pod 概览
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: 概念
|
||||
name: concepts
|
||||
weight: 60
|
||||
---
|
||||
|
||||
|
||||
@@ -13,47 +13,59 @@ menu:
|
||||
title: "文档"
|
||||
weight: 20
|
||||
post: >
|
||||
<p>通过演练,示例和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>!</p>
|
||||
overview: >
|
||||
<!-- Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>). -->
|
||||
Kubernetes 是一个开源容器编排引擎,用于容器化应用的自动化部署、扩展和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。
|
||||
<!-- cards:
|
||||
- name: concepts
|
||||
title: "Understand the basics"
|
||||
description: "Learn about Kubernetes and its fundamental concepts."
|
||||
button: "Learn Concepts"
|
||||
button_path: "/docs/concepts"
|
||||
- name: tutorials
|
||||
title: "Try Kubernetes"
|
||||
description: "Follow tutorials to learn how to deploy applications in Kubernetes."
|
||||
button: "View Tutorials"
|
||||
button_path: "/docs/tutorials"
|
||||
- name: setup
|
||||
title: "Set up a cluster"
|
||||
description: "Get Kubernetes running based on your resources and needs."
|
||||
button: "Set up Kubernetes"
|
||||
button_path: "/docs/setup"
|
||||
- name: tasks
|
||||
title: "Learn how to use Kubernetes"
|
||||
description: "Look up common tasks and how to perform them using a short sequence of steps."
|
||||
button: "View Tasks"
|
||||
button_path: "/docs/tasks"
|
||||
- name: reference
|
||||
title: Look up reference information
|
||||
description: Browse terminology, command line syntax, API resource types, and setup tool documentation.
|
||||
button: View Reference
|
||||
button_path: /docs/reference
|
||||
- name: contribute
|
||||
title: Contribute to the docs
|
||||
description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time.
|
||||
button: Contribute to the docs
|
||||
button_path: /docs/contribute
|
||||
- name: release-notes
|
||||
title: Release Notes
|
||||
description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
|
||||
- name: about
|
||||
title: About the documentation
|
||||
description: This website contains documentation for the current and previous 4 versions of Kubernetes. -->
|
||||
<p>通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以<a href="/editdocs/" data-auto-burger-exclude>帮助贡献文档</a>!</p>
|
||||
# description: >
|
||||
# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation.
|
||||
description: >
|
||||
Kubernetes 是一个开源的容器编排引擎,用来对容器化应用进行自动部署、 扩缩和管理。此开源项目由云原生计算基金会(CNCF)托管。
|
||||
# overview:
|
||||
# Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. The open source project is hosted by the Cloud Native Computing Foundation (<a href="https://www.cncf.io/about">CNCF</a>).
|
||||
overview:
|
||||
Kubernetes 是一个开源的容器编排引擎,用来对容器化应用进行自动化部署、 扩缩和管理。该项目托管在 <a href="https://www.cncf.io/about">CNCF</a>。
|
||||
# cards:
|
||||
# - name: concepts
|
||||
# title: "Understand the basics"
|
||||
# description: "Learn about Kubernetes and its fundamental concepts."
|
||||
# button: "Learn Concepts"
|
||||
# button_path: "/docs/concepts"
|
||||
# - name: tutorials
|
||||
# title: "Try Kubernetes"
|
||||
# description: "Follow tutorials to learn how to deploy applications in Kubernetes."
|
||||
# button: "View Tutorials"
|
||||
# button_path: "/docs/tutorials"
|
||||
# - name: setup
|
||||
# title: "Set up a cluster"
|
||||
# description: "Get Kubernetes running based on your resources and needs."
|
||||
# button: "Set up Kubernetes"
|
||||
# button_path: "/docs/setup"
|
||||
# - name: tasks
|
||||
# title: "Learn how to use Kubernetes"
|
||||
# description: "Look up common tasks and how to perform them using a short sequence of steps."
|
||||
# button: "View Tasks"
|
||||
# button_path: "/docs/tasks"
|
||||
# - name: training
|
||||
# title: "Training"
|
||||
# description: "Get certified in Kubernetes and make your cloud native projects successful!"
|
||||
# button: "View training"
|
||||
# button_path: "/training"
|
||||
# - name: reference
|
||||
# title: Look up reference information
|
||||
# description: Browse terminology, command line syntax, API resource types, and setup tool documentation.
|
||||
# button: View Reference
|
||||
# button_path: /docs/reference
|
||||
# - name: contribute
|
||||
# title: Contribute to the docs
|
||||
# description: Anyone can contribute, whether you’re new to the project or you’ve been around a long time.
|
||||
# button: Contribute to the docs
|
||||
# button_path: /docs/contribute
|
||||
# - name: release-notes
|
||||
# title: Release Notes
|
||||
# description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
|
||||
# button: "Download Kubernetes"
|
||||
# button_path: "/zh/docs/setup/release/notes"
|
||||
# - name: about
|
||||
# title: About the documentation
|
||||
# description: This website contains documentation for the current and previous 4 versions of Kubernetes.
|
||||
cards:
|
||||
- name: concepts
|
||||
title: "了解基本知识"
|
||||
@@ -75,20 +87,27 @@ cards:
|
||||
description: "查看常见任务以及如何使用简单步骤执行它们。"
|
||||
button: "查看任务"
|
||||
button_path: "/zh/docs/tasks"
|
||||
- name: training
|
||||
title: "培训"
|
||||
description: "通过 Kubernetes 认证,助你的云原生项目成功!"
|
||||
button: "查看培训"
|
||||
button_path: "/zh/training"
|
||||
- name: reference
|
||||
title: 参考
|
||||
description: 术语、命令行语法、API 资源类型和设置工具文档。
|
||||
title: 查阅参考信息
|
||||
description: 浏览术语、命令行语法、API 资源类型和安装工具文档。
|
||||
button: 查看参考
|
||||
button_path: /zh/docs/reference
|
||||
- name: contribute
|
||||
title: 为该文档作出贡献
|
||||
title: 为文档作贡献
|
||||
description: 任何人,无论对该项目熟悉与否,都能贡献自己的力量。
|
||||
button: 参与贡献
|
||||
button: 为文档作贡献
|
||||
button_path: /zh/docs/contribute
|
||||
- name: download
|
||||
title: 下载 Kubernetes
|
||||
description: 如果你正在安装或升级 Kubernetes 的话,最好参考最新的发行版说明。
|
||||
- name: release-notes
|
||||
title: 发布说明
|
||||
description: 如果你正在安装或升级 Kubernetes,最好参考最新的发布说明。
|
||||
button: "下载 Kubernetes"
|
||||
button_path: "/zh/docs/setup/release/notes"
|
||||
- name: about
|
||||
title: 关于文档
|
||||
description: 该网站包含了当前版本以及前 4 个版本的 Kubernetes 文档。
|
||||
description: 本网站包含了当前及前 4 个版本的 Kubernetes 文档。
|
||||
---
|
||||
|
||||
@@ -631,9 +631,9 @@ Example of a minimal response from a webhook to allow a request:
|
||||
* `allowed`,设置为 `true` 或 `false`
|
||||
|
||||
<!--
|
||||
Example of a minimal response from a webhook to forbid a request:
|
||||
Example of a minimal response from a webhook to allow a request:
|
||||
-->
|
||||
Webhook 禁止请求的最简单响应示例:
|
||||
Webhook 允许请求的最简单响应示例:
|
||||
|
||||
{{< tabs name="AdmissionReview_response_allow" >}}
|
||||
{{% tab name="admission.k8s.io/v1" %}}
|
||||
|
||||
@@ -1,14 +1,11 @@
|
||||
---
|
||||
approvers:
|
||||
- chenopis
|
||||
- abiogenesis-now
|
||||
title: 标准化词汇表
|
||||
layout: glossary
|
||||
noedit: true
|
||||
default_active_tag: fundamental
|
||||
weight: 5
|
||||
card:
|
||||
name: 参考
|
||||
name: reference
|
||||
weight: 10
|
||||
title: 词汇表
|
||||
---
|
||||
|
||||
@@ -1,9 +1,5 @@
|
||||
---
|
||||
title: kubectl 备忘单
|
||||
reviewers:
|
||||
- erictune
|
||||
- krousey
|
||||
- clove
|
||||
content_type: concept
|
||||
card:
|
||||
name: reference
|
||||
@@ -23,34 +19,42 @@ card:
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!-- See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath). -->
|
||||
也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
|
||||
<!--
|
||||
See also: [Kubectl Overview](/docs/reference/kubectl/overview/) and [JsonPath Guide](/docs/reference/kubectl/jsonpath).
|
||||
|
||||
This page is an overview of the `kubectl` command.
|
||||
-->
|
||||
另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。
|
||||
|
||||
<!-- This page is an overview of the `kubectl` command. -->
|
||||
本页面是 `kubectl` 命令的概述。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!-- # kubectl - Cheat Sheet -->
|
||||
## kubectl - 备忘单
|
||||
<!--
|
||||
# kubectl - Cheat Sheet
|
||||
|
||||
## Kubectl Autocomplete
|
||||
-->
|
||||
# kubectl - 备忘单
|
||||
|
||||
<!-- ## Kubectl Autocomplete -->
|
||||
## Kubectl 自动补全
|
||||
|
||||
### BASH
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first.
|
||||
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.
|
||||
``` -->
|
||||
```
|
||||
|
||||
You can also use a shorthand alias for `kubectl` that also works with completion:
|
||||
-->
|
||||
```bash
|
||||
source <(kubectl completion bash) # 在 bash 中设置当前 shell 的自动补全,要先安装 bash-completion 包。
|
||||
echo "source <(kubectl completion bash)" >> ~/.bashrc # 在您的 bash shell 中永久的添加自动补全
|
||||
```
|
||||
|
||||
<!-- You can also use a shorthand alias for `kubectl` that also works with completion: -->
|
||||
您还可以为 `kubectl` 使用一个速记别名,该别名也可以与 completion 一起使用:
|
||||
|
||||
```bash
|
||||
@@ -60,25 +64,32 @@ complete -F __start_kubectl k
|
||||
|
||||
### ZSH
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell
|
||||
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # add autocomplete permanently to your zsh shell
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全
|
||||
echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全
|
||||
```
|
||||
|
||||
<!-- ## Kubectl Context and Configuration
|
||||
<!--
|
||||
## Kubectl Context and Configuration
|
||||
|
||||
Set which Kubernetes cluster `kubectl` communicates with and modifies configuration
|
||||
information. See [Authenticating Across Clusters with kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation for
|
||||
detailed config file information. -->
|
||||
detailed config file information.
|
||||
-->
|
||||
## Kubectl 上下文和配置
|
||||
|
||||
设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看 [使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取详情配置文件信息。
|
||||
设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。查看
|
||||
[使用 kubeconfig 跨集群授权访问](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
|
||||
文档获取配置文件详细信息。
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
``bash
|
||||
kubectl config view # Show Merged kubeconfig settings.
|
||||
|
||||
# use multiple kubeconfig files at the same time and view merged config
|
||||
@@ -89,9 +100,10 @@ kubectl config view
|
||||
# get the password for the e2e user
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config view -o jsonpath='{.users[].name}' # get a list of users
|
||||
kubectl config view -o jsonpath='{.users[].name}' # display the first user
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # get a list of users
|
||||
kubectl config get-contexts # display list of contexts
|
||||
kubectl config current-context # display the current-context
|
||||
kubectl config current-context # display the current-context
|
||||
kubectl config use-context my-cluster-name # set the default context to my-cluster-name
|
||||
|
||||
# add a new cluster to your kubeconf that supports basic auth
|
||||
@@ -105,7 +117,8 @@ kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
kubectl config unset users.foo # delete user foo
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl config view # 显示合并的 kubeconfig 配置。
|
||||
|
||||
@@ -115,36 +128,54 @@ KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view
|
||||
# 获取 e2e 用户的密码
|
||||
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
|
||||
|
||||
kubectl config current-context # 展示当前所处的上下文
|
||||
kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name
|
||||
kubectl config view -o jsonpath='{.users[].name}' # 显示第一个用户
|
||||
kubectl config view -o jsonpath='{.users[*].name}' # 获取用户列表
|
||||
kubectl config get-contexts # 显示上下文列表
|
||||
kubectl config current-context # 展示当前所处的上下文
|
||||
kubectl config use-context my-cluster-name # 设置默认的上下文为 my-cluster-name
|
||||
|
||||
# 添加新的集群配置到 kubeconf 中,使用 basic auth 进行鉴权
|
||||
# 添加新的集群配置到 kubeconf 中,使用 basic auth 进行身份认证
|
||||
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
|
||||
|
||||
# 使用特定的用户名和命名空间设置上下文。
|
||||
# 在指定上下文中持久性地保存名字空间,供所有后续 kubectl 命令使用
|
||||
kubectl config set-context --current --namespace=ggckad-s2
|
||||
|
||||
# 使用特定的用户名和名字空间设置上下文
|
||||
kubectl config set-context gce --user=cluster-admin --namespace=foo \
|
||||
&& kubectl config use-context gce
|
||||
|
||||
kubectl config unset users.foo # 删除用户 foo
|
||||
```
|
||||
|
||||
<!-- ## Apply
|
||||
`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io). -->
|
||||
<!--
|
||||
## Apply
|
||||
`apply` 通过定义 Kubernetes 资源的文件管理应用程序。它通过运行 `kubectl apply` 在集群中创建和更新资源。这是在生产中管理 Kubernetes 应用程序的推荐方法。查阅 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。
|
||||
`apply` manages applications through files defining Kubernetes resources. It creates and updates resources in a cluster through running `kubectl apply`. This is the recommended way of managing Kubernetes applications on production. See [Kubectl Book](https://kubectl.docs.kubernetes.io).
|
||||
-->
|
||||
## Apply
|
||||
`apply` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行
|
||||
`kubectl apply` 在集群中创建和更新资源。
|
||||
这是在生产中管理 Kubernetes 应用的推荐方法。
|
||||
参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。
|
||||
|
||||
<!-- ## Creating Objects -->
|
||||
## 创建对象
|
||||
<!--
|
||||
## Creating Objects
|
||||
|
||||
<!-- Kubernetes manifests can be defined in json or yaml. The file extension `.yaml`,
|
||||
`.yml`, and `.json` can be used. -->
|
||||
Kubernetes 配置可以用 json 或 yaml 定义。可以使用的文件扩展名有 `.yaml`,`.yml` 和 `.json`。
|
||||
Kubernetes manifests can be defined in YAML or JSON. The file extension `.yaml`,
|
||||
`.yml`, and `.json` can be used.
|
||||
-->
|
||||
## 创建对象 {#creating-objects}
|
||||
|
||||
<!-- ```bash
|
||||
Kubernetes 配置可以用 YAML 或 JSON 定义。可以使用的文件扩展名有
|
||||
`.yaml`、`.yml` 和 `.json`。
|
||||
|
||||
<!--
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # create resource(s)
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple files
|
||||
kubectl apply -f ./dir # create resource(s) in all manifest files in dir
|
||||
kubectl apply -f https://git.io/vPieo # create resource(s) from url
|
||||
kubectl create deployment nginx --image=nginx # start a single instance of nginx
|
||||
kubectl explain pods,svc # get the documentation for pod and svc manifests
|
||||
kubectl create deployment nginx --image=nginx # start a single instance of nginx
|
||||
kubectl explain pods # get the documentation for pod and svc manifests
|
||||
|
||||
# Create multiple YAML objects from stdin
|
||||
cat <<EOF | kubectl apply -f -
|
||||
@@ -184,17 +215,17 @@ data:
|
||||
password: $(echo -n "s33msi4" | base64 -w0)
|
||||
username: $(echo -n "jane" | base64 -w0)
|
||||
EOF
|
||||
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl apply -f ./my-manifest.yaml # 创建资源
|
||||
kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建
|
||||
kubectl apply -f ./dir # 从目录下的全部配置文件创建资源
|
||||
kubectl apply -f https://git.io/vPieo # 从 url 中创建资源
|
||||
kubectl create deployment nginx --image=nginx # 启动单实例 nginx
|
||||
kubectl explain pods,svc # 获取 pod,svc 配置的文档说明
|
||||
kubectl apply -f ./dir # 基于目录下的所有清单文件创建资源
|
||||
kubectl apply -f https://git.io/vPieo # 从 URL 中创建资源
|
||||
kubectl create deployment nginx --image=nginx # 启动单实例 nginx
|
||||
kubectl explain pods,svc # 获取 pod 清单的文档说明
|
||||
|
||||
# 从标准输入中的多个 YAML 对象中创建
|
||||
# 从标准输入创建多个 YAML 对象
|
||||
cat <<EOF | kubectl apply -f -
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -232,34 +263,35 @@ data:
|
||||
password: $(echo -n "s33msi4" | base64 -w0)
|
||||
username: $(echo -n "jane" | base64 -w0)
|
||||
EOF
|
||||
|
||||
```
|
||||
|
||||
<!-- ## Viewing, Finding Resources -->
|
||||
## 获取和查找资源
|
||||
<!--
|
||||
## Viewing, Finding Resources
|
||||
-->
|
||||
## 查看和查找资源
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
# Get commands with basic output
|
||||
kubectl get services # List all services in the namespace
|
||||
kubectl get pods --all-namespaces # List all pods in all namespaces
|
||||
kubectl get pods -o wide # List all pods in the namespace, with more details
|
||||
kubectl get deployment my-dep # List a particular deployment
|
||||
kubectl get pods --include-uninitialized # List all pods in the namespace, including uninitialized ones
|
||||
kubectl get pods # List all pods in the namespace
|
||||
kubectl get pod my-pod -o yaml # Get a pod's YAML
|
||||
kubectl get pod my-pod -o yaml --export # Get a pod's YAML without cluster specific information
|
||||
|
||||
# Describe commands with verbose output
|
||||
kubectl describe nodes my-node
|
||||
kubectl describe pods my-pod
|
||||
|
||||
kubectl get services --sort-by=.metadata.name # List Services Sorted by Name
|
||||
# List Services Sorted by Name
|
||||
kubectl get services --sort-by=.metadata.name
|
||||
|
||||
# List pods Sorted by Restart Count
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
|
||||
# List pods in test namespace sorted by capacity
|
||||
|
||||
kubectl get pods -n test --sort-by=.spec.capacity.storage
|
||||
# List PersistentVolumes sorted by capacity
|
||||
kubectl get pv --sort-by=.spec.capacity.storage
|
||||
|
||||
# Get the version label of all pods with label app=cassandra
|
||||
kubectl get pods --selector=app=cassandra -o \
|
||||
@@ -281,10 +313,6 @@ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries
|
||||
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||
|
||||
# Show labels for all pods (or any other Kubernetes object that supports labelling)
|
||||
# Also uses "jq"
|
||||
for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
|
||||
|
||||
# Or this command can be used as well to get all the labels associated with pods
|
||||
kubectl get pods --show-labels
|
||||
|
||||
# Check which nodes are ready
|
||||
@@ -294,86 +322,91 @@ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.ty
|
||||
# List all Secrets currently in use by a pod
|
||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||
|
||||
# List all containerIDs of initContainer of all pods
|
||||
# Helpful when cleaning up stopped containers, while avoiding removal of initContainers.
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
|
||||
|
||||
# List Events sorted by timestamp
|
||||
kubectl get events --sort-by=.metadata.creationTimestamp
|
||||
``` -->
|
||||
```bash
|
||||
# 使用 get 命令获取基本输出
|
||||
kubectl get services # 列出当前命名空间下的所有 services
|
||||
kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 pods
|
||||
kubectl get pods -o wide # 列出当前命名空间下的全部 pods,有更多的详细信息
|
||||
kubectl get deployment my-dep # 列出某个特定的 deployment
|
||||
kubectl get pods --include-uninitialized # 列出当前命名空间下的全部 pods,包含未初始化的
|
||||
kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML
|
||||
kubectl get pod my-pod -o yaml --export # 获取一个没有集群特定信息的 YAML
|
||||
|
||||
# 使用 describe 命令获取详细输出
|
||||
# Compares the current state of the cluster against the state that the cluster would be in if the manifest was applied.
|
||||
kubectl diff -f ./my-manifest.yaml
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
# get 命令的基本输出
|
||||
kubectl get services # 列出当前命名空间下的所有 services
|
||||
kubectl get pods --all-namespaces # 列出所有命名空间下的全部的 Pods
|
||||
kubectl get pods -o wide # 列出当前命名空间下的全部 Pods,并显示更详细的信息
|
||||
kubectl get deployment my-dep # 列出某个特定的 Deployment
|
||||
kubectl get pods # 列出当前命名空间下的全部 Pods
|
||||
kubectl get pod my-pod -o yaml # 获取一个 pod 的 YAML
|
||||
|
||||
# describe 命令的详细输出
|
||||
kubectl describe nodes my-node
|
||||
kubectl describe pods my-pod
|
||||
|
||||
kubectl get services --sort-by=.metadata.name # 列出当前命名空间下所有 services,按照名称排序
|
||||
# 列出当前名字空间下所有 Services,按名称排序
|
||||
kubectl get services --sort-by=.metadata.name
|
||||
|
||||
# 列出 pods 按照重启次数进行排序
|
||||
# 列出 Pods,按重启次数排序
|
||||
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
|
||||
|
||||
# 列出测试命名空间中的 Pod,按容量排序
|
||||
kubectl get pods -n test --sort-by=.spec.capacity.storage
|
||||
# 列举所有 PV 持久卷,按容量排序
|
||||
kubectl get pv --sort-by=.spec.capacity.storage
|
||||
|
||||
# 获取包含 app=cassandra 标签全部 pods 的 version 标签
|
||||
# 获取包含 app=cassandra 标签的所有 Pods 的 version 标签
|
||||
kubectl get pods --selector=app=cassandra -o \
|
||||
jsonpath='{.items[*].metadata.labels.version}'
|
||||
|
||||
# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果)
|
||||
# 获取所有工作节点(使用选择器以排除标签名称为 'node-role.kubernetes.io/master' 的结果)
|
||||
kubectl get node --selector='!node-role.kubernetes.io/master'
|
||||
|
||||
# 获取当前命名空间中正在运行的 pods
|
||||
# 获取当前命名空间中正在运行的 Pods
|
||||
kubectl get pods --field-selector=status.phase=Running
|
||||
|
||||
# 获取全部 node 的 ExternalIP 地址
|
||||
# 获取全部节点的 ExternalIP 地址
|
||||
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
|
||||
|
||||
# 列出属于某个特定 RC 的 pods 的名称
|
||||
# "jq" 命令对于 jsonpath 过于复杂的转换非常有用,可以在 https://stedolan.github.io/jq/ 找到它。
|
||||
# 列出属于某个特定 RC 的 Pods 的名称
|
||||
# 在转换对于 jsonpath 过于复杂的场合,"jq" 命令很有用;可以在 https://stedolan.github.io/jq/ 找到它。
|
||||
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
|
||||
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
|
||||
|
||||
# 显示所有 Pod 的标签(或任何其他支持标签的 Kubernetes 对象)
|
||||
# 也可以使用 "jq"
|
||||
for item in $( kubectl get pod --output=name); do printf "Labels for %s\n" "$item" | grep --color -E '[^/]+$' && kubectl get "$item" --output=json | jq -r -S '.metadata.labels | to_entries | .[] | " \(.key)=\(.value)"' 2>/dev/null; printf "\n"; done
|
||||
|
||||
# 或也可以使用此命令来获取与容器关联的所有标签
|
||||
# 显示所有 Pods 的标签(或任何其他支持标签的 Kubernetes 对象)
|
||||
kubectl get pods --show-labels
|
||||
|
||||
# 检查哪些节点处于 ready
|
||||
# 检查哪些节点处于就绪状态
|
||||
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
|
||||
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
|
||||
|
||||
# 列出被一个 pod 使用的全部 secret
|
||||
# 列出被一个 Pod 使用的全部 Secret
|
||||
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
|
||||
|
||||
# 列出 events,按照创建时间排序
|
||||
# 列举所有 Pods 中初始化容器的容器 ID(containerID)
|
||||
# Helpful when cleaning up stopped containers, while avoiding removal of initContainers.
|
||||
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
|
||||
|
||||
# 列出事件(Events),按时间戳排序
|
||||
kubectl get events --sort-by=.metadata.creationTimestamp
|
||||
|
||||
# 比较当前的集群状态和假定某清单被应用之后的集群状态
|
||||
kubectl diff -f ./my-manifest.yaml
|
||||
```
|
||||
|
||||
<!-- ## Updating Resources -->
|
||||
<!--
|
||||
## Updating Resources
|
||||
-->
|
||||
## 更新资源
|
||||
|
||||
<!-- As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)), use `rollout` instead. -->
|
||||
从版本 1.11 开始,`rolling-update` 已被弃用(参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md)),请使用 `rollout` 代替。
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # Rolling update "www" containers of "frontend" deployment, updating the image
|
||||
kubectl rollout history deployment/frontend # Check the history of deployments including the revision
|
||||
kubectl rollout undo deployment/frontend # Rollback to the previous deployment
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # Rollback to a specific revision
|
||||
kubectl rollout status -w deployment/frontend # Watch rolling update status of "frontend" deployment until completion
|
||||
|
||||
|
||||
# deprecated starting version 1.11
|
||||
kubectl rolling-update frontend-v1 -f frontend-v2.json # (deprecated) Rolling update pods of frontend-v1
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (deprecated) Change the name of the resource and update the image
|
||||
kubectl rolling-update frontend --image=image:v2 # (deprecated) Update the pods image of frontend
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (deprecated) Abort existing rollout in progress
|
||||
kubectl rollout restart deployment/frontend # Rolling restart of the "frontend" deployment
|
||||
|
||||
cat pod.json | kubectl replace -f - # Replace a pod based on the JSON passed into std
|
||||
|
||||
@@ -389,41 +422,39 @@ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl
|
||||
kubectl label pods my-pod new-label=awesome # Add a Label
|
||||
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Add an annotation
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # Auto scale a deployment "foo"
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" deployment 的 "www" 容器镜像
|
||||
kubectl rollout history deployment/frontend # 检查部署的历史记录,包括版本
|
||||
kubectl set image deployment/frontend www=image:v2 # 滚动更新 "frontend" Deployment 的 "www" 容器镜像
|
||||
kubectl rollout history deployment/frontend # 检查 Deployment 的历史记录,包括版本
|
||||
kubectl rollout undo deployment/frontend # 回滚到上次部署版本
|
||||
kubectl rollout undo deployment/frontend --to-revision=2 # 回滚到特定部署版本
|
||||
kubectl rollout status -w deployment/frontend # Watch "frontend" deployment 的滚动升级状态直到完成
|
||||
kubectl rollout status -w deployment/frontend # 监视 "frontend" Deployment 的滚动升级状态直到完成
|
||||
kubectl rollout restart deployment/frontend # 轮替重启 "frontend" Deployment
|
||||
|
||||
# 从 1.11 版本开始弃用
|
||||
kubectl rolling-update frontend-v1 -f frontend-v2.json # (弃用) 滚动升级 frontend-v1 的 pods
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (弃用) 修改资源的名称并更新镜像
|
||||
kubectl rolling-update frontend --image=image:v2 # (弃用) 更新 frontend 的 pods 的镜像
|
||||
kubectl rolling-update frontend-v1 frontend-v2 --rollback # (弃用) 终止已经进行中的 rollout
|
||||
cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 Pod
|
||||
|
||||
cat pod.json | kubectl replace -f - # 通过传入到标准输入的 JSON 来替换 pod
|
||||
|
||||
# 强制进行替换,会删除然后再创建资源,会导致服务不可用。
|
||||
# 强制替换,删除后重建资源。会导致服务不可用。
|
||||
kubectl replace --force -f ./pod.json
|
||||
|
||||
# 为多副本的 nginx 创建服务,使用 80 端口提供服务,连接到容器的 8000 端口。
|
||||
kubectl expose rc nginx --port=80 --target-port=8000
|
||||
|
||||
# 更新单容器 pod 的镜像标签到 v4
|
||||
# 将某单容器 Pod 的镜像版本(标签)更新到 v4
|
||||
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
|
||||
|
||||
kubectl label pods my-pod new-label=awesome # 添加标签
|
||||
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # 使 "foo" deployment 自动伸缩容
|
||||
kubectl autoscale deployment foo --min=2 --max=10 # 对 "foo" Deployment 自动伸缩容
|
||||
```
|
||||
|
||||
<!-- ## Patching Resources -->
|
||||
## 局部更新资源
|
||||
## 部分更新资源
|
||||
|
||||
<!-- ```bash
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # Partially update a node
|
||||
<!--
|
||||
```bash
|
||||
# Partially update a node
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
# Update a container's image; spec.containers[*].name is required because it's a merge key
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
@@ -436,38 +467,48 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "
|
||||
|
||||
# Add a new element to a positional array
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新 node
|
||||
# 部分更新某节点
|
||||
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
|
||||
|
||||
#更新容器的镜像;spec.containers[*].name 是必须的。因为它是一个合并 key。
|
||||
# 更新容器的镜像;spec.containers[*].name 是必须的。因为它是一个合并性质的主键。
|
||||
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
|
||||
|
||||
# 使用带位置数组的 json patch 更新容器的镜像
|
||||
# 使用带位置数组的 JSON patch 更新容器的镜像
|
||||
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
|
||||
|
||||
# 使用带位置数组的 json patch 禁用 deployment 的 livenessProbe
|
||||
# 使用带位置数组的 JSON patch 禁用某 Deployment 的 livenessProbe
|
||||
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
|
||||
|
||||
# 在带位置数组中添加元素
|
||||
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
|
||||
```
|
||||
|
||||
<!-- ## Editing Resources -->
|
||||
## 编辑资源
|
||||
<!-- The edit any API resource in an editor. -->
|
||||
在编辑器中编辑任何 API 资源
|
||||
<!--
|
||||
## Editing Resources
|
||||
|
||||
<!-- ```bash
|
||||
The edit any API resource in an editor.
|
||||
-->
|
||||
## 编辑资源
|
||||
|
||||
使用你偏爱的编辑器编辑 API 资源。
|
||||
|
||||
<!--
|
||||
```bash
|
||||
kubectl edit svc/docker-registry # Edit the service named docker-registry
|
||||
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Use an alternative editor
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service
|
||||
kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务
|
||||
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器
|
||||
```
|
||||
|
||||
<!-- ## Scaling Resources -->
|
||||
<!--
|
||||
## Scaling Resources
|
||||
-->
|
||||
## 对资源进行伸缩
|
||||
|
||||
<!-- ```bash
|
||||
@@ -475,40 +516,47 @@ kubectl scale --replicas=3 rs/foo # Scale a repl
|
||||
kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl scale --replicas=3 rs/foo # 将名为 'foo' 的副本集伸缩到 3 副本
|
||||
kubectl scale --replicas=3 -f foo.yaml # 将在 "foo.yaml" 中的特定资源伸缩到 3 个副本
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 deployment 的副本当前是 2,那么将它伸缩到 3
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个 replication controllers
|
||||
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # 如果名为 mysql 的 Deployment 的副本当前是 2,那么将它伸缩到 3
|
||||
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 伸缩多个副本控制器
|
||||
```
|
||||
|
||||
<!-- ## Deleting Resources -->
|
||||
<!--
|
||||
## Deleting Resources
|
||||
-->
|
||||
## 删除资源
|
||||
|
||||
<!-- ```bash
|
||||
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
|
||||
kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo"
|
||||
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # Delete pods and services, including uninitialized ones, with label name=myLabel
|
||||
kubectl -n my-ns delete po,svc --all # Delete all pods and services, including uninitialized ones, in namespace my-ns,
|
||||
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
|
||||
kubectl -n my-ns delete po,svc --all # Delete all pods and services in namespace my-ns,
|
||||
# Delete all pods matching the awk pattern1 or pattern2
|
||||
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 pod
|
||||
kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 pod 和 service
|
||||
kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和 services
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 pods 和 services,包括未初始化的
|
||||
kubectl -n my-ns delete po,svc --all # 删除在 my-ns 命名空间中全部的 pods 和 services ,包括未初始化的
|
||||
# 删除所有与 pattern1 或 pattern2 匹配的 pod
|
||||
kubectl delete -f ./pod.json # 删除在 pod.json 中指定的类型和名称的 Pod
|
||||
kubectl delete pod,service baz foo # 删除名称为 "baz" 和 "foo" 的 Pod 和服务
|
||||
kubectl delete pods,services -l name=myLabel # 删除包含 name=myLabel 标签的 pods 和服务
|
||||
kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除包含 label name=myLabel 标签的 Pods 和服务
|
||||
kubectl -n my-ns delete po,svc --all # 删除在 my-ns 名字空间中全部的 Pods 和服务
|
||||
# 删除所有与 pattern1 或 pattern2 awk 模式匹配的 Pods
|
||||
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
|
||||
```
|
||||
|
||||
<!-- ## Interacting with running Pods -->
|
||||
<!--
|
||||
## Interacting with running Pods
|
||||
-->
|
||||
## 与运行中的 Pods 进行交互
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl logs my-pod # dump pod logs (stdout)
|
||||
kubectl logs -l name=myLabel # dump pod logs, with label name=myLabel (stdout)
|
||||
kubectl logs my-pod --previous # dump pod logs (stdout) for a previous instantiation of a container
|
||||
@@ -519,34 +567,47 @@ kubectl logs -f my-pod # stream pod logs (stdout)
|
||||
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
|
||||
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
|
||||
kubectl run nginx --image=nginx -n
|
||||
mynamespace # Run pod nginx in a specific namespace
|
||||
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
|
||||
--dry-run=client -o yaml > pod.yaml
|
||||
|
||||
kubectl attach my-pod -i # Attach to Running Container
|
||||
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
|
||||
kubectl exec my-pod -- ls / # Run command in existing pod (1 container case)
|
||||
kubectl exec my-pod -c my-container -- ls / # Run command in existing pod (multi-container case)
|
||||
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl logs my-pod # 获取 pod 日志(标准输出)
|
||||
kubectl logs -l name=myLabel # 获取 pod label name=myLabel 日志(标准输出)
|
||||
kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出)
|
||||
kubectl logs my-pod -c my-container # 获取 pod 的容器日志 (标准输出, 多容器的场景)
|
||||
kubectl logs -l name=myLabel -c my-container # 获取 label name=myLabel pod 的容器日志 (标准输出, 多容器的场景)
|
||||
kubectl logs my-pod -c my-container --previous # 获取 pod 的上个容器实例日志 (标准输出, 多容器的场景)
|
||||
kubectl logs -f my-pod # 流式输出 pod 的日志 (标准输出)
|
||||
kubectl logs -f my-pod -c my-container # 流式输出 pod 容器的日志 (标准输出, 多容器的场景)
|
||||
kubectl logs -f -l name=myLabel --all-containers # 流式输出 label name=myLabel pod 的日志 (标准输出)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 shell 运行 pod
|
||||
kubectl attach my-pod -i # 进入到一个运行中的容器中
|
||||
kubectl logs my-pod # 获取 pod 日志(标准输出)
|
||||
kubectl logs -l name=myLabel # 获取含 name=myLabel 标签的 Pods 的日志(标准输出)
|
||||
kubectl logs my-pod --previous # 获取上个容器实例的 pod 日志(标准输出)
|
||||
kubectl logs my-pod -c my-container # 获取 Pod 容器的日志(标准输出, 多容器场景)
|
||||
kubectl logs -l name=myLabel -c my-container # 获取含 name=myLabel 标签的 Pod 容器日志(标准输出, 多容器场景)
|
||||
kubectl logs my-pod -c my-container --previous # 获取 Pod 中某容器的上个实例的日志(标准输出, 多容器场景)
|
||||
kubectl logs -f my-pod # 流式输出 Pod 的日志(标准输出)
|
||||
kubectl logs -f my-pod -c my-container # 流式输出 Pod 容器的日志(标准输出, 多容器场景)
|
||||
kubectl logs -f -l name=myLabel --all-containers # 流式输出含 name=myLabel 标签的 Pod 的所有日志(标准输出)
|
||||
kubectl run -i --tty busybox --image=busybox -- sh # 以交互式 Shell 运行 Pod
|
||||
kubectl run nginx --image=nginx -n mynamespace # 在指定名字空间中运行 nginx Pod
|
||||
kubectl run nginx --image=nginx # 运行 ngins Pod 并将其规约写入到名为 pod.yaml 的文件
|
||||
--dry-run=client -o yaml > pod.yaml
|
||||
|
||||
kubectl attach my-pod -i # 挂接到一个运行的容器中
|
||||
kubectl port-forward my-pod 5000:6000 # 在本地计算机上侦听端口 5000 并转发到 my-pod 上的端口 6000
|
||||
kubectl exec my-pod -- ls / # 在已有的 pod 中运行命令(单容器的场景)
|
||||
kubectl exec my-pod -c my-container -- ls / # 在已有的 pod 中运行命令(多容器的场景)
|
||||
kubectl top pod POD_NAME --containers # 显示给定 pod 和容器的监控数据
|
||||
kubectl exec my-pod -- ls / # 在已有的 Pod 中运行命令(单容器场景)
|
||||
kubectl exec my-pod -c my-container -- ls / # 在已有的 Pod 中运行命令(多容器场景)
|
||||
kubectl top pod POD_NAME --containers # 显示给定 Pod 和其中容器的监控数据
|
||||
```
|
||||
|
||||
<!-- ## Interacting with Nodes and Cluster -->
|
||||
<!--
|
||||
## Interacting with Nodes and Cluster
|
||||
-->
|
||||
## 与节点和集群进行交互
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl cordon my-node # Mark my-node as unschedulable
|
||||
kubectl drain my-node # Drain my-node in preparation for maintenance
|
||||
kubectl uncordon my-node # Mark my-node as schedulable
|
||||
@@ -557,57 +618,70 @@ kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump cur
|
||||
|
||||
# If a taint with that key and effect already exists, its value is replaced as specified.
|
||||
kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl cordon my-node # 设置 my-node 节点为不可调度
|
||||
kubectl drain my-node # 对 my-node 节点进行驱逐操作,为节点维护做准备
|
||||
kubectl uncordon my-node # 设置 my-node 节点为可以调度
|
||||
kubectl top node my-node # 显示给定 node 的指标
|
||||
kubectl cluster-info # 显示 master 和 services 的地址
|
||||
kubectl cluster-info dump # 将当前集群状态输出到标准输出
|
||||
kubectl cordon my-node # 标记 my-node 节点为不可调度
|
||||
kubectl drain my-node # 对 my-node 节点进行清空操作,为节点维护做准备
|
||||
kubectl uncordon my-node # 标记 my-node 节点为可以调度
|
||||
kubectl top node my-node # 显示给定节点的度量值
|
||||
kubectl cluster-info # 显示主控节点和服务的地址
|
||||
kubectl cluster-info dump # 将当前集群状态转储到标准输出
|
||||
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 将当前集群状态输出到 /path/to/cluster-state
|
||||
|
||||
# 如果已存在具有该键和效果的污点,则其值将按指定替换
|
||||
# 如果已存在具有指定键和效果的污点,则替换其值为指定值
|
||||
kubectl taint nodes foo dedicated=special-user:NoSchedule
|
||||
```
|
||||
|
||||
<!-- ### Resource types -->
|
||||
<!--
|
||||
### Resource types
|
||||
-->
|
||||
### 资源类型
|
||||
|
||||
<!-- List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): -->
|
||||
列出全部支持的资源类型和它们的简称, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), 无论它们是否是 [namespaced](/docs/concepts/overview/working-with-objects/namespaces), [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
<!--
|
||||
List all supported resource types along with their shortnames, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), whether they are [namespaced](/docs/concepts/overview/working-with-objects/namespaces), and [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
|
||||
-->
|
||||
列出所支持的全部资源类型和它们的简称、[API 组](/docs/concepts/overview/kubernetes-api/#api-groups), 是否是[名字空间作用域](/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects)。
|
||||
|
||||
```bash
|
||||
kubectl api-resources
|
||||
```
|
||||
|
||||
<!-- Other operations for exploring API resources: -->
|
||||
<!--
|
||||
Other operations for exploring API resources:
|
||||
-->
|
||||
用于探索 API 资源的其他操作:
|
||||
|
||||
<!-- ```bash
|
||||
<!--
|
||||
```bash
|
||||
kubectl api-resources --namespaced=true # All namespaced resources
|
||||
kubectl api-resources --namespaced=false # All non-namespaced resources
|
||||
kubectl api-resources -o name # All resources with simple output (just the resource name)
|
||||
kubectl api-resources -o wide # All resources with expanded (aka "wide") output
|
||||
kubectl api-resources --verbs=list,get # All resources that support the "list" and "get" request verbs
|
||||
kubectl api-resources --api-group=extensions # All resources in the "extensions" API group
|
||||
``` -->
|
||||
```
|
||||
-->
|
||||
```bash
|
||||
kubectl api-resources --namespaced=true # 所有在命名空间中的资源
|
||||
kubectl api-resources --namespaced=false # 所有不在命名空间中的资源
|
||||
kubectl api-resources -o name # 输出简单的所有资源(只是资源名称)
|
||||
kubectl api-resources -o wide # 具有扩展(又称 "wide")输出的所有资源
|
||||
kubectl api-resources --namespaced=true # 所有命名空间作用域的资源
|
||||
kubectl api-resources --namespaced=false # 所有非命名空间作用域的资源
|
||||
kubectl api-resources -o name # 用简单格式列举所有资源(仅显示资源名称)
|
||||
kubectl api-resources -o wide # 用扩展格式列举所有资源(又称 "wide" 格式)
|
||||
kubectl api-resources --verbs=list,get # 支持 "list" 和 "get" 请求动词的所有资源
|
||||
kubectl api-resources --api-group=extensions # "extensions" API 组中的所有资源
|
||||
```
|
||||
|
||||
<!-- ### Formatting output -->
|
||||
<!--
|
||||
### Formatting output
|
||||
|
||||
To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.
|
||||
-->
|
||||
### 格式化输出
|
||||
|
||||
<!-- To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command. -->
|
||||
要以特定格式将详细信息输出到终端窗口,可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。
|
||||
|
||||
<!-- Output format | Description
|
||||
<!--O
|
||||
utput format | Description
|
||||
--------------| -----------
|
||||
`-o=custom-columns=<spec>` | Print a table using a comma separated list of custom columns
|
||||
`-o=custom-columns-file=<filename>` | Print a table using the custom columns template in the `<filename>` file
|
||||
@@ -616,25 +690,63 @@ kubectl api-resources --api-group=extensions # "extensions" API 组中的所有
|
||||
`-o=jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath) expression in the `<filename>` file
|
||||
`-o=name` | Print only the resource name and nothing else
|
||||
`-o=wide` | Output in the plain-text format with any additional information, and for pods, the node name is included
|
||||
`-o=yaml` | Output a YAML formatted API object -->
|
||||
输出格式 | 描述
|
||||
`-o=yaml` | Output a YAML formatted API object
|
||||
-->
|
||||
输出格式 | 描述
|
||||
--------------| -----------
|
||||
`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列列表打印表格
|
||||
`-o=custom-columns=<spec>` | 使用逗号分隔的自定义列来打印表格
|
||||
`-o=custom-columns-file=<filename>` | 使用 `<filename>` 文件中的自定义列模板打印表格
|
||||
`-o=json` | 输出 JSON 格式的 API 对象
|
||||
`-o=jsonpath=<template>` | 打印 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式中定义的字段
|
||||
`-o=jsonpath-file=<filename>` | 在 `<filename>` 文件中打印由 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式定义的字段。
|
||||
`-o=name` | 仅打印资源名称而不打印任何其他内容
|
||||
`-o=wide` | 使用任何其他信息以纯文本格式输出,对于 pod 来说,包含了节点名称
|
||||
`-o=jsonpath-file=<filename>` | 打印在 `<filename>` 文件中定义的 [jsonpath](/docs/reference/kubectl/jsonpath) 表达式所指定的字段。
|
||||
`-o=name` | 仅打印资源名称而不打印其他内容
|
||||
`-o=wide` | 以纯文本格式输出额外信息,对于 Pod 来说,输出中包含了节点名称
|
||||
`-o=yaml` | 输出 YAML 格式的 API 对象
|
||||
|
||||
<!-- ### Kubectl output verbosity and debugging -->
|
||||
<!--
|
||||
Examples using `-o=custom-columns`:
|
||||
|
||||
```bash
|
||||
# All images running in a cluster
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
|
||||
|
||||
# All images excluding "k8s.gcr.io/coredns:1.6.2"
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
|
||||
|
||||
# All fields under metadata regardless of name
|
||||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
|
||||
More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns).
|
||||
```
|
||||
-->
|
||||
使用 `-o=custom-columns` 的示例:
|
||||
|
||||
```bash
|
||||
# 集群中运行着的所有镜像
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
|
||||
|
||||
# 除 "k8s.gcr.io/coredns:1.6.2" 之外的所有镜像
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
|
||||
|
||||
# 输出 metadata 下面的所有字段,无论 Pod 名字为何
|
||||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
```
|
||||
|
||||
有关更多示例,请参看 kubectl [参考文档](/docs/reference/kubectl/overview/#custom-columns)。
|
||||
|
||||
<!--
|
||||
### Kubectl output verbosity and debugging
|
||||
|
||||
Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
-->
|
||||
### Kubectl 日志输出详细程度和调试
|
||||
|
||||
<!-- Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an integer representing the log level. General Kubernetes logging conventions and the associated log levels are described [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). -->
|
||||
Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的,参数后跟了一个数字表示日志的级别。Kubernetes 通用的日志习惯和相关的日志级别在 [这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 有相应的描述。
|
||||
Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的,参数后跟一个数字表示日志的级别。
|
||||
Kubernetes 通用的日志习惯和相关的日志级别在
|
||||
[这里](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 有相应的描述。
|
||||
|
||||
<!-- Verbosity | Description
|
||||
<!--
|
||||
Verbosity | Description
|
||||
--------------| -----------
|
||||
`--v=0` | Generally useful for this to *always* be visible to a cluster operator.
|
||||
`--v=1` | A reasonable default log level if you don't want verbosity.
|
||||
@@ -644,37 +756,30 @@ Kubectl 日志输出详细程度是通过 `-v` 或者 `--v` 来控制的,参
|
||||
`--v=6` | Display requested resources.
|
||||
`--v=7` | Display HTTP request headers.
|
||||
`--v=8` | Display HTTP request contents.
|
||||
`--v=9` | Display HTTP request contents without truncation of contents. -->
|
||||
详细程度 | 描述
|
||||
`--v=9` | Display HTTP request contents without truncation of contents.
|
||||
-->
|
||||
详细程度 | 描述
|
||||
--------------| -----------
|
||||
`--v=0` | 通常对此有用,*始终*对运维人员可见。
|
||||
`--v=1` | 如果您不想要详细程度,则为合理的默认日志级别。
|
||||
`--v=2` | 有关服务的有用稳定状态信息以及可能与系统中的重大更改相关的重要日志消息。这是大多数系统的建议默认日志级别。
|
||||
`--v=3` | 有关更改的扩展信息。
|
||||
`--v=4` | Debug 级别。
|
||||
`--v=6` | 显示请求的资源。
|
||||
`--v=0` | 用于那些应该 *始终* 对运维人员可见的信息,因为这些信息一般很有用。
|
||||
`--v=1` | 如果您不想要看到冗余信息,此值是一个合理的默认日志级别。
|
||||
`--v=2` | 输出有关服务的稳定状态的信息以及重要的日志消息,这些信息可能与系统中的重大变化有关。这是建议大多数系统设置的默认日志级别。
|
||||
`--v=3` | 包含有关系统状态变化的扩展信息。
|
||||
`--v=4` | 包含调试级别的冗余信息。
|
||||
`--v=6` | 显示所请求的资源。
|
||||
`--v=7` | 显示 HTTP 请求头。
|
||||
`--v=8` | 显示 HTTP 请求内容。
|
||||
`--v=9` | 显示 HTTP 请求内容而不截断内容。
|
||||
|
||||
|
||||
`--v=9` | 显示 HTTP 请求内容而且不截断内容。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
<!-- * Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
|
||||
<!--
|
||||
* Learn more about [Overview of kubectl](/docs/reference/kubectl/overview/).
|
||||
* See [kubectl](/docs/reference/kubectl/kubectl/) options.
|
||||
|
||||
* Also [kubectl Usage Conventions](/docs/reference/kubectl/conventions/) to understand how to use it in reusable scripts.
|
||||
|
||||
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4). -->
|
||||
* 学习更多关于 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
|
||||
* 查看 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
|
||||
|
||||
* 也可以查看 [kubectl 使用约定](/docs/reference/kubectl/conventions/) 来理解如果在可以复用的脚本中使用它。
|
||||
|
||||
* 查看更多社区 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
|
||||
|
||||
* See more community [kubectl cheatsheets](https://github.com/dennyzhang/cheatsheet-kubernetes-A4).
|
||||
-->
|
||||
* 进一步了解 [kubectl 概述](/docs/reference/kubectl/overview/)。
|
||||
* 参阅 [kubectl](/docs/reference/kubectl/kubectl/) 选项.
|
||||
* 参阅 [kubectl 使用约定](/docs/reference/kubectl/conventions/)来理解如果在可复用的脚本中使用它。
|
||||
* 查看社区中其他的 [kubectl 备忘单](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)。
|
||||
|
||||
|
||||
@@ -1,33 +1,63 @@
|
||||
---
|
||||
# title: Overview of kubeadm
|
||||
title: kubeadm 概述
|
||||
weight: 10
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- luxas
|
||||
- jbeda
|
||||
title: Overview of kubeadm
|
||||
weight: 10
|
||||
card:
|
||||
name: reference
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<img src="https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png" align="right" width="150px">
|
||||
<!-- Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters. -->
|
||||
<!--
|
||||
Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice “fast paths” for creating Kubernetes clusters.
|
||||
-->
|
||||
Kubeadm 是一个工具,它提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令作为快速创建 kubernetes 集群的最佳实践。
|
||||
|
||||
<!-- kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. -->
|
||||
<!--
|
||||
kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope.
|
||||
-->
|
||||
kubeadm 通过执行必要的操作来启动和运行一个最小可用的集群。它被故意设计为只关心启动集群,而不是准备节点环境的工作。同样的,诸如安装各种各样的可有可无的插件,例如 Kubernetes 控制面板、监控解决方案以及特定云提供商的插件,这些都不在它负责的范围。
|
||||
|
||||
<!-- Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters. -->
|
||||
<!--
|
||||
Instead, we expect higher-level and more tailored tooling to be built on top of kubeadm, and ideally, using kubeadm as the basis of all deployments will make it easier to create conformant clusters.
|
||||
-->
|
||||
相反,我们期望由一个基于 kubeadm 从更高层设计的更加合适的工具来做这些事情;并且,理想情况下,使用 kubeadm 作为所有部署的基础将会使得创建一个符合期望的集群变得容易。
|
||||
|
||||
<!--
|
||||
## How to install
|
||||
|
||||
To install kubeadm, see the [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm).
|
||||
-->
|
||||
## 如何安装
|
||||
要安装 kubeadm,请参考[安装指南](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)。
|
||||
|
||||
## 接下可以做什么
|
||||
|
||||
<!-- * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node -->
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动一个 Kubernetes 主节点
|
||||
<!-- * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster -->
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动一个 Kubernetes 工作节点并且将其加入到集群
|
||||
<!-- * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version -->
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新一个 Kubernetes 集群到新版本
|
||||
<!-- * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` -->
|
||||
<!--
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) to bootstrap a Kubernetes master node
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) to bootstrap a Kubernetes worker node and join it to the cluster
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) to upgrade a Kubernetes cluster to a newer version
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade`
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join`
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community
|
||||
-->
|
||||
* [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init) 启动引导一个 Kubernetes 主节点
|
||||
* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) 启动引导一个 Kubernetes 工作节点并且将其加入到集群
|
||||
* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade) 更新 Kubernetes 集群到新版本
|
||||
* [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) 如果你使用 kubeadm v1.7.x 或者更低版本,你需要对你的集群做一些配置以便使用 `kubeadm upgrade` 命令
|
||||
<!-- * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` -->
|
||||
* [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) 使用 `kubeadm join` 来管理令牌
|
||||
<!-- * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` -->
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点产生的改变
|
||||
<!-- * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version -->
|
||||
* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) 还原之前使用 `kubeadm init` 或者 `kubeadm join` 对节点所作改变
|
||||
* [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) 打印出 kubeadm 版本
|
||||
<!-- * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community -->
|
||||
* [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) 预览一组可用的新功能以便从社区搜集反馈
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ main_menu: true
|
||||
weight: 20
|
||||
content_type: concept
|
||||
card:
|
||||
name: 设置
|
||||
name: setup
|
||||
weight: 20
|
||||
anchors:
|
||||
- anchor: "#learning-environment"
|
||||
@@ -15,7 +15,6 @@ card:
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- brendandburns
|
||||
- erictune
|
||||
@@ -33,7 +32,6 @@ card:
|
||||
title: Learning environment
|
||||
- anchor: "#production-environment"
|
||||
title: Production environment
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
+254
-31
@@ -1,29 +1,67 @@
|
||||
---
|
||||
title: 配置对多集群的访问
|
||||
content_type: task
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
---
|
||||
|
||||
<!--
|
||||
title: Configure Access to Multiple Clusters
|
||||
content_type: task
|
||||
weight: 30
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This page shows how to configure access to multiple clusters by using
|
||||
configuration files. After your clusters, users, and contexts are defined in
|
||||
one or more configuration files, you can quickly switch between clusters by using the
|
||||
`kubectl config use-context` command.
|
||||
-->
|
||||
本文展示如何使用配置文件来配置对多个集群的访问。 在将集群、用户和上下文定义在一个或多个配置文件中之后,用户可以使用 `kubectl config use-context` 命令快速地在集群之间进行切换。
|
||||
|
||||
<!--
|
||||
A file that is used to configure access to a cluster is sometimes called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
-->
|
||||
{{< note >}}
|
||||
用于配置集群访问的文件有时被称为 *kubeconfig 文件*。
|
||||
这是一种引用配置文件的通用方式,并不意味着存在一个名为 `kubeconfig` 的文件。
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
需要安装 [`kubectl`](/docs/tasks/tools/install-kubectl/) 命令行工具。
|
||||
|
||||
|
||||
<!--
|
||||
To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
|
||||
run `kubectl version --client`. The kubectl version should be
|
||||
[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your
|
||||
cluster's API server.
|
||||
-->
|
||||
要检查 {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 是否安装,
|
||||
执行 `kubectl version --client` 命令。
|
||||
kubectl 的版本应该与集群的 API 服务器
|
||||
[使用同一次版本号](/docs/setup/release/version-skew-policy/#kubectl)。
|
||||
|
||||
<!-- steps -->
|
||||
<!--
|
||||
## Define clusters, users, and contexts
|
||||
|
||||
Suppose you have two clusters, one for development work and one for scratch work.
|
||||
In the `development` cluster, your frontend developers work in a namespace called `frontend`,
|
||||
and your storage developers work in a namespace called `storage`. In your `scratch` cluster,
|
||||
developers work in the default namespace, or they create auxiliary namespaces as they
|
||||
see fit. Access to the development cluster requires authentication by certificate. Access
|
||||
to the scratch cluster requires authentication by username and password.
|
||||
|
||||
Create a directory named `config-exercise`. In your
|
||||
`config-exercise` directory, create a file named `config-demo` with this content:
|
||||
-->
|
||||
## 定义集群、用户和上下文
|
||||
|
||||
假设用户有两个集群,一个用于正式开发工作,一个用于其它临时用途(scratch)。
|
||||
@@ -58,6 +96,14 @@ contexts:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
<!--
|
||||
A configuration file describes clusters, users, and contexts. Your `config-demo` file
|
||||
has the framework to describe two clusters, two users, and three contexts.
|
||||
|
||||
Go to your `config-exercise` directory. Enter these commands to add cluster details to
|
||||
your configuration file:
|
||||
-->
|
||||
|
||||
配置文件描述了集群、用户名和上下文。 `config-demo` 文件中含有描述两个集群、两个用户和三个上下文的框架。
|
||||
|
||||
进入 `config-exercise` 目录。 输入以下命令,将群集详细信息添加到配置文件中:
|
||||
@@ -67,6 +113,9 @@ kubectl config --kubeconfig=config-demo set-cluster development --server=https:/
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
<!--
|
||||
Add user details to your configuration file:
|
||||
-->
|
||||
将用户详细信息添加到配置文件中:
|
||||
|
||||
```shell
|
||||
@@ -74,6 +123,20 @@ kubectl config --kubeconfig=config-demo set-credentials developer --client-certi
|
||||
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
|
||||
```
|
||||
|
||||
<!--
|
||||
- To delete a user you can run `kubectl --kubeconfig=config-demo config unset users.<name>`
|
||||
- To remove a cluster, you can run `kubectl --kubeconfig=config-demo config unset clusters.<name>`
|
||||
- To remove a context, you can run `kubectl --kubeconfig=config-demo config unset contexts.<name>`
|
||||
-->
|
||||
|
||||
注意:
|
||||
- 要删除用户,可以运行 `kubectl --kubeconfig=config-demo config unset users.<name>`
|
||||
- 要删除集群,可以运行 `kubectl --kubeconfig=config-demo config unset clusters.<name>`
|
||||
- 要删除上下文,可以运行 `kubectl --kubeconfig=config-demo config unset contexts.<name>`
|
||||
|
||||
<!--
|
||||
Add context details to your configuration file:
|
||||
-->
|
||||
将上下文详细信息添加到配置文件中:
|
||||
|
||||
```shell
|
||||
@@ -82,12 +145,19 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
<!--
|
||||
Open your `config-demo` file to see the added details. As an alternative to opening the
|
||||
`config-demo` file, you can use the `config view` command.
|
||||
-->
|
||||
打开 `config-demo` 文件查看添加的详细信息。 也可以使用 `config view` 命令进行查看:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows the two clusters, two users, and three contexts:
|
||||
-->
|
||||
输出展示了两个集群、两个用户和三个上下文:
|
||||
|
||||
```yaml
|
||||
@@ -131,8 +201,32 @@ users:
|
||||
username: exp
|
||||
```
|
||||
|
||||
<!--
|
||||
The `fake-ca-file`, `fake-cert-file` and `fake-key-file` above are the placeholders
|
||||
for the pathnames of the certificate files. You need change these to the actual pathnames
|
||||
of certificate files in your environment.
|
||||
|
||||
Sometimes you may want to use Base64-encoded data embedded here instead of separate
|
||||
certificate files; in that case you need add the suffix `-data` to the keys, for example,
|
||||
`certificate-authority-data`, `client-certificate-data`, `client-key-data`.
|
||||
-->
|
||||
其中的 `fake-ca-file`、`fake-cert-file` 和 `fake-key-file` 是证书文件路径名的占位符。
|
||||
你需要更改这些值,使之对应你的环境中证书文件的实际路径名。
|
||||
|
||||
有时你可能希望在这里使用 BASE64 编码的数据而不是一个个独立的证书文件。
|
||||
如果是这样,你需要在键名上添加 `-data` 后缀。例如,
|
||||
`certificate-authority-data`、`client-certificate-data` 和 `client-key-data`。
|
||||
|
||||
<!--
|
||||
Each context is a triple (cluster, user, namespace). For example, the
|
||||
`dev-frontend` context says, "Use the credentials of the `developer`
|
||||
user to access the `frontend` namespace of the `development` cluster".
|
||||
|
||||
Set the current context:
|
||||
-->
|
||||
每个上下文包含三部分(集群、用户和名字空间),例如,
|
||||
`dev-frontend` 上下文表明:使用 `developer` 用户的凭证来访问 `development` 集群的 `frontend` 名字空间。
|
||||
`dev-frontend` 上下文表明:使用 `developer` 用户的凭证来访问 `development` 集群的
|
||||
`frontend` 名字空间。
|
||||
|
||||
设置当前上下文:
|
||||
|
||||
@@ -140,7 +234,16 @@ users:
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
现在当输入 `kubectl` 命令时,相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间,同时,命令会使用 `dev-frontend` 上下文中所列用户的凭证。
|
||||
<!--
|
||||
Now whenever you enter a `kubectl` command, the action will apply to the cluster,
|
||||
and namespace listed in the `dev-frontend` context. And the command will use
|
||||
the credentials of the user listed in the `dev-frontend` context.
|
||||
|
||||
To see only the configuration information associated with
|
||||
the current context, use the `--minify` flag.
|
||||
-->
|
||||
现在当输入 `kubectl` 命令时,相应动作会应用于 `dev-frontend` 上下文中所列的集群和名字空间,
|
||||
同时,命令会使用 `dev-frontend` 上下文中所列用户的凭证。
|
||||
|
||||
使用 `--minify` 参数,来查看与当前上下文相关联的配置信息。
|
||||
|
||||
@@ -148,6 +251,9 @@ kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
The output shows configuration information associated with the `dev-frontend` context:
|
||||
-->
|
||||
输出结果展示了 `dev-frontend` 上下文相关的配置信息:
|
||||
|
||||
```yaml
|
||||
@@ -173,6 +279,11 @@ users:
|
||||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
<!--
|
||||
Now suppose you want to work for a while in the scratch cluster.
|
||||
|
||||
Change the current context to `exp-scratch`:
|
||||
-->
|
||||
现在假设用户希望在其它临时用途集群中工作一段时间。
|
||||
|
||||
将当前上下文更改为 `exp-scratch`:
|
||||
@@ -181,7 +292,16 @@ users:
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
现在用户 `kubectl` 下达的任何命令都将应用于 `scratch` 集群的默认名字空间。 同时,命令会使用 `exp-scratch` 上下文中所列用户的凭证。
|
||||
<!--
|
||||
Now any `kubectl` command you give will apply to the default namespace of
|
||||
the `scratch` cluster. And the command will use the credentials of the user
|
||||
listed in the `exp-scratch` context.
|
||||
|
||||
View configuration associated with the new current context, `exp-scratch`.
|
||||
-->
|
||||
|
||||
现在你发出的所有 `kubectl` 命令都将应用于 `scratch` 集群的默认名字空间。
|
||||
同时,命令会使用 `exp-scratch` 上下文中所列用户的凭证。
|
||||
|
||||
查看更新后的当前上下文 `exp-scratch` 相关的配置:
|
||||
|
||||
@@ -189,6 +309,12 @@ kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
Finally, suppose you want to work for a while in the `storage` namespace of the
|
||||
`development` cluster.
|
||||
|
||||
Change the current context to `dev-storage`:
|
||||
-->
|
||||
最后,假设用户希望在 `development` 集群中的 `storage` 名字空间下工作一段时间。
|
||||
|
||||
将当前上下文更改为 `dev-storage`:
|
||||
@@ -197,13 +323,21 @@ kubectl config --kubeconfig=config-demo view --minify
|
||||
kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
```
|
||||
|
||||
<!--
|
||||
View configuration associated with the new current context, `dev-storage`.
|
||||
-->
|
||||
查看更新后的当前上下文 `dev-storage` 相关的配置:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
<!--
|
||||
## Create a second configuration file
|
||||
|
||||
In your `config-exercise` directory, create a file named `config-demo-2` with this content:
|
||||
-->
|
||||
|
||||
## 创建第二个配置文件
|
||||
|
||||
在 `config-exercise` 目录中,创建名为 `config-demo-2` 的文件,其中包含以下内容:
|
||||
@@ -221,32 +355,77 @@ contexts:
|
||||
name: dev-ramp-up
|
||||
```
|
||||
|
||||
<!--
|
||||
The preceding configuration file defines a new context named `dev-ramp-up`.
|
||||
-->
|
||||
上述配置文件定义了一个新的上下文,名为 `dev-ramp-up`。
|
||||
|
||||
<!--
|
||||
## Set the KUBECONFIG environment variable
|
||||
|
||||
See whether you have an environment variable named `KUBECONFIG`. If so, save the
|
||||
current value of your `KUBECONFIG` environment variable, so you can restore it later.
|
||||
For example:
|
||||
-->
|
||||
## 设置 KUBECONFIG 环境变量
|
||||
|
||||
查看是否有名为 `KUBECONFIG` 的环境变量。 如有,保存 `KUBECONFIG` 环境变量当前的值,以便稍后恢复。
|
||||
例如,在 Linux 中:
|
||||
例如:
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
|
||||
`KUBECONFIG` 环境变量是配置文件路径的列表,该列表在 Linux 和 Mac 中以冒号分隔,在 Windows 中以分号分隔。 如果有 `KUBECONFIG` 环境变量,请熟悉列表中的配置文件。
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
|
||||
临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如,在 Linux 中:
|
||||
<!--
|
||||
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is
|
||||
colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
|
||||
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
|
||||
in the list.
|
||||
|
||||
Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
|
||||
-->
|
||||
`KUBECONFIG` 环境变量是配置文件路径的列表,该列表在 Linux 和 Mac 中以冒号分隔,
|
||||
在 Windows 中以分号分隔。
|
||||
如果有 `KUBECONFIG` 环境变量,请熟悉列表中的配置文件。
|
||||
|
||||
临时添加两条路径到 `KUBECONFIG` 环境变量中。 例如:
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
|
||||
```shell
|
||||
$Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
```
|
||||
|
||||
<!--
|
||||
In your `config-exercise` directory, enter this command:
|
||||
-->
|
||||
在 `config-exercise` 目录中输入以下命令:
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。 特别地, 注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自 `config-demo` 文件的三个上下文:
|
||||
<!--
|
||||
The output shows merged information from all the files listed in your `KUBECONFIG`
|
||||
environment variable. In particular, notice that the merged information has the
|
||||
`dev-ramp-up` context from the `config-demo-2` file and the three contexts from
|
||||
the `config-demo` file:
|
||||
-->
|
||||
输出展示了 `KUBECONFIG` 环境变量中所列举的所有文件合并后的信息。
|
||||
特别地,注意合并信息中包含来自 `config-demo-2` 文件的 `dev-ramp-up` 上下文和来自
|
||||
`config-demo` 文件的三个上下文:
|
||||
|
||||
```yaml
|
||||
contexts:
|
||||
@@ -272,49 +451,93 @@ contexts:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
更多关于 kubeconfig 文件如何合并的信息,请参考
|
||||
[使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
<!--
|
||||
For more information about how kubeconfig files are merged, see
|
||||
[Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
-->
|
||||
关于 kubeconfig 文件如何合并的更多信息,请参考
|
||||
[使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
|
||||
<!--
|
||||
## Explore the $HOME/.kube directory
|
||||
|
||||
If you already have a cluster, and you can use `kubectl` to interact with
|
||||
the cluster, then you probably have a file named `config` in the `$HOME/.kube`
|
||||
directory.
|
||||
|
||||
Go to `$HOME/.kube`, and see what files are there. Typically, there is a file named
|
||||
`config`. There might also be other configuration files in this directory. Briefly
|
||||
familiarize yourself with the contents of these files.
|
||||
-->
|
||||
## 探索 $HOME/.kube 目录
|
||||
|
||||
如果用户已经拥有一个集群,可以使用 `kubectl` 与集群进行交互。 那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。
|
||||
如果用户已经拥有一个集群,可以使用 `kubectl` 与集群进行交互,
|
||||
那么很可能在 `$HOME/.kube` 目录下有一个名为 `config` 的文件。
|
||||
|
||||
进入 `$HOME/.kube` 目录, 看看那里有什么文件。 通常会有一个名为
|
||||
`config` 的文件,目录中可能还有其他配置文件。 请简单地熟悉这些文件的内容。
|
||||
进入 `$HOME/.kube` 目录,看看那里有什么文件。通常会有一个名为
|
||||
`config` 的文件,目录中可能还有其他配置文件。请简单地熟悉这些文件的内容。
|
||||
|
||||
<!--
|
||||
## Append $HOME/.kube/config to your KUBECONFIG environment variable
|
||||
|
||||
If you have a `$HOME/.kube/config` file, and it's not already listed in your
|
||||
`KUBECONFIG` environment variable, append it to your `KUBECONFIG` environment variable now.
|
||||
For example:
|
||||
-->
|
||||
## 将 $HOME/.kube/config 追加到 KUBECONFIG 环境变量中
|
||||
|
||||
如果有 `$HOME/.kube/config` 文件,并且还未列在 `KUBECONFIG` 环境变量中,
|
||||
那么现在将它追加到 `KUBECONFIG` 环境变量中。
|
||||
例如,在 Linux 中:
|
||||
例如:
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
|
||||
在配置练习目录中输入以下命令,来查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息:
|
||||
### Windows Powershell
|
||||
|
||||
```shell
|
||||
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
|
||||
```
|
||||
|
||||
<!--
|
||||
View configuration information merged from all the files that are now listed
|
||||
in your `KUBECONFIG` environment variable. In your config-exercise directory, enter:
|
||||
-->
|
||||
在配置练习目录中输入以下命令,查看当前 `KUBECONFIG` 环境变量中列举的所有文件合并后的配置信息:
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
<!--
|
||||
## Clean up
|
||||
|
||||
Return your `KUBECONFIG` environment variable to its original value. For example:
|
||||
-->
|
||||
## 清理
|
||||
|
||||
将 `KUBECONFIG` 环境变量还原为原始值。 例如,在 Linux 中:
|
||||
将 `KUBECONFIG` 环境变量还原为原始值。 例如:
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
-->
|
||||
|
||||
* [使用 kubeconfig 文件组织集群访问](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl 配置](/docs/user-guide/kubectl/{{< param "version" >}}/)
|
||||
|
||||
|
||||
|
||||
|
||||
* [使用 kubeconfig 文件组织集群访问](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
|
||||
@@ -6,14 +6,14 @@ card:
|
||||
name: tasks
|
||||
weight: 50
|
||||
---
|
||||
<!-- ---
|
||||
<!--
|
||||
title: Configure a Pod to Use a ConfigMap
|
||||
content_type: task
|
||||
weight: 150
|
||||
card:
|
||||
name: tasks
|
||||
weight: 50
|
||||
--- -->
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!-- ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. -->
|
||||
|
||||
@@ -1,20 +1,24 @@
|
||||
---
|
||||
reviewers:
|
||||
- mikedanese
|
||||
title: 安装并设置 kubectl
|
||||
title: 安装并配置 kubectl
|
||||
content_type: task
|
||||
weight: 10
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: 安装 kubectl
|
||||
---
|
||||
<!--
|
||||
---
|
||||
reviewers:
|
||||
- bgrant0607
|
||||
- mikedanese
|
||||
title: Install and Set Up kubectl
|
||||
content_type: task
|
||||
weight: 10
|
||||
---
|
||||
card:
|
||||
name: tasks
|
||||
weight: 20
|
||||
title: Install kubectl
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
<!--
|
||||
Use the Kubernetes command-line tool, [kubectl](/docs/user-guide/kubectl/), to deploy and manage applications on Kubernetes. Using kubectl, you can inspect cluster resources; create, delete, and update components; look at your new cluster; and bring up example apps.
|
||||
|
||||
+12
-4
@@ -1,15 +1,23 @@
|
||||
---
|
||||
title: 示例:使用 Persistent Volumes 部署 WordPress 和 MySQL
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 40
|
||||
title: "Stateful 示例: Wordpress with Persistent Volumes"
|
||||
title: "有状态应用示例: 带持久卷的 Wordpress"
|
||||
---
|
||||
|
||||
<!--
|
||||
title: "Example: Deploying WordPress and MySQL with Persistent Volumes"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 40
|
||||
title: "Stateful Example: Wordpress with Persistent Volumes"
|
||||
-->
|
||||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
|
||||
@@ -1,19 +1,23 @@
|
||||
---
|
||||
title: "示例:使用 Redis 部署 PHP 留言板应用程序"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "无状态应用示例:基于 Redis 的 PHP Guestbook"
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: "Example: Deploying PHP Guestbook application with Redis"
|
||||
reviewers:
|
||||
- ahmetb
|
||||
content_type: tutorial
|
||||
weight: 20
|
||||
---
|
||||
card:
|
||||
name: tutorials
|
||||
weight: 30
|
||||
title: "Stateless Example: PHP Guestbook with Redis"
|
||||
-->
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -8,14 +8,12 @@ class: training
|
||||
---
|
||||
|
||||
<!--
|
||||
---
|
||||
title: Training
|
||||
bigheader: Kubernetes Training and Certification
|
||||
abstract: Training programs, certifications, and partners.
|
||||
layout: basic
|
||||
cid: training
|
||||
class: training
|
||||
---
|
||||
-->
|
||||
|
||||
<section class="call-to-action">
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
# 注意:修改此文件时请维持字符串名称的字母顺序并与英文版保持一致
|
||||
|
||||
[caution]
|
||||
other = "警告:"
|
||||
other = "注意:"
|
||||
|
||||
[cleanup_heading]
|
||||
other = "清理现场"
|
||||
@@ -164,7 +164,7 @@ other = "了解"
|
||||
other = "了解更多"
|
||||
|
||||
[note]
|
||||
other = "注意:"
|
||||
other = "说明:"
|
||||
|
||||
[objectives_heading]
|
||||
other = "教程目标"
|
||||
|
||||
@@ -10,8 +10,8 @@
|
||||
{{ partial "docs/content-page" (dict "ctx" $ "page" $ ) }}
|
||||
{{ else }}
|
||||
<h1>{{ .Title }}</h1>
|
||||
{{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }}
|
||||
{{ end }}
|
||||
{{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }}
|
||||
{{ partial "section-index.html" . }}
|
||||
</div>
|
||||
{{ end }}
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
</p>
|
||||
{{ if not .page.Params.notitle }}
|
||||
<h1>{{ .page.Title }}</h1>
|
||||
{{ $desc := .page.Description }}
|
||||
{{ with .page.Params.description }}<div class="lead">{{ $desc | markdownify }}</div>{{ end }}
|
||||
{{ end }}
|
||||
|
||||
{{ .page.Content }}
|
||||
{{ .page.Content }}
|
||||
|
||||
@@ -19,9 +19,11 @@
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</ul>
|
||||
<br>
|
||||
<button id="btn-concepts" class="button" onClick="location.href='{{ .button_path | relLangURL }}';" aria-label="{{ .title }}">{{ .button }}</button>
|
||||
<br>
|
||||
<br>
|
||||
{{ if .button }}
|
||||
<br>
|
||||
<button id="btn-concepts" class="button" onClick="location.href='{{ .button_path | relLangURL }}';" aria-label="{{ .title }}">{{ .button }}</button>
|
||||
<br>
|
||||
<br>
|
||||
{{ end }}
|
||||
</div>
|
||||
{{ end }}
|
||||
+6
-4
@@ -20,7 +20,7 @@
|
||||
/vi/docs/ /vi/docs/home/ 301!
|
||||
/zh/docs/ /zh/docs/home/ 301!
|
||||
/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/ /blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/ 301!
|
||||
/docs/admin/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301
|
||||
/docs/admin/ /docs/concepts/cluster-administration/ 301
|
||||
/docs/admin/add-ons/ /docs/concepts/cluster-administration/addons/ 301
|
||||
/docs/admin/addons/ /docs/concepts/cluster-administration/addons/ 301
|
||||
/docs/admin/apparmor/ /docs/tutorials/clusters/apparmor/ 301
|
||||
@@ -75,7 +75,8 @@
|
||||
/docs/concepts/abstractions/pod/ /docs/concepts/workloads/pods/pod-overview/ 301
|
||||
/docs/concepts/api-extension/apiserver-aggregation/ /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ 301
|
||||
/docs/concepts/api-extension/custom-resources/ /docs/concepts/extend-kubernetes/api-extension/custom-resources/ 301
|
||||
/docs/concepts/cluster/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301
|
||||
/docs/concepts/containers/overview/ /docs/concepts/containers/ 301
|
||||
/docs/concepts/cluster-administration/cluster-administration-overview/ /docs/concepts/cluster-administration/ 301
|
||||
/docs/concepts/cluster-administration/access-cluster/ /docs/tasks/access-application-cluster/access-cluster/ 301
|
||||
/docs/concepts/cluster-administration/audit/ /docs/tasks/debug-application-cluster/audit/ 301
|
||||
/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/ 301
|
||||
@@ -98,12 +99,13 @@
|
||||
/docs/concepts/configuration/scheduler-perf-tuning/ /docs/concepts/scheduling-eviction/scheduler-perf-tuning/ 301
|
||||
/docs/concepts/configuration/scheduling-framework/ /docs/concepts/scheduling-eviction/scheduling-framework/ 301
|
||||
/docs/concepts/configuration/taint-and-toleration/ /docs/concepts/scheduling-eviction/taint-and-toleration/ 301
|
||||
/docs/concepts/extend-kubernetes/extend-cluster/ /docs/concepts/extend-kubernetes/ 301
|
||||
/docs/concepts/jobs/cron-jobs/ /docs/concepts/workloads/controllers/cron-jobs/ 301
|
||||
/docs/concepts/jobs/run-to-completion-finite-workloads/ /docs/concepts/workloads/controllers/job/ 301
|
||||
/docs/concepts/nodes/node/ /docs/concepts/architecture/nodes/ 301
|
||||
/docs/concepts/object-metadata/annotations/ /docs/concepts/overview/working-with-objects/annotations/ 301
|
||||
/docs/concepts/overview/ /docs/concepts/overview/what-is-kubernetes/ 301
|
||||
/docs/concepts/overview/extending/ /docs/concepts/extend-kubernetes/extend-cluster/ 301
|
||||
/docs/concepts/overview/extending/ /docs/concepts/extend-kubernetes/ 301
|
||||
/docs/concepts/policy/container-capabilities/ /docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container/ 301
|
||||
/docs/concepts/policy/security-context/ /docs/tasks/configure-pod-container/security-context/ 301
|
||||
/docs/concepts/scheduling/kube-scheduler/ /docs/concepts/scheduling-eviction/kube-scheduler/ 301
|
||||
@@ -230,7 +232,7 @@
|
||||
/docs/tasks/administer-cluster/memory-constraint-namespace/ /docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/ 301
|
||||
/docs/tasks/administer-cluster/memory-default-namespace/ /docs/tasks/administer-cluster/manage-resources/memory-default-namespace/ 301
|
||||
/docs/tasks/administer-cluster/out-of-resource/memory-available.sh /docs/tasks/administer-cluster/memory-available.sh 301
|
||||
/docs/tasks/administer-cluster/overview/ /docs/concepts/cluster-administration/cluster-administration-overview/ 301
|
||||
/docs/tasks/administer-cluster/overview/ /docs/concepts/cluster-administration/ 301
|
||||
/docs/tasks/administer-cluster/quota-memory-cpu-namespace/ /docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/ 301
|
||||
/docs/tasks/administer-cluster/quota-pod-namespace/ /docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/ 301
|
||||
/docs/tasks/administer-cluster/reserve-compute-resources/out-of-resource.md /docs/tasks/administer-cluster/out-of-resource/ 301
|
||||
|
||||
Reference in New Issue
Block a user