diff --git a/assets/scss/_base.scss b/assets/scss/_base.scss index ddfee42444..fab7dd4e7e 100644 --- a/assets/scss/_base.scss +++ b/assets/scss/_base.scss @@ -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; diff --git a/content/de/docs/setup/minikube.md b/content/de/docs/setup/minikube.md index f0484a8447..3b583360d7 100644 --- a/content/de/docs/setup/minikube.md +++ b/content/de/docs/setup/minikube.md @@ -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) diff --git a/content/en/docs/concepts/_index.md b/content/en/docs/concepts/_index.md index 27c23bfe4d..8165a3a1f4 100644 --- a/content/en/docs/concepts/_index.md +++ b/content/en/docs/concepts/_index.md @@ -12,61 +12,3 @@ The Concepts section helps you learn about the parts of the Kubernetes system an - -## 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. - - diff --git a/content/en/docs/concepts/architecture/_index.md b/content/en/docs/concepts/architecture/_index.md index 3a17d1b08e..61fb48e714 100755 --- a/content/en/docs/concepts/architecture/_index.md +++ b/content/en/docs/concepts/architecture/_index.md @@ -1,5 +1,7 @@ --- title: "Cluster Architecture" weight: 30 +description: > + The architectural concepts behind Kubernetes. --- diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 index 72af40feec..7ce7126d9d --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -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. --- + +The cluster administration overview is for anyone creating or administering a Kubernetes cluster. +It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). + + + +## 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. diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md deleted file mode 100644 index fc2f55fbcd..0000000000 --- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -reviewers: -- davidopp -- lavalamp -title: Cluster Administration Overview -content_type: concept -weight: 10 ---- - - -The cluster administration overview is for anyone creating or administering a Kubernetes cluster. -It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). - - - -## 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. - - - - diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md index 1635c2a5bf..2ed10d601d 100755 --- a/content/en/docs/concepts/configuration/_index.md +++ b/content/en/docs/concepts/configuration/_index.md @@ -1,5 +1,7 @@ --- title: "Configuration" weight: 80 +description: > + Resources that Kubernetes provides for configuring Pods. --- diff --git a/content/en/docs/concepts/containers/_index.md b/content/en/docs/concepts/containers/_index.md old mode 100755 new mode 100644 index ad442f3ab3..091cea881b --- a/content/en/docs/concepts/containers/_index.md +++ b/content/en/docs/concepts/containers/_index.md @@ -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 --- + + +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. + + + + + + +## 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/) + diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md deleted file mode 100644 index 1d996b8b93..0000000000 --- a/content/en/docs/concepts/containers/overview.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -reviewers: -- erictune -- thockin -title: Containers overview -content_type: concept -weight: 1 ---- - - - -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. - - - - - - -## 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/) - diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index 93d955441d..934861904f 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -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 --- + + + +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. + + + + + + +## 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. + + + + + + +## Extension Points + +This diagram shows the extension points in a Kubernetes system. + + + + + +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. + + + + + + +## 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/) + + diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md index ec86980c4b..a52c470446 100755 --- a/content/en/docs/concepts/overview/_index.md +++ b/content/en/docs/concepts/overview/_index.md @@ -1,4 +1,5 @@ --- title: "Overview" weight: 20 ---- \ No newline at end of file +description: Get a high-level outline of Kubernetes and the components it is built from. +--- diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index f83f00683e..53e6b84c16 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -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 diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index dd69fb6ccb..b3b6960358 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -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 diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md index 8661349a3f..f872c20697 100755 --- a/content/en/docs/concepts/overview/working-with-objects/_index.md +++ b/content/en/docs/concepts/overview/working-with-objects/_index.md @@ -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. --- - diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md index 41d91de546..d2b42bc4cd 100755 --- a/content/en/docs/concepts/policy/_index.md +++ b/content/en/docs/concepts/policy/_index.md @@ -1,5 +1,6 @@ --- title: "Policies" weight: 90 +description: > + Policies you can configure that apply to groups of resources. --- - diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md index a30a80a451..3a2bf9359f 100644 --- a/content/en/docs/concepts/scheduling-eviction/_index.md +++ b/content/en/docs/concepts/scheduling-eviction/_index.md @@ -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. --- diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md index aecc16eee7..3dfb62fe48 100644 --- a/content/en/docs/concepts/security/_index.md +++ b/content/en/docs/concepts/security/_index.md @@ -1,4 +1,6 @@ --- title: "Security" weight: 81 +description: > + Concepts for keeping your cloud-native workload secure. --- diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index eea2c65b33..2e7d91427e 100755 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -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. diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md index 7e0dd19b12..a6aeac7734 100755 --- a/content/en/docs/concepts/storage/_index.md +++ b/content/en/docs/concepts/storage/_index.md @@ -1,5 +1,7 @@ --- title: "Storage" weight: 70 +description: > + Ways to provide both long-term and temporary storage to Pods in your cluster. --- diff --git a/content/en/docs/concepts/workloads/_index.md b/content/en/docs/concepts/workloads/_index.md index ca394ebd00..1aac095cb5 100644 --- a/content/en/docs/concepts/workloads/_index.md +++ b/content/en/docs/concepts/workloads/_index.md @@ -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. --- diff --git a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md index d3d072ad71..576cde3d88 100644 --- a/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md +++ b/content/en/docs/reference/access-authn-authz/certificate-signing-requests.md @@ -254,6 +254,7 @@ spec: request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo= usages: - client auth +EOF ``` Some points to note: diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 7a37fdc20b..6d7c1cced2 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -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. diff --git a/content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md similarity index 100% rename from content/en/docs/tasks/debug-application-cluster/dns-debugging-resolution.md rename to content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md diff --git a/content/fr/docs/reference/glossary/volume.md b/content/fr/docs/reference/glossary/volume.md new file mode 100644 index 0000000000..deeca963b6 --- /dev/null +++ b/content/fr/docs/reference/glossary/volume.md @@ -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" >}}. + + + +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. \ No newline at end of file diff --git a/content/fr/docs/reference/glossary/workload.md b/content/fr/docs/reference/glossary/workload.md new file mode 100644 index 0000000000..8b3a0fd3c3 --- /dev/null +++ b/content/fr/docs/reference/glossary/workload.md @@ -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. + + + +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" >}}. diff --git a/content/fr/docs/setup/learning-environment/minikube.md b/content/fr/docs/setup/learning-environment/minikube.md index 9b801a4453..77be61831f 100644 --- a/content/fr/docs/setup/learning-environment/minikube.md +++ b/content/fr/docs/setup/learning-environment/minikube.md @@ -235,13 +235,13 @@ minikube start --vm-driver= 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) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md new file mode 100644 index 0000000000..5d8df1af62 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -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/ -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 - < +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 %}} diff --git a/content/fr/docs/tutorials/hello-minikube.md b/content/fr/docs/tutorials/hello-minikube.md index 724919d0e6..a934464b77 100644 --- a/content/fr/docs/tutorials/hello-minikube.md +++ b/content/fr/docs/tutorials/hello-minikube.md @@ -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 : diff --git a/content/fr/examples/pods/pod-projected-svc-token.yaml b/content/fr/examples/pods/pod-projected-svc-token.yaml new file mode 100644 index 0000000000..985073c8d3 --- /dev/null +++ b/content/fr/examples/pods/pod-projected-svc-token.yaml @@ -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 diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index 6de85830e8..9e0a5b1664 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -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 diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md index f340841e19..408c9c7641 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -3,7 +3,7 @@ title: 理解 Kubernetes 对象 content_type: concept weight: 10 card: - name: 概念 + name: concepts weight: 40 --- diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md index 25e92ac78d..29d222a63c 100644 --- a/content/zh/docs/concepts/policy/resource-quotas.md +++ b/content/zh/docs/concepts/policy/resource-quotas.md @@ -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)的支持。 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)了解更多信息。 - - diff --git a/content/zh/docs/concepts/workloads/pods/pod-overview.md b/content/zh/docs/concepts/workloads/pods/pod-overview.md index d9c8423450..e3959d62cb 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-overview.md +++ b/content/zh/docs/concepts/workloads/pods/pod-overview.md @@ -3,7 +3,7 @@ title: Pod 概览 content_type: concept weight: 10 card: - name: 概念 + name: concepts weight: 60 --- diff --git a/content/zh/docs/home/_index.md b/content/zh/docs/home/_index.md index 9106ce3727..d0e81e59d9 100644 --- a/content/zh/docs/home/_index.md +++ b/content/zh/docs/home/_index.md @@ -13,47 +13,59 @@ menu: title: "文档" weight: 20 post: > -

通过演练，示例和参考文档了解如何使用 Kubernetes。你甚至可以帮助贡献文档！

-overview: > - - Kubernetes 是一个开源容器编排引擎，用于容器化应用的自动化部署、扩展和管理。该项目托管在 CNCF。 - +

通过概念、教程和参考文档了解如何使用 Kubernetes。你甚至可以帮助贡献文档！

+# 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 (CNCF). +overview: + Kubernetes 是一个开源的容器编排引擎，用来对容器化应用进行自动化部署、 扩缩和管理。该项目托管在 CNCF。 +# 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 文档。 --- diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md index e1782b0419..4b0fcf0584 100644 --- a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md @@ -631,9 +631,9 @@ Example of a minimal response from a webhook to allow a request: * `allowed`，设置为 `true` 或 `false` -Webhook 禁止请求的最简单响应示例： +Webhook 允许请求的最简单响应示例： {{< tabs name="AdmissionReview_response_allow" >}} {{% tab name="admission.k8s.io/v1" %}} diff --git a/content/zh/docs/reference/glossary/index.md b/content/zh/docs/reference/glossary/index.md index 0c13697ff9..d5d593d062 100755 --- a/content/zh/docs/reference/glossary/index.md +++ b/content/zh/docs/reference/glossary/index.md @@ -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: 词汇表 --- diff --git a/content/zh/docs/reference/kubectl/cheatsheet.md b/content/zh/docs/reference/kubectl/cheatsheet.md index 4ef61cac63..b157fefd71 100644 --- a/content/zh/docs/reference/kubectl/cheatsheet.md +++ b/content/zh/docs/reference/kubectl/cheatsheet.md @@ -1,9 +1,5 @@ --- title: kubectl 备忘单 -reviewers: -- erictune -- krousey -- clove content_type: concept card: name: reference @@ -23,34 +19,42 @@ card: - -也可以看下: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 + +另见: [Kubectl 概述](/docs/reference/kubectl/overview/) 和 [JsonPath 指南](/docs/reference/kubectl/jsonpath)。 - 本页面是 `kubectl` 命令的概述。 - - -## kubectl - 备忘单 + +# kubectl - 备忘单 - ## Kubectl 自动补全 ### BASH - +``` + +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 中永久的添加自动补全 ``` - 您还可以为 `kubectl` 使用一个速记别名，该别名也可以与 completion 一起使用： ```bash @@ -60,25 +64,32 @@ complete -F __start_kubectl k ### ZSH - +``` +--> ```bash source <(kubectl completion zsh) # 在 zsh 中设置当前 shell 的自动补全 echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 在您的 zsh shell 中永久的添加自动补全 ``` - +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 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` 通过定义 Kubernetes 资源的文件来管理应用。它通过运行 +`kubectl apply` 在集群中创建和更新资源。 +这是在生产中管理 Kubernetes 应用的推荐方法。 +参见 [Kubectl 文档](https://kubectl.docs.kubernetes.io)。 - -## 创建对象 + -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 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 < -## 获取和查找资源 + +## 查看和查找资源 - -```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 ``` - + ## 更新资源 - -从版本 1.11 开始，`rolling-update` 已被弃用（参见 [CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.11.md))，请使用 `rollout` 代替。 - - +``` +--> ```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 自动伸缩容 ``` -## 局部更新资源 +## 部分更新资源 - +``` +--> ```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" } }]' ``` - -## 编辑资源 - -在编辑器中编辑任何 API 资源 + +## 编辑资源 + +使用你偏爱的编辑器编辑 API 资源。 + + +``` +--> ```bash -kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service +kubectl edit svc/docker-registry # 编辑名为 docker-registry 的服务 KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其他编辑器 ``` - + ## 对资源进行伸缩 +``` +--> ```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 # 伸缩多个副本控制器 ``` - + ## 删除资源 +``` +--> ```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 ``` - + ## 与运行中的 Pods 进行交互 - +``` +--> ```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 和其中容器的监控数据 ``` - + ## 与节点和集群进行交互 - +``` +--> ```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 ``` - + ### 资源类型 - -列出全部支持的资源类型和它们的简称, [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)。 + +列出所支持的全部资源类型和它们的简称、[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 ``` - + 用于探索 API 资源的其他操作： - +``` +--> ```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 组中的所有资源 ``` - + ### 格式化输出 - 要以特定格式将详细信息输出到终端窗口，可以将 `-o` 或 `--output` 参数添加到支持的 `kubectl` 命令。 - -输出格式 | 描述 +`-o=yaml` | Output a YAML formatted API object +--> +输出格式 | 描述 --------------| ----------- -`-o=custom-columns=` | 使用逗号分隔的自定义列列表打印表格 +`-o=custom-columns=` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=` | 使用 `` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 `-o=jsonpath=