diff --git a/OWNERS b/OWNERS index 62138a57ba..f1f2f35873 100644 --- a/OWNERS +++ b/OWNERS @@ -6,5 +6,9 @@ reviewers: approvers: - sig-docs-en-owners # Defined in OWNERS_ALIASES +emeritus_approvers: +- chenopis +- jaredbhatti + labels: - sig/docs \ No newline at end of file diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 3e8f3b1532..dd33e0ce96 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -50,21 +50,18 @@ aliases: - mistyhacks - rajakavitha1 - ryanmcginnis - - shavidissa + - simplytunde - steveperry-53 - stewart-yu - tengqm - tfogo + - xiangpengzhao - zacharysarah - - zhangxiaoyu-zidif - zparnold sig-docs-en-reviews: # PR reviews for English content - - jimangel - rajakavitha1 - sftim - stewart-yu - - xiangpengzhao - - zhangxiaoyu-zidif sig-docs-es-owners: # Admins for Spanish content - raelga - alexbrand @@ -114,11 +111,13 @@ aliases: - girikuncoro - irvifa sig-docs-it-owners: # Admins for Italian content - - rlenferink + - mattiaperi - micheleberardi + - rlenferink sig-docs-it-reviews: # PR reviews for Italian content - - rlenferink + - mattiaperi - micheleberardi + - rlenferink sig-docs-ja-owners: # Admins for Japanese content - cstoku - nasa9084 @@ -142,11 +141,8 @@ aliases: - seokho-son sig-docs-maintainers: # Website maintainers - bradamant3 - - chenopis - - jaredbhatti - jimangel - kbarnard10 - - mistyhacks - pwittrock - steveperry-53 - tengqm @@ -181,6 +177,8 @@ aliases: sig-docs-pt-owners: # Admins for Portuguese content - femrtnz - jcjesus + - devlware sig-docs-pt-reviews: # PR reviews for Portugese content - femrtnz - jcjesus + - devlware diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS index a91048f714..6c33b7c038 100644 --- a/SECURITY_CONTACTS +++ b/SECURITY_CONTACTS @@ -10,6 +10,6 @@ # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE # INSTRUCTIONS AT https://kubernetes.io/security/ -chenopis bradamant3 +jimangel zacharysarah diff --git a/content/de/docs/concepts/architecture/nodes.md b/content/de/docs/concepts/architecture/nodes.md index faf5e5decb..29c0c33e7c 100644 --- a/content/de/docs/concepts/architecture/nodes.md +++ b/content/de/docs/concepts/architecture/nodes.md @@ -152,7 +152,7 @@ Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-per In Versionen von Kubernetes vor 1.13 ist NodeStatus der Herzschlag des Nodes. -Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). +Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird. Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt. diff --git a/content/en/blog/_posts/2018-05-29-announcing-kustomize.md b/content/en/blog/_posts/2018-05-29-announcing-kustomize.md index 908ce72363..fbd1192e95 100644 --- a/content/en/blog/_posts/2018-05-29-announcing-kustomize.md +++ b/content/en/blog/_posts/2018-05-29-announcing-kustomize.md @@ -11,7 +11,7 @@ date: 2018-05-29 [kustomization]: https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization [mailing list]: https://groups.google.com/forum/#!forum/kustomize [open an issue]: https://github.com/kubernetes-sigs/kustomize/issues/new -[subproject]: https://github.com/kubernetes/community/blob/master/keps/sig-cli/0008-kustomize.md +[subproject]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/0008-kustomize.md [SIG-CLI]: https://github.com/kubernetes/community/tree/master/sig-cli [workflow]: https://github.com/kubernetes-sigs/kustomize/blob/master/docs/workflows.md diff --git a/content/en/blog/_posts/2018-10-10-runtimeclass.md b/content/en/blog/_posts/2018-10-10-runtimeclass.md index d47ad9c9cb..29ae6e3285 100644 --- a/content/en/blog/_posts/2018-10-10-runtimeclass.md +++ b/content/en/blog/_posts/2018-10-10-runtimeclass.md @@ -42,6 +42,6 @@ RuntimeClass will be under active development at least through 2019, and we’re ## Learn More - Take it for a spin! As an alpha feature, there are some additional setup steps to use RuntimeClass. Refer to the [RuntimeClass documentation](/docs/concepts/containers/runtime-class/#runtime-class) for how to get it running. -- Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/community/blob/master/keps/sig-node/0014-runtime-class.md) for more nitty-gritty design details. +- Check out the [RuntimeClass Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0014-runtime-class.md) for more nitty-gritty design details. - The [Sandbox Isolation Level Decision](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) documents the thought process that initially went into making RuntimeClass a pod-level choice. - Join the discussions and help shape the future of RuntimeClass with the [SIG-Node community](https://github.com/kubernetes/community/tree/master/sig-node) diff --git a/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md b/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md index 38f0e39a9e..b8eaecaf27 100644 --- a/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md +++ b/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md @@ -68,6 +68,8 @@ properties: properties command: type: string + shell: + type: string machines: type: array items: @@ -92,14 +94,14 @@ properties: shell: type: string minLength: 1 # value validation - oneOf: # value validation - - required: [“command”] # value validation - - required: [“shell”] # value validation machines: type: array items: type: string pattern: “^[a-z0-9]+(-[a-z0-9]+)*$” # value validation + oneOf: # value validation + - required: [“command”] # value validation + - required: [“shell”] # value validation required: [“spec”] # value validation ``` @@ -130,16 +132,20 @@ properties: shell: type: string minLength: 1 - oneOf: - - type: string - required: [“command”] - - type: string - required: [“shell”] machines: type: array items: type: string pattern: “^[a-z0-9]+(-[a-z0-9]+)*$” + oneOf: + - properties: + command: + type: string + required: [“command”] + - properties: + shell: + type: string + required: [“shell”] not: properties: privileged: {} diff --git a/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md b/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md index 549dfdb72f..bc9a3f3e15 100644 --- a/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md +++ b/content/en/blog/_posts/2019-07-18-some-apis-are-being-deprecated.md @@ -34,8 +34,8 @@ from **extensions/v1beta1**, **apps/v1beta1**, or **apps/v1beta2** in **v1.16**. * Migrate to the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API. * Ingress: will no longer be served from **extensions/v1beta1** in **v1.18**. - * Migrate to the networking.k8s.io/v1beta1 API. Existing persisted data can be - retrieved/updated via the networking.k8s.io/v1beta1 API. + * Migrate to the networking.k8s.io/v1beta1 API, serving Ingress since v1.14. + Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API. # What To Do diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md index be327630fe..8a4493e49b 100644 --- a/content/en/docs/concepts/architecture/master-node-communication.md +++ b/content/en/docs/concepts/architecture/master-node-communication.md @@ -3,7 +3,7 @@ reviewers: - dchen1107 - roberthbailey - liggitt -title: Master-Node communication +title: Master-Node Communication content_template: templates/concept weight: 20 --- diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 58f9d014f1..5bb680aedd 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -176,7 +176,7 @@ checks the state of each node every `--node-monitor-period` seconds. In versions of Kubernetes prior to 1.13, NodeStatus is the heartbeat from the node. Starting from Kubernetes 1.13, node lease feature is introduced as an alpha feature (feature gate `NodeLease`, -[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). +[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). When node lease feature is enabled, each node has an associated `Lease` object in `kube-node-lease` namespace that is renewed by the node periodically, and both NodeStatus and node lease are treated as heartbeats from the node. Node leases diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md index fea67957d1..bcec8727f9 100644 --- a/content/en/docs/concepts/security/overview.md +++ b/content/en/docs/concepts/security/overview.md @@ -75,9 +75,9 @@ consult your documentation for security best practices. Area of Concern for Kubernetes Infrastructure | Recommendation | --------------------------------------------- | ------------ | Network access to API Server (Masters) | Ideally all access to the Kubernetes Masters is not allowed publicly on the internet and is controlled by network access control lists restricted to the set of IP addresses needed to administer the cluster.| -Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, this nodes should not exposed on the public internet entirely. +Network access to Nodes (Worker Servers) | Nodes should be configured to _only_ accept connections (via network access control lists) from the masters on the specified ports, and accept connections for services in Kubernetes of type NodePort and LoadBalancer. If possible, these nodes should not be exposed on the public internet entirely. Kubernetes access to Cloud Provider API | Each cloud provider will need to grant a different set of permissions to the Kubernetes Masters and Nodes, so this recommendation will be more generic. It is best to provide the cluster with cloud provider access that follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) for the resources it needs to administer. An example for Kops in AWS can be found here: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles -Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security +Access to etcd | Access to etcd (the datastore of Kubernetes) should be limited to the masters only. Depending on your configuration, you should also attempt to use etcd over TLS. More info can be found here: https://github.com/etcd-io/etcd/tree/master/Documentation#security etcd Encryption | Wherever possible it's a good practice to encrypt all drives at rest, but since etcd holds the state of the entire cluster (including Secrets) its disk should especially be encrypted at rest. ## Cluster diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index c81be65379..1753428810 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -15,7 +15,7 @@ weight: 40 ## Terminology -For the sake of clarity, this guide defines the following terms: +For clarity, this guide defines the following terms: Node : A worker machine in Kubernetes, part of a cluster. diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 4800af5628..6f8c426fa5 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -356,7 +356,7 @@ that are configured for a specific IP address and difficult to re-configure. The IP address that you choose must be a valid IPv4 or IPv6 address from within the `service-cluster-ip-range` CIDR range that is configured for the API server. If you try to create a Service with an invalid clusterIP address value, the API -server will returns a 422 HTTP status code to indicate that there's a problem. +server will return a 422 HTTP status code to indicate that there's a problem. ## Discovering services @@ -598,7 +598,7 @@ For more information, see the [docs](https://cloud.google.com/kubernetes-engine/ metadata: name: my-service annotations: - service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 + service.beta.kubernetes.io/aws-load-balancer-internal: "true" [...] ``` {{% /tab %}} @@ -685,7 +685,7 @@ In the above example, if the Service contained three ports, `80`, `443`, and `8443`, then `443` and `8443` would use the SSL certificate, but `80` would just be proxied HTTP. -From Kubernetes v1.9 onwrds you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services. +From Kubernetes v1.9 onwards you can use [predefined AWS SSL policies](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) with HTTPS or SSL listeners for your Services. To see which policies are available for use, you can use the `aws` command line tool: ```bash diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 55a1392a25..a8def3012b 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -522,11 +522,12 @@ parameters: Default is "default". * `adminSecretName`: secret that holds information about the Quobyte user and the password to authenticate against the API server. The provided secret - must have type "kubernetes.io/quobyte", e.g. created in this way: + must have type "kubernetes.io/quobyte" and the keys `user` and `password`, + e.g. created in this way: ```shell kubectl create secret generic quobyte-admin-secret \ - --type="kubernetes.io/quobyte" --from-literal=key='opensesame' \ + --type="kubernetes.io/quobyte" --from-literal=user='admin' --from-literal=password='opensesame' \ --namespace=kube-system ``` @@ -610,13 +611,25 @@ parameters: group are searched to find one that matches `skuName` and `location`. If a storage account is provided, it must reside in the same resource group as the cluster, and `skuName` and `location` are ignored. +* `secretNamespace`: the namespace of the secret that contains the Azure Storage + Account Name and Key. Default is the same as the Pod. +* `secretName`: the name of the secret that contains the Azure Storage Account Name and + Key. Default is `azure-storage-account--secret` +* `readOnly`: a flag indicating whether the storage will be mounted as read only. + Defaults to false which means a read/write mount. This setting will impact the + `ReadOnly` setting in VolumeMounts as well. -During provision, a secret is created for mounting credentials. If the cluster -has enabled both [RBAC](/docs/reference/access-authn-authz/rbac/) and +During storage provisioning, a secret named by `secretName` is created for the +mounting credentials. If the cluster has enabled both +[RBAC](/docs/reference/access-authn-authz/rbac/) and [Controller Roles](/docs/reference/access-authn-authz/rbac/#controller-roles), add the `create` permission of resource `secret` for clusterrole `system:controller:persistent-volume-binder`. +In a multi-tenancy context, it is strongly recommended to set the value for +`secretNamespace` explicitly, otherwise the storage account credentials may +be read by other users. + ### Portworx Volume ```yaml diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 799dff3082..bb06be99bf 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -177,7 +177,7 @@ SIG Docs [approvers](/docs/contribute/participating/#approvers) can serve a term Approvers must meet the following requirements to be a co-chair: - Have been a SIG Docs approver for at least 6 months -- Have [led a Kubernetes docs release][coordinate-docs-for-a-kubernetes-release] or shadowed two releases +- Have [led a Kubernetes docs release](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) or shadowed two releases - Understand SIG Docs workflows and tooling: git, Hugo, localization, blog subproject - Understand how other Kubernetes SIGs and repositories affect the SIG Docs workflow, including: [teams in k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [process in k/community](https://github.com/kubernetes/community/tree/master/sig-docs), plugins in [k/test-infra](https://github.com/kubernetes/test-infra/), and the role of [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture). - Commit at least 5 hours per week (and often more) to the role for a minimum of 6 months diff --git a/content/en/docs/contribute/start.md b/content/en/docs/contribute/start.md index 67fbe8d38a..c736e0914a 100644 --- a/content/en/docs/contribute/start.md +++ b/content/en/docs/contribute/start.md @@ -261,11 +261,18 @@ pull request if it detects that you pushed a new branch to your fork. link for the `deploy/netlify` test, near the bottom of the page. It opens in the same browser window by default. + {{< note >}} + Please limit pull requests to one language per PR. For example, if you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. + {{< /note >}} + 6. Wait for review. Generally, reviewers are suggested by the `k8s-ci-robot`. If a reviewer asks you to make changes, you can go to the **Files changed** tab and click the pencil icon on any files that have been changed by the pull request. When you save the changed file, a new commit is created in - the branch being monitored by the pull request. + the branch being monitored by the pull request. If you are waiting on a + reviewer to review the changes, proactively reach out to the reviewer + once every 7 days. You can also drop into #sig-docs Slack channel, + which is a good place to ask for help regarding PR reviews. 7. If your change is accepted, a reviewer merges your pull request, and the change is live on the Kubernetes website a few minutes later. diff --git a/content/en/docs/reference/access-authn-authz/webhook.md b/content/en/docs/reference/access-authn-authz/webhook.md index e4945b1685..3f667fa5ef 100644 --- a/content/en/docs/reference/access-authn-authz/webhook.md +++ b/content/en/docs/reference/access-authn-authz/webhook.md @@ -108,7 +108,13 @@ the request and respond to either allow or disallow access. The response body's } ``` -To disallow access, the remote service would return: +For disallowing access there are two methods. + +The first method is preferred in most cases, and indicates the authorization +webhook does not allow, or has "no opinion" about the request, but if other +authorizers are configured, they are given a chance to allow the request. +If there are no other authorizers, or none of them allow the request, the +request is forbidden. The webhook would return: ```json { @@ -121,6 +127,23 @@ To disallow access, the remote service would return: } ``` +The second method denies immediately, short-circuiting evaluation by other +configured authorizers. This should only be used by webhooks that have +detailed knowledge of the full authorizer configuration of the cluster. +The webhook would return: + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "status": { + "allowed": false, + "denied": true, + "reason": "user does not have read access to the namespace" + } +} +``` + Access to non-resource paths are sent as: ```json diff --git a/content/en/docs/reference/glossary/qos-class.md b/content/en/docs/reference/glossary/qos-class.md index 6ecd3e402a..692afd47fa 100755 --- a/content/en/docs/reference/glossary/qos-class.md +++ b/content/en/docs/reference/glossary/qos-class.md @@ -15,7 +15,7 @@ related: - pod --- - QoS Class (Quality of Service Class)) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction. + QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction. QoS Class of a Pod is set at creation time based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction. diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index ea846c4254..ecec12f3be 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -205,9 +205,12 @@ As of version 1.11 `rolling-update` have been deprecated (see [CHANGELOG-1.11.md ```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 diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index ad5d0caf8d..3cf3899296 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -452,3 +452,26 @@ Another difference is that an applier using Client Side Apply is unable to chang ### Custom Resources Server Side Apply currently treats all custom resources as unstructured data. All keys are treated the same as struct fields, and all lists are considered atomic. In the future, it will use the validation field in Custom Resource Definitions to allow Custom Resource authors to define how to how to merge their own objects. + +### Clearing ManagedFields + +It is possible to strip all managedFields from an object by overwriting them using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every non-apply operation. +This can be done by overwriting the managedFields field with an empty entry. Two examples are: + +```json +PATCH /api/v1/namespaces/default/configmaps/example-cm +Content-Type: application/merge-patch+json +Accept: application/json +Data: {"metadata":{"managedFields": [{}]}} +``` + +```json +PATCH /api/v1/namespaces/default/configmaps/example-cm +Content-Type: application/json-patch+json +Accept: application/json +Data: [{"op": "replace", "path": "/metadata/managedFields", "value": [{}]}] +``` + +This will overwrite the managedFields with a list containing a single empty entry that then results in the managedFields being stripped entirely from the object. Note that just setting the managedFields to an empty list will not reset the field. This is on purpose, so managedFields never get stripped by clients not aware of the field. + +In cases where the reset operation is combined with changes to other fields than the managedFields, this will result in the managedFields being reset first and the other changes being processed afterwards. As a result the applier takes ownership of any fields updated in the same request. diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index 0d3325b99d..baf0c86ecb 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -23,7 +23,7 @@ Minikube supports the following Kubernetes features: * NodePorts * ConfigMaps and Secrets * Dashboards -* Container Runtime: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o), and [containerd](https://github.com/containerd/containerd) +* Container Runtime: Docker, [CRI-O](https://github.com/kubernetes-incubator/cri-o), and [containerd](https://github.com/containerd/containerd) * Enabling CNI (Container Network Interface) * Ingress @@ -252,16 +252,6 @@ minikube start \ --bootstrapper=kubeadm ``` {{% /tab %}} -{{% tab name="rkt container engine" %}} -To use [rkt](https://github.com/rkt/rkt) as the container runtime run: -```shell -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=rkt -``` -This will use an alternative minikube ISO image containing both rkt, and Docker, and enable CNI networking. -{{% /tab %}} {{< /tabs >}} #### Use local images by re-using the Docker daemon diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index b63330438d..80c2cc639c 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -215,6 +215,11 @@ Use the following commands to install Containerd on your system: ### Prerequisites ```shell +cat > /etc/modules-load.d/containerd.conf <}} All code snippets in Windows sections are to be run in a PowerShell environment with elevated permissions (Admin). {{< /note >}} @@ -180,9 +197,28 @@ All code snippets in Windows sections are to be run in a PowerShell environment [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) ``` - If after reboot you see the following error, you need to restart the docker service manually + After reboot, you can verify that the docker service is ready with the command below. - ![alt_text](../windows-docker-error.png "windows docker error screen capture") + ```PowerShell + docker version + ``` + + If you see error message like the following, you need to start the docker service manually. + + ``` + Client: + Version: 17.06.2-ee-11 + API version: 1.30 + Go version: go1.8.7 + Git commit: 06fc007 + Built: Thu May 17 06:14:39 2018 + OS/Arch: windows / amd64 + error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/version: open //./pipe/docker_engine: The system c + annot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to + connect. This error may also indicate that the docker daemon is not running. + ``` + + You can start the docker service manually like below. ```PowerShell Start-Service docker @@ -229,7 +265,13 @@ wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/s {{< /note >}} ```PowerShell -.\start.ps1 -ManagementIP -NetworkMode overlay -ClusterCIDR -ServiceCIDR -KubeDnsServiceIP -LogDir +cd c:\k +.\start.ps1 -ManagementIP ` + -NetworkMode overlay ` + -ClusterCIDR ` + -ServiceCIDR ` + -KubeDnsServiceIP ` + -LogDir ``` | Parameter | Default Value | Notes | diff --git a/content/en/docs/setup/production-environment/windows/windows-docker-error.png b/content/en/docs/setup/production-environment/windows/windows-docker-error.png deleted file mode 100644 index d00528c0d4..0000000000 Binary files a/content/en/docs/setup/production-environment/windows/windows-docker-error.png and /dev/null differ diff --git a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md index b923b532b9..546e3e3098 100644 --- a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -9,6 +9,10 @@ weight: 80 This page shows how to create an External Load Balancer. +{{< note >}} +This feature is only available for cloud providers or environments which support external load balancers. +{{< /note >}} + When creating a service, you have the option of automatically creating a cloud network load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your cluster nodes @@ -35,30 +39,24 @@ documentation. To create an external load balancer, add the following line to your [service configuration file](/docs/concepts/services-networking/service/#loadbalancer): -```json - "type": "LoadBalancer" +```yaml + type: LoadBalancer ``` Your configuration file might look like: -```json - { - "kind": "Service", - "apiVersion": "v1", - "metadata": { - "name": "example-service" - }, - "spec": { - "ports": [{ - "port": 8765, - "targetPort": 9376 - }], - "selector": { - "app": "example" - }, - "type": "LoadBalancer" - } - } +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + type: LoadBalancer ``` ## Using kubectl @@ -118,82 +116,42 @@ minikube service example-service --url ## Preserving the client source IP Due to the implementation of this feature, the source IP seen in the target -container will *not be the original source IP* of the client. To enable +container is *not the original source IP* of the client. To enable preservation of the client IP, the following fields can be configured in the service spec (supported in GCE/Google Kubernetes Engine environments): * `service.spec.externalTrafficPolicy` - denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. There are two available -options: "Cluster" (default) and "Local". "Cluster" obscures the client source +options: Cluster (default) and Local. Cluster obscures the client source IP and may cause a second hop to another node, but should have good overall -load-spreading. "Local" preserves the client source IP and avoids a second hop +load-spreading. Local preserves the client source IP and avoids a second hop for LoadBalancer and NodePort type services, but risks potentially imbalanced traffic spreading. -* `service.spec.healthCheckNodePort` - specifies the healthcheck nodePort -(numeric port number) for the service. If not specified, healthCheckNodePort is -created by the service API backend with the allocated nodePort. It will use the -user-specified nodePort value if specified by the client. It only has an -effect when type is set to "LoadBalancer" and externalTrafficPolicy is set -to "Local". +* `service.spec.healthCheckNodePort` - specifies the health check nodePort +(numeric port number) for the service. If not specified, `healthCheckNodePort` is +created by the service API backend with the allocated `nodePort`. It will use the +user-specified `nodePort` value if specified by the client. It only has an +effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set +to Local. -This feature can be activated by setting `externalTrafficPolicy` to "Local" in the -Service Configuration file. +Setting `externalTrafficPolicy` to Local in the Service configuration file +activates this feature. -```json - { - "kind": "Service", - "apiVersion": "v1", - "metadata": { - "name": "example-service" - }, - "spec": { - "ports": [{ - "port": 8765, - "targetPort": 9376 - }], - "selector": { - "app": "example" - }, - "type": "LoadBalancer", - "externalTrafficPolicy": "Local" - } - } +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + externalTrafficPolicy: Local + type: LoadBalancer ``` -### Feature availability - -| K8s version | Feature support | -| :---------: |:-----------:| -| 1.7+ | Supports the full API fields | -| 1.5 - 1.6 | Supports Beta Annotations | -| <1.5 | Unsupported | - -Below you could find the deprecated Beta annotations used to enable this feature -prior to its stable version. Newer Kubernetes versions may stop supporting these -after v1.7. Please update existing applications to use the fields directly. - -* `service.beta.kubernetes.io/external-traffic` annotation <-> `service.spec.externalTrafficPolicy` field -* `service.beta.kubernetes.io/healthcheck-nodeport` annotation <-> `service.spec.healthCheckNodePort` field - -`service.beta.kubernetes.io/external-traffic` annotation has a different set of values -compared to the `service.spec.externalTrafficPolicy` field. The values match as follows: - -* "OnlyLocal" for annotation <-> "Local" for field -* "Global" for annotation <-> "Cluster" for field - -{{< note >}} -This feature is not currently implemented for all cloudproviders/environments. -{{< /note >}} - -Known issues: - -* AWS: [kubernetes/kubernetes#35758](https://github.com/kubernetes/kubernetes/issues/35758) -* Weave-Net: [weaveworks/weave/#2924](https://github.com/weaveworks/weave/issues/2924) - -{{% /capture %}} - -{{% capture discussion %}} - ## Garbage Collecting Load Balancers In usual case, the correlating load balancer resources in cloud provider should @@ -203,7 +161,7 @@ associated Service is deleted. Finalizer Protection for Service LoadBalancers wa introduced to prevent this from happening. By using finalizers, a Service resource will never be deleted until the correlating load balancer resources are also deleted. -Specifically, if a Service has Type=LoadBalancer, the service controller will attach +Specifically, if a Service has `type` LoadBalancer, the service controller will attach a finalizer named `service.kubernetes.io/load-balancer-cleanup`. The finalizer will only be removed after the load balancer resource is cleaned up. This prevents dangling load balancer resources even in corner cases such as the @@ -217,14 +175,18 @@ enabling the [feature gate](/docs/reference/command-line-tools-reference/feature It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster. -When the service type is set to `LoadBalancer`, Kubernetes provides functionality equivalent to `type=` to pods within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service object. +When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods +within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes +pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), +firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service +object. ## Caveats and Limitations when preserving source IPs GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB kube-proxy rules which would correctly balance across all endpoints. -With the new functionality, the external traffic will not be equally load balanced across pods, but rather +With the new functionality, the external traffic is not equally load balanced across pods, but rather equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability for specifying the weight per node, they balance equally across all target nodes, disregarding the number of pods on each node). @@ -238,5 +200,3 @@ Once the external load balancers provide weights, this functionality can be adde Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. {{% /capture %}} - - diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 56cea2a220..123699856b 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -140,13 +140,13 @@ The following file is an Ingress resource that sends traffic to your Service via metadata: name: example-ingress annotations: - nginx.ingress.kubernetes.io/rewrite-target: / + nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: rules: - host: hello-world.info http: paths: - - path: /* + - path: /(.+) backend: serviceName: web servicePort: 8080 diff --git a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md index 826cd20ae5..bec97a2975 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -113,7 +113,7 @@ of `Always`. kubectl exec -it redis -- /bin/bash ``` -1. In your shell, goto `/data/redis`, and verify that `test-file` is still there. +1. In your shell, go to `/data/redis`, and verify that `test-file` is still there. ```shell root@redis:/data/redis# cd /data/redis/ root@redis:/data/redis# ls diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 03ceecc477..0fe8928260 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -262,7 +262,7 @@ and can optionally include a custom CA bundle to use to verify the TLS connectio The `host` should not refer to a service running in the cluster; use a service reference by specifying the `service` field instead. The host might be resolved via external DNS in some apiservers -(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would +(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. Please note that using `localhost` or `127.0.0.1` as a `host` is @@ -489,16 +489,11 @@ Note that in addition to file output plugin, logstash has a variety of outputs t let users route data where they want. For example, users can emit audit events to elasticsearch plugin which supports full-text search and analytics. -[kube-apiserver]: /docs/admin/kube-apiserver -[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md -[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go -[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 -[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ -[fluentd]: http://www.fluentd.org/ -[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd -[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management -[logstash]: https://www.elastic.co/products/logstash -[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html -[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation + +{{% /capture %}} + +{{% capture whatsnext %}} + +Visit [Auditing with Falco](/docs/tasks/debug-application-cluster/falco) {{% /capture %}} diff --git a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 1f996b1042..f1740d9ae7 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -63,7 +63,7 @@ case you can try several things: information: ```shell - kubectl get nodes -o yaml | egrep '\sname:\|cpu:\|memory:' + kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:' kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}' ``` diff --git a/content/en/docs/tasks/debug-application-cluster/falco.md b/content/en/docs/tasks/debug-application-cluster/falco.md new file mode 100644 index 0000000000..003b287602 --- /dev/null +++ b/content/en/docs/tasks/debug-application-cluster/falco.md @@ -0,0 +1,121 @@ +--- +reviewers: +- soltysh +- sttts +- ericchiang +content_template: templates/concept +title: Auditing with Falco +--- + +{{% capture overview %}} +### Use Falco to collect audit events + +[Falco](https://falco.org/) is an open source project for intrusion and abnormality detection for Cloud Native platforms. +This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior. + +{{% /capture %}} + +{{% capture body %}} + + +#### Install Falco + +Install Falco by using one of the following methods: + +- [Standalone Falco][falco_installation] +- [Kubernetes DaemonSet][falco_installation] +- [Falco Helm Chart][falco_helm_chart] + +Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration: + +```yaml +webserver: + enabled: true + listen_port: 8765 + k8s_audit_endpoint: /k8s_audit + ssl_enabled: false + ssl_certificate: /etc/falco/falco.pem +``` + +This configuration is typically found in the `/etc/falco/falco.yaml` file. If Falco is installed as a Kubernetes DaemonSet, edit the `falco-config` ConfigMap and add this configuration. + +#### Configure Kubernetes Audit + +1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for the [kube-apiserver][kube-apiserver] webhook audit backend. + + cat < /etc/kubernetes/audit-webhook-kubeconfig + apiVersion: v1 + kind: Config + clusters: + - cluster: + server: http://:8765/k8s_audit + name: falco + contexts: + - context: + cluster: falco + user: "" + name: default-context + current-context: default-context + preferences: {} + users: [] + EOF + +1. Start [kube-apiserver][kube-apiserver] with the following options: + + ```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig + ``` + +#### Audit Rules + +Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml][falco_k8s_audit_rules]. If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to `/etc/falco/`, so they are available for use. + +There are three classes of rules. + +The first class of rules looks for suspicious or exceptional activities, such as: + +- Any activity by an unauthorized or anonymous user. +- Creating a pod with an unknown or disallowed image. +- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking. +- Creating a NodePort service. +- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets. +- Attaching to or executing a command on a running pod. +- Creating a namespace external to a set of allowed namespaces. +- Creating a pod or service account in the kube-system or kube-public namespaces. +- Trying to modify or delete a system ClusterRole. +- Creating a ClusterRoleBinding to the cluster-admin role. +- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive. +- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods. + +A second class of rules tracks resources being created or destroyed, including: + +- Deployments +- Services +- ConfigMaps +- Namespaces +- Service accounts +- Role/ClusterRoles +- Role/ClusterRoleBindings + +The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy. + +For further details, see [Kubernetes Audit Events][falco_ka_docs] in the Falco documentation. + +[kube-apiserver]: /docs/admin/kube-apiserver +[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md +[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go +[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 +[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ +[fluentd]: http://www.fluentd.org/ +[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd +[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management +[logstash]: https://www.elastic.co/products/logstash +[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html +[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation +[falco_website]: https://www.falco.org +[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml +[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit +[falco_installation]: https://falco.org/docs/installation +[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco + +{{% /capture %}} diff --git a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index faa067a6e5..de8c538118 100644 --- a/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/en/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -20,99 +20,39 @@ where bottlenecks can be removed to improve overall performance. {{% capture body %}} -In Kubernetes, application monitoring does not depend on a single monitoring -solution. On new clusters, you can use two separate pipelines to collect -monitoring statistics by default: - -- The [**resource metrics pipeline**](#resource-metrics-pipeline) provides a limited set of metrics related - to cluster components such as the HorizontalPodAutoscaler controller, as well - as the `kubectl top` utility. These metrics are collected by - [metrics-server](https://github.com/kubernetes-incubator/metrics-server) - and are exposed via the `metrics.k8s.io` API. `metrics-server` discovers - all nodes on the cluster and queries each node's [Kubelet](/docs/admin/kubelet) - for CPU and memory usage. The Kubelet fetches the data from - [cAdvisor](https://github.com/google/cadvisor). `metrics-server` is a - lightweight short-term in-memory store. - -- A [**full metrics pipeline**](#full-metrics-pipelines), such as Prometheus, gives you access to richer - metrics. In addition, Kubernetes can respond to these metrics by automatically - scaling or adapting the cluster based on its current state, using mechanisms - such as the Horizontal Pod Autoscaler. The monitoring pipeline fetches - metrics from the Kubelet, and then exposes them to Kubernetes via an adapter - by implementing either the `custom.metrics.k8s.io` or - `external.metrics.k8s.io` API. +In Kubernetes, application monitoring does not depend on a single monitoring solution. On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or [full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics. ## Resource metrics pipeline -### Kubelet +The resource metrics pipeline provides a limited set of metrics related to +cluster components such as the [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale) controller, as well as the `kubectl top` utility. +These metrics are collected by the lightweight, short-term, in-memory +[metrics-server](https://github.com/kubernetes-incubator/metrics-server) and + are exposed via the `metrics.k8s.io` API. -The Kubelet acts as a bridge between the Kubernetes master and the nodes. It manages the pods and containers running on a machine. Kubelet translates each pod into its constituent containers and fetches individual container usage statistics from the container runtime, through the container runtime interface. For the legacy docker integration, it fetches this information from cAdvisor. It then exposes the aggregated pod resource usage statistics through the kubelet resource metrics api. This api is served at `/metrics/resource/v1alpha1` on the kubelet's authenticated and read-only ports. +metrics-server discovers all nodes on the cluster and +queries each node's +[kubelet](/docs/reference/command-line-tools-reference/kubelet) for CPU and +memory usage. The kubelet acts as a bridge between the Kubernetes master and +the nodes, managing the pods and containers running on a machine. The kubelet +translates each pod into its constituent containers and fetches individual +container usage statistics from the container runtime through the container +runtime interface. The kubelet fetches this information from the integrated +cAdvisor for the legacy Docker integration. It then exposes the aggregated pod +resource usage statistics through the metrics-server Resource Metrics API. +This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and +read-only ports. -### cAdvisor +## Full metrics pipeline -cAdvisor is an open source container resource usage and performance analysis agent. It is purpose-built for containers and supports Docker containers natively. In Kubernetes, cAdvisor is integrated into the Kubelet binary. cAdvisor auto-discovers all containers in the machine and collects CPU, memory, filesystem, and network usage statistics. cAdvisor also provides the overall machine usage by analyzing the 'root' container on the machine. +A full metrics pipeline gives you access to richer metrics. Kubernetes can +respond to these metrics by automatically scaling or adapting the cluster +based on its current state, using mechanisms such as the Horizontal Pod +Autoscaler. The monitoring pipeline fetches metrics from the kubelet and +then exposes them to Kubernetes via an adapter by implementing either the +`custom.metrics.k8s.io` or `external.metrics.k8s.io` API. -Kubelet exposes a simple cAdvisor UI for containers on a machine, via the default port 4194. -The picture below is an example showing the overall machine usage. However, this feature has been marked -deprecated in v1.10 and completely removed in v1.12. - -![cAdvisor](/images/docs/cadvisor.png) - -Starting from v1.13, you can [deploy cAdvisor as a DaemonSet](https://github.com/google/cadvisor/tree/master/deploy/kubernetes) for an access to the cAdvisor UI. - -## Full metrics pipelines - -Many full metrics solutions exist for Kubernetes. - -### Prometheus - -[Prometheus](https://prometheus.io) can natively monitor kubernetes, nodes, and prometheus itself. -The [Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/) -simplifies Prometheus setup on Kubernetes, and allows you to serve the -custom metrics API using the -[Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter). -Prometheus provides a robust query language and a built-in dashboard for -querying and visualizing your data. Prometheus is also a supported -data source for [Grafana](https://prometheus.io/docs/visualization/grafana/). - -### Sysdig -[Sysdig](http://sysdig.com) provides full spectrum container and platform intelligence, and is a -true container native solution. Sysdig pulls together data from system calls, Kubernetes events, -Prometheus metrics, statsD, JMX, and more into a single pane that gives you a comprehensive picture -of your environment. Sysdig also provides an API to query for providing robust and customizable -solutions. Sysdig is built on Open Source. [Sysdig and Sysdig Inspect](https://sysdig.com/opensource/inspect/) give you the -ability to freely perform troubleshooting, performance analyis and forensics. - -### Google Cloud Monitoring - -Google Cloud Monitoring is a hosted monitoring service you can use to -visualize and alert on important metrics in your application. You can collect -metrics from Kubernetes, and you can access them -using the [Cloud Monitoring Console](https://app.google.stackdriver.com/). -You can create and customize dashboards to visualize the data gathered -from your Kubernetes cluster. - -This video shows how to configure and run a Google Cloud Monitoring backed Heapster: - -[![how to setup and run a Google Cloud Monitoring backed Heapster](https://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](https://www.youtube.com/watch?v=xSMNR2fcoLs) - - -{{< figure src="/images/docs/gcm.png" alt="Google Cloud Monitoring dashboard example" title="Google Cloud Monitoring dashboard example" caption="This dashboard shows cluster-wide resource usage." >}} - -## CronJob monitoring - -### Kubernetes Job Monitor - -With the [Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) dashboard a Cluster Administrator can see which jobs are running and view the status of completed jobs. - -### New Relic Kubernetes monitoring integration - -[New Relic Kubernetes](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) integration provides increased visibility into the performance of your Kubernetes environment. New Relic's Kubernetes integration instruments the container orchestration layer by reporting metrics from Kubernetes objects. The integration gives you insight into your Kubernetes nodes, namespaces, deployments, replica sets, pods, and containers. - -Marquee capabilities: -View your data in pre-built dashboards for immediate insight into your Kubernetes environment. -Create your own custom queries and charts in Insights from automatically reported data. -Create alert conditions on Kubernetes data. -Learn more on this [page](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration). +[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself. +Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation. {{% /capture %}} diff --git a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md index a78bab5360..edc1d812eb 100644 --- a/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/en/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -150,7 +150,7 @@ Example: ```bash # create a plugin -echo '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz +echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz sudo chmod +x ./kubectl-foo-bar-baz # "install" our plugin by placing it on our PATH @@ -185,7 +185,7 @@ Example: ```bash # create a plugin containing an underscore in its filename -echo '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar +echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar sudo chmod +x ./kubectl-foo_bar # move the plugin into your PATH diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 02a7ef6e7d..6c43983c57 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -287,7 +287,7 @@ For example, if you had your monitoring system collecting metrics about network you could update the definition above using `kubectl edit` to look like this: ```yaml -apiVersion: autoscaling/v2beta1 +apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: php-apache diff --git a/content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md b/content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md index 3c59c00e06..81007d63a4 100644 --- a/content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md +++ b/content/en/docs/tasks/run-application/update-api-object-kubectl-patch.md @@ -311,7 +311,7 @@ The following commands are equivalent: ```shell -kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" +kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" kubectl patch deployment patch-demo --patch 'spec:\n template:\n spec:\n containers:\n - name: patch-demo-ctr-2\n image: redis' kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index 2e2794f47c..b0dd0f4ecf 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -44,7 +44,7 @@ chain and adding the parsed certificates to the `RootCAs` field in the [`tls.Config`](https://godoc.org/crypto/tls#Config) struct. You can distribute the CA certificate as a -[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-config) that your +[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your pods have access to use. ## Requesting a Certificate diff --git a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md index ff7917dccc..62f89d35bb 100644 --- a/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/en/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -146,12 +146,12 @@ The preceding command creates a To delete the Service, enter this command: - kubectl delete services my-service + kubectl delete services my-service To delete the Deployment, the ReplicaSet, and the Pods that are running the Hello World application, enter this command: - kubectl delete deployment hello-world + kubectl delete deployment hello-world {{% /capture %}} diff --git a/content/en/examples/admin/cloud/ccm-example.yaml b/content/en/examples/admin/cloud/ccm-example.yaml index e49413e4cc..20aafb31e5 100644 --- a/content/en/examples/admin/cloud/ccm-example.yaml +++ b/content/en/examples/admin/cloud/ccm-example.yaml @@ -47,7 +47,7 @@ spec: image: k8s.gcr.io/cloud-controller-manager:v1.8.0 command: - /usr/local/bin/cloud-controller-manager - - --cloud-provider= # Add your own cloud provider here! + - --cloud-provider=[YOUR_CLOUD_PROVIDER] # Add your own cloud provider here! - --leader-elect=true - --use-service-account-credentials # these flags will vary for every cloud provider diff --git a/content/es/docs/concepts/architecture/nodes.md b/content/es/docs/concepts/architecture/nodes.md index 17cd61111b..44c3029ec1 100644 --- a/content/es/docs/concepts/architecture/nodes.md +++ b/content/es/docs/concepts/architecture/nodes.md @@ -114,7 +114,7 @@ El segundo es mantener actualizada la lista interna del controlador con la lista El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue re-intentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos. En versiones de Kubernetes previas a 1.13, `NodeStatus` es el `heartbeat` del nodo. Empezando con 1.13 la funcionalidad de `node lease` se introduce como alfa (`NodeLease`, -[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento. +[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento. En Kubernetes 1.4, se actualizó la lógica del controlador de nodos para gestionar mejor los casos en los que un gran número de nodos tiene problemas alcanzando el nodo máster (Por ejemplo, cuando el nodo máster es el que tiene un problema de red). Desde 1.4, el controlador de nodos observa el estado de todos los nodos en el clúster cuando toma decisiones sobre desalojo de pods. diff --git a/content/es/docs/reference/glossary/applications.md b/content/es/docs/reference/glossary/applications.md new file mode 100644 index 0000000000..eef13eeece --- /dev/null +++ b/content/es/docs/reference/glossary/applications.md @@ -0,0 +1,13 @@ +--- +title: Applications +id: applications +date: 2019-08-06 +full_link: +short_description: > + Es la capa donde se ejecutan varias aplicaciones en contenedores. + +aka: +tags: +- fundamental +--- + Es la capa donde se ejecutan varias aplicaciones en contenedores. diff --git a/content/es/docs/reference/glossary/kubelet.md b/content/es/docs/reference/glossary/kubelet.md new file mode 100755 index 0000000000..6b479018f3 --- /dev/null +++ b/content/es/docs/reference/glossary/kubelet.md @@ -0,0 +1,20 @@ +--- +title: Kubelet +id: kubelet +date: 2018-04-12 +full_link: /docs/reference/generated/kubelet +short_description: > + Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod. + +aka: +tags: +- fundamental +- core-object +--- + Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod. + + + +El agente kubelet toma un conjunto de especificaciones de {{< glossary_tooltip text="Pod" term_id="pod" >}}, llamados + PodSpecs, que han sido creados por Kubernetes y garantiza que los contenedores descritos en ellos estén funcionando y + en buen estado. diff --git a/content/es/docs/reference/glossary/replica-set.md b/content/es/docs/reference/glossary/replica-set.md new file mode 100755 index 0000000000..d52d5ee13f --- /dev/null +++ b/content/es/docs/reference/glossary/replica-set.md @@ -0,0 +1,19 @@ +--- +title: ReplicaSet +id: replica-set +date: 2018-05-16 +full_link: /docs/concepts/workloads/controllers/replicaset/ +short_description: > + El ReplicaSet es la nueva generación del ReplicationController. + +aka: +tags: +- fundamental +- core-object +- workload +--- + El ReplicaSet es la nueva generación del ReplicationController. + + + +Un ReplicaSet, análogamente a un {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}, garantiza que un número establecido de réplicas de un pod estén corriendo en un momento dado. El ReplicaSet tiene soporte para selectores del tipo set-based, lo que permite el filtrado de claves por grupos de valores como por ejemplo todos los pods cuya etiqueta `environment` no sea `production` ni `qa`. Por otro lado, el ReplicationController solo soporta selectores equality-based, es decir, que solo puedes filtrar por valores exactos como por ejemplo, los pods que tengan la etiqueta `tier` con valor `frontend`. diff --git a/content/fr/docs/concepts/architecture/nodes.md b/content/fr/docs/concepts/architecture/nodes.md index e95525ebc1..17d5c807d3 100644 --- a/content/fr/docs/concepts/architecture/nodes.md +++ b/content/fr/docs/concepts/architecture/nodes.md @@ -144,7 +144,7 @@ Le contrôleur de noeud est responsable de la mise à jour de la condition NodeR Le contrôleur de nœud vérifie l'état de chaque nœud toutes les `--node-monitor-period` secondes. Dans les versions de Kubernetes antérieures à 1.13, NodeStatus correspond au heartbeat du nœud. -À partir de Kubernetes 1.13, la fonctionnalité de bail de nœud (node lease en anglais) est introduite en tant que fonctionnalité alpha (feature gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). +À partir de Kubernetes 1.13, la fonctionnalité de bail de nœud (node lease en anglais) est introduite en tant que fonctionnalité alpha (feature gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Lorsque la fonction de node lease est activée, chaque noeud a un objet `Lease` associé dans le namespace `kube-node-lease` qui est renouvelé périodiquement par le noeud, et NodeStatus et le node lease sont traités comme des heartbeat du noeud. Les node leases sont renouvelés fréquemment lorsque NodeStatus est signalé de nœud à master uniquement lorsque des modifications ont été apportées ou que suffisamment de temps s'est écoulé (la valeur par défaut est 1 minute, ce qui est plus long que le délai par défaut de 40 secondes pour les nœuds inaccessibles). Étant donné qu'un node lease est beaucoup plus léger qu'un NodeStatus, cette fonctionnalité rends le heartbeat d'un nœud nettement moins coûteux, tant du point de vue de l'évolutivité que des performances. diff --git a/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md index 61cfc62f4f..f0ce6315e8 100644 --- a/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/fr/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -63,5 +63,5 @@ A noter: Toutes les distributions ne sont pas activement maintenues. Choisissez * [Integration DNS](/docs/concepts/services-networking/dns-pod-service/) décrit comment résoudre un nom DNS directement vers un service Kubernetes. -* [Journalisation et surveillance de l'activité du cluster](/docs/concepts/cluster-administration/logging/) explique le fonctionnement de la connexion à Kubernetes et son implémentation. +* [Journalisation des évènements et surveillance de l'activité du cluster](/docs/concepts/cluster-administration/logging/) explique le fonctionnement de la journalisation des évènements dans Kubernetes et son implémentation. {{% /capture %}} diff --git a/content/fr/docs/concepts/overview/components.md b/content/fr/docs/concepts/overview/components.md new file mode 100644 index 0000000000..4a2376d307 --- /dev/null +++ b/content/fr/docs/concepts/overview/components.md @@ -0,0 +1,128 @@ +--- +title: Composants de Kubernetes +content_template: templates/concept +weight: 20 +card: + name: concepts + weight: 20 +--- + +{{% capture overview %}} +Ce document résume les divers composants binaires requis pour livrer +un cluster Kubernetes fonctionnel. +{{% /capture %}} + +{{% capture body %}} +## Composants Master + +Les composants Master fournissent le plan de contrôle (control plane) du cluster. +Les composants Master prennent des décisions globales à propos du cluster (par exemple, la planification (scheduling)). +Ils détectent et répondent aux événements du cluster (par exemple, démarrer un nouveau {{< glossary_tooltip text="Pod" term_id="pod">}} lorsque le champ `replicas` d'un déploiement n'est pas satisfait). + +Les composants Master peuvent être exécutés sur n'importe quelle machine du cluster. Toutefois, +par soucis de simplicité, les scripts de mise en route démarrent typiquement tous les composants master sur la +même machine et n'exécutent pas de conteneurs utilisateur sur cette machine. +Voir [Construire des Clusters en Haute Disponibilité](/docs/admin/high-availability/) pour une configuration d'exemple en multi-master-VM. + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +Ces contrôleurs incluent : + + * Node Controller : Responsable de détecter et apporter une réponse lorsqu'un nœud tombe en panne. + * Replication Controller : Responsable de maintenir le bon nombre de pods pour chaque objet + ReplicationController dans le système. + * Endpoints Controller : Remplit les objets Endpoints (c'est-à-dire joint les Services et Pods). + * Service Account & Token Controllers : Créent des comptes par défaut et des jetons d'accès à l'API + pour les nouveaux namespaces. + +### cloud-controller-manager + +Le [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) exécute les contrôleurs +qui interagissent avec les fournisseurs cloud sous-jacents. Le binaire du cloud-controller-manager est une +fonctionnalité alpha introduite dans la version 1.6 de Kubernetes. + +Le cloud-controller-manager exécute seulement les boucles spécifiques des fournisseurs cloud. +Vous devez désactiver ces boucles de contrôleurs dans le kube-controller-manager. +Vous pouvez désactiver les boucles de contrôleurs en définissant la valeur du flag `--cloud-provider` à `external` lors du démarrage du kube-controller-manager. + +Le cloud-controller-manager permet au code du fournisseur cloud et au code de Kubernetes d'évoluer indépendamment l'un de l'autre. +Dans des versions antérieures, le code de base de Kubernetes dépendait du code spécifique du fournisseur cloud pour la fonctionnalité. Dans des versions ultérieures, le code spécifique des fournisseurs cloud devrait être maintenu par les fournisseurs cloud eux-mêmes et lié au cloud-controller-manager lors de l'exécution de Kubernetes. + +Les contrôleurs suivants ont des dépendances vers des fournisseurs cloud : + + * Node Controller : Pour vérifier le fournisseur de cloud afin de déterminer si un nœud a été supprimé dans le cloud après avoir cessé de répondre + * Route Controller : Pour mettre en place des routes dans l'infrastructure cloud sous-jacente + * Service Controller : Pour créer, mettre à jour et supprimer les load balancers des fournisseurs cloud + * Volume Controller : Pour créer, attacher et monter des Volumes, et interagir avec le fournisseur cloud pour orchestrer les volumes. + +## Composants de nœud + +Les composants de nœud (Node components) s'exécutent sur chaque nœud, en maintenant les pods en exécution +et en fournissant l'environnement d'exécution Kubernetes. + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +{{< glossary_definition term_id="kube-proxy" length="all" >}} + +### Container Runtime + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## Addons + +Les addons utilisent les ressources Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) +pour implémenter des fonctionnalités cluster. Comme ces derniers fournissent des fonctionnalités au niveau +du cluster, les ressources dans des namespaces pour les addons appartiennent au namespace `kube-system`. + +Les addons sélectionnés sont décrits ci-dessous. Pour une liste étendue des addons disponibles, voir la page +[Addons](/docs/concepts/cluster-administration/addons/). + +### DNS + +Tandis que les autres addons ne sont pas strictement requis, tous les clusters Kubernetes devraient avoir un +[DNS cluster](/fr/docs/concepts/services-networking/dns-pod-service/) car de nombreux exemples en dépendent. + +Le DNS Cluster est un serveur DNS, en plus des autres serveurs DNS dans votre environnement, qui sert +les enregistrements DNS pour les services Kubernetes. + +Les conteneurs démarrés par Kubernetes incluent automatiquement ce serveur DNS dans leurs recherches DNS. + +### Interface utilisateur Web (Dashboard) + +Le [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) est une interface utilisateur web à but général pour les clusters Kubernetes. Il permet aux utilisateurs de gérer et de dépanner aussi bien des +applications s'exécutant dans le cluster que le cluster lui-même. + +### La surveillance des ressources de conteneur + +[La surveillance des ressources de conteneur](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) enregistre des métriques chronologiques génériques à propos des conteneurs dans une base de données centrale et +fournit une interface utilisateur pour parcourir ces données. + +### Le logging au niveau cluster + +Un mécanisme de [logging au niveau cluster](/docs/concepts/cluster-administration/logging/) est chargé +de sauvegarder les logs des conteneurs dans un magasin de logs central avec une interface de recherche/navigation. + +{{% /capture %}} +{{% capture whatsnext %}} +* En savoir plus sur les [Nœuds](/fr/docs/concepts/architecture/nodes/) +* En savoir plus sur [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) +* Lire la [documentation officielle d'etcd](https://etcd.io/docs/) +{{% /capture %}} diff --git a/content/fr/docs/concepts/storage/volumes.md b/content/fr/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..3a5e748090 --- /dev/null +++ b/content/fr/docs/concepts/storage/volumes.md @@ -0,0 +1,1250 @@ +--- +title: Volumes +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +Les fichiers sur disque dans un conteneur sont éphémères, ce qui présente des problèmes pour +des applications non-triviales lorsqu'elles s'exécutent dans des conteneurs. Premièrement, lorsqu'un +conteneur plante, kubelet va le redémarrer mais les fichiers seront perdus - le conteneur démarre +avec un état propre. Deuxièmement, lorsque plusieurs conteneurs s'exécutent ensemble dans un `Pod`, +il est souvent nécessaire de partager des fichiers entre ces conteneurs. L'abstraction Kubernetes +`Volume` résout ces deux problèmes. + +Une connaissance des [Pods](/fr/docs/concepts/workloads/pods/pod) est suggérée. + +{{% /capture %}} + +{{% capture body %}} + +## Contexte + +Docker a également un concept de [volumes](https://docs.docker.com/engine/admin/volumes/), bien qu'il +soit, dans une certaine mesure, plus relâché et moins géré. +Avec Docker, un volume est simplement un dossier sur le disque ou dans un autre conteneur. +Les durées de vie ne sont pas gérées et, jusqu'à très récemment, seuls les volumes supportés par un disque local l'étaient. +Docker fournit maintenant des pilotes de volume, mais la fonctionnalité est très limitée pour le moment (par exemple, à partir de Docker 1.7, seulement un pilote de volume est autorisé par conteneur et il n'est pas possible de passer des paramètres aux volumes). + +Un volume Kubernetes, en revanche, a une durée de vie explicite - la même que le Pod qui l'inclut. +Par conséquent, un volume survit aux conteneurs qui s'exécutent à l'intérieur du Pod et les données sont préservées lorsque le conteneur redémarre. +Bien sûr, lorsqu'un Pod cesse d'exister, le volume va également cesser d'exister. +Peut-être plus important encore, Kubernetes supporte de nombreux types de volumes et un Pod peut en utiliser plusieurs simultanément. + +À la base, un volume est juste un dossier, contenant possiblement des données, qui est accessible aux conteneurs dans un Pod. La manière dont ce dossier est créé, le support qui le sauvegarde et son contenu sont déterminés par le type de volume utilisé. + +Pour utiliser un volume, un Pod spécifie les volumes à fournir au Pod (le champ `.spec.volumes`) +et où les monter dans les conteneurs (le champ `.spec.containers.volumeMounts`). + +Un processus dans un conteneur a une vue système de fichiers composée de son image et de ses volumes Docker. +L'[image Docker](https://docs.docker.com/userguide/dockerimages/) est à la racine de la hiérarchie du système de fichiers et tous les volumes sont montés sur les chemins spécifiés dans l'image. +Les volumes ne peuvent pas être montés sur d'autres volumes ou avoir des liens physiques vers d'autres volumes. +Chaque conteneur dans le Pod doit spécifier indépendamment où monter chaque volume. + +## Types de Volumes + +Kubernetes supporte plusieurs types de Volumes: + + * [awsElasticBlockStore](#awselasticblockstore) + * [azureDisk](#azuredisk) + * [azureFile](#azurefile) + * [cephfs](#cephfs) + * [cinder](#cinder) + * [configMap](#configmap) + * [csi](#csi) + * [downwardAPI](#downwardapi) + * [emptyDir](#emptydir) + * [fc (fibre channel)](#fc) + * [flexVolume](#flexVolume) + * [flocker](#flocker) + * [gcePersistentDisk](#gcepersistentdisk) + * [gitRepo (deprecated)](#gitrepo) + * [glusterfs](#glusterfs) + * [hostPath](#hostpath) + * [iscsi](#iscsi) + * [local](#local) + * [nfs](#nfs) + * [persistentVolumeClaim](#persistentvolumeclaim) + * [projected](#projected) + * [portworxVolume](#portworxvolume) + * [quobyte](#quobyte) + * [rbd](#rbd) + * [scaleIO](#scaleio) + * [secret](#secret) + * [storageos](#storageos) + * [vsphereVolume](#vspherevolume) + +Toute contribution supplémentaire est la bienvenue. + +### awsElasticBlockStore {#awselasticblockstore} + +Un type de volume `awsElasticBlockStore` monte un [Volume EBS](http://aws.amazon.com/ebs/) d'Amazon Web Services (AWS) dans un Pod. +À la différence de `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume EBS +est préservé et le volume est seulement démonté. Cela signifie qu'un volume EBS peut être prérempli avec des données et que les données peuvent être transmises entre les Pods. + +{{< caution >}} +Vous devez créer un volume EBS avec la commande `aws ec2 create-volume` ou l'API AWS avant de pouvoir l'utiliser. +{{< /caution >}} + +Des restrictions existent lorsque l'on utilise un volume `awsElasticBlockStore` : + +* les nœuds dans lesquels les Pods s'exécutent doivent être des instances AWS EC2 +* ces instances doivent être dans la même région et la même zone de disponibilité que le volume EBS +* EBS supporte uniquement le montage d'un volume par une seule instance EC2 + +#### Création d'un volume EBS + +Avant que vous puissiez utiliser un volume EBS dans un Pod, vous devez le créer. + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + +Assurez-vous que la zone correspond à la zone de votre grappe de serveurs (cluster). +(Et vérifiez aussi que la taille et le type du volume EBS conviennent à votre utilisation!) + +#### Exemple de configuration AWS EBS + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # Ce volume AWS EBS doit déjà exister. + awsElasticBlockStore: + volumeID: + fsType: ext4 +``` + +#### Migration CSI + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +La fonctionnalité de migration CSI pour awsElasticBlockStore, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `ebs.csi.aws.com`. +Afin d'utiliser cette fonctionnalité, le [Pilote AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationAWS` doivent être activées. + +### azureDisk {#azuredisk} + +Un type de volume `azureDisk` est utilisé pour monter un disque de données ([Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)) dans un Pod. + +Plus de détails sont disponibles [ici](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md). + +#### Migration CSI + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +La fonctionnalité de migration CSI pour azureDisk, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `disk.csi.azure.com`. +Afin d'utiliser cette fonctionnalité, le [Pilote Azure Disk CSI](https://github.com/kubernetes-sigs/azuredisk-csi-driver) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationAzureDisk` doivent être activées. + +### azureFile {#azurefile} + +Un type de volume `azureFile` est utilisé pour monter un volume de fichier Microsoft Azure (SMB 2.1 et 3.0) dans un Pod. + +Plus de détails sont disponibles [ici](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). + +#### Migration CSI + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +La fonctionnalité de migration CSI pour azureFile, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `file.csi.azure.com`. +Afin d'utiliser cette fonctionnalité, le [Pilote Azure File CSI](https://github.com/kubernetes-sigs/azurefile-csi-driver) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationAzureFile` doivent être activées. + +### cephfs {#cephfs} + +Un volume `cephfs` permet de monter un volume CephFS existant dans un Pod. +Contrairement à `emptyDir`, qui est écrasé quand un Pod est supprimé, le contenu d'un volume `cephfs` est préservé et le volume est simplement démonté. +Cela signifie qu'un volume CephFS peut être prérempli avec des données et ces données peuvent être transmises entre les Pods. +CephFS peut être monté plusieurs fois en écriture simultanément. + +{{< caution >}} +Vous devez exécuter votre propre serveur Ceph avec le partage exporté avant de pouvoir l'utiliser. +{{< /caution >}} + +Voir [l'exemple CephFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) pour plus de détails. + +### cinder {#cinder} + +{{< note >}} +prérequis : Kubernetes avec le fournisseur infonuagique OpenStack (OpenStack Cloud Provider) configuré. +Pour la configuration cloudprovider, se référer à [cloud provider openstack](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack). +{{< /note >}} + +`cinder` est utilisé pour monter un volume Cinder OpenStack dans un Pod. + +#### Exemple de configuration d'un volume Cinder + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-cinder +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-cinder-container + volumeMounts: + - mountPath: /test-cinder + name: test-volume + volumes: + - name: test-volume + # Ce volume OpenStack doit déjà exister. + cinder: + volumeID: + fsType: ext4 +``` + +#### Migration CSI + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +La fonctionnalité de migration CSI pour Cinder, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `cinder.csi.openstack.org`. +Afin d'utiliser cette fonctionnalité, le [Pilote Cinder CSI](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationOpenStack` doivent être activées. + +### configMap {#configmap} + +La ressource [`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) fournit un moyen d'injecter des données de configuration dans les Pods. +Les données stockées dans un objet `ConfigMap` peuvent être référencées dans un volume de type `configMap` +et être ensuite consommées par des applications conteneurisées s'exécutant dans un Pod. + +Lorsque l'on référence un objet `configMap`, on peut simplement fournir son nom dans le volume +pour le référencer. On peut également personnaliser le chemin pour utiliser une entrée spécifique dans +la ConfigMap. Par exemple, pour monter la ConfigMap `log-config` sur un Pod appelé `configmap-pod`, +vous pourriez utiliser le YAML suivant : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + +La ConfigMap `log-config` est montée comme un volume et tout le contenu stocké dans son entrée `log_level` +est monté dans le Pod au chemin "`/etc/config/log_level`". +À noter que ce chemin est dérivé du `mountPath` du volume et le `path` est étiqueté avec la clef `log_level`. + +{{< caution >}} +Vous devez créer une [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) avant de pouvoir l'utiliser. +{{< /caution >}} + +{{< note >}} +Un conteneur utilisant une ConfigMap en tant que montage de volume [subPath](#using-subpath) ne recevra pas les mises à jour de la ConfigMap. +{{< /note >}} + +### downwardAPI {#downwardapi} + +Un volume `downwardAPI` est utilisé pour rendre disponibles aux applications les données de l'API Downward. +Il monte un dossier et écrit les données demandées dans des fichiers de texte brut. + +{{< note >}} +Un conteneur utilisant l'API Downward en tant que montage de volume [subPath](#using-subpath) ne recevra pas les mises à jour de l'API Downward. +{{< /note >}} + +Voir [l'exemple de volume `downwardAPI`](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) pour plus de détails. + +### emptyDir {#emptydir} + +Un volume `emptyDir` est d'abord créé lorsqu'un Pod est assigné à un nœud et existe aussi longtemps que le Pod s'exécute sur ce nœud. +Comme le nom l'indique, le volume est initialement vide. Les conteneurs dans le Pod peuvent tous lire et écrire les mêmes fichiers dans le volume `emptyDir`, bien que ce volume puisse être monté sur le même ou différents chemins dans chaque conteneur. +Lorsqu'un Pod est supprimé d'un nœud pour une raison quelconque, les données dans le `emptyDir` sont supprimées à jamais. + +{{< note >}} +Un conteneur qui plante ne retire *PAS* un Pod d'un nœud, ainsi, les données présentes dans un `emptyDir` sont protégées en cas de plantage du conteneur. +{{< /note >}} + +Des cas d'utilisation pour un `emptyDir` peuvent être : + +* un espace de travail, par exemple pour un tri fusion sur disque. +* l'établissement d'un point de reprise d'un long calcul à des fins de récupération des données après un crash. +* le stockage de fichiers qu'un conteneur de gestion de contenu va chercher pendant qu'un conteneur serveur web expose les données. + +Par défaut, les volumes `emptyDir` sont stockés sur tout médium supporté par le nœud - que ce soit un disque dur, un disque SSD ou un stockage réseau, dépendamment de l'environnement. +Cependant, vous pouvez définir le champ `emptyDir.medium` à `"Memory"` pour indiquer à Kubernetes de monter un tmpfs (système de fichiers supporté par la RAM) pour vous à la place. +Tandis que tmpfs est très rapide, soyez conscient qu'au contraire des disques, un tmpfs est effacé au redémarrage du nœud et tous les fichiers que vous écrivez seront comptabilisés dans la limite de mémoire de votre conteneur. + +#### Exemple de Pod + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + +### fc (fibre channel) {#fc} + +Un volume `fc` permet à un volume Fibre Channel existant d'être monté dans un Pod. +Vous pouvez spécifier une ou plusieurs cibles World Wide Names en utilisant le paramètre +`targetWWNs` dans votre configuration de volume. +Si plusieurs WWNs sont spécifiés, targetWWNs s'attend à ce que ces WWNs proviennent de connexions multi-path. + +{{< caution >}} +Vous devez configurer un zonage FC SAN pour allouer et masquer au préalable ces LUNs (volumes) aux cibles WWNs afin que les hôtes Kubernetes puissent y accéder. +{{< /caution >}} + +Voir [l'exemple FC](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) pour plus de détails. + +### flocker {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker) est un gestionnaire de volumes de données en cluster open-source. Il assure la gestion et l'orchestration de volumes de données supportés par divers serveurs de stockage. + +Un volume `flocker` permet de monter un ensemble de données Flocker dans un Pod. +Si l'ensemble de données n'existe pas déjà dans Flocker, il doit d'abord être créé avec la CLI Flocker ou en utilisant l'API Flocker. +Si l'ensemble de données existe déjà, il sera réattaché par Flocker au nœud sur lequel le Pod est planifié. +Cela signifie que les données peuvent être transmises entre les Pods selon les besoins. + +{{< caution >}} +Vous devez exécuter votre propre installation de Flocker avant de pouvoir l'utiliser. +{{< /caution >}} + +Voir [l'exemple Flocker](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) pour plus de détails. + +### gcePersistentDisk {#gcepersistentdisk} + +Un volume `gcePersistentDisk` monte un [Disque Persistant](http://cloud.google.com/compute/docs/disks) Google Compute Engine (GCE) dans un Pod. +À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un disque persistant est préservé et le volume est simplement démonté. Cela signifie qu'un disque persistant peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods. + +{{< caution >}} +Vous devez créer un disque persistant en utilisant `gcloud`, l'API GCE ou l'interface utilisateur avant de pouvoir utiliser ce disque. +{{< /caution >}} + +Des restrictions existent lors de l'utilisation d'un `gcePersistentDisk`: + +* les nœuds sur lesquels les Pods s'exécutent doivent être des machines virtuelles (VMs) GCE. +* ces VMs doivent se trouver dans le même projet et la même zone GCE que le disque persistant + +Une fonctionnalité des disques persistants est qu'ils peuvent être montés en lecture seule par plusieurs consommateurs simultanément. +Cela signifie que vous pouvez préremplir un disque persistant avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. +Malheureusement, les disques persistants peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. + +Utiliser un disque persistant dans un Pod contrôlé par un ReplicationController échouera à moins que le disque persistant soit en lecture seule ou que le nombre de répliques soit de 0 ou 1. + +#### Création d'un disque persistant + +Avant de pouvoir utiliser un disque persistant GCE avec un Pod, vous devez le créer. + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + +#### Exemple de Pod + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # Ce disque persistant GCE doit déjà exister. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### Disques persistants régionaux +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +La fonctionnalité de disques persistants régionaux ([Regional Persistent Disks](https://cloud.google.com/compute/docs/disks/#repds)) permet la création de disques persistants disponibles dans deux zones à l'intérieur d'une même région. +Afin d'utiliser cette fonctionnalité, le volume doit être provisionné en tant que PersistentVolume; le référencement du volume directement depuis un Pod n'est pas supporté. + +#### Provisionnement manuel d'un disque persistant régional en tant que PersistentVolume + +Le provisionnement dynamique est possible en utilisant une [StorageClass pour un disque persistant GCE](/docs/concepts/storage/storage-classes/#gce). +Avant de créer un PersistentVolume, vous devez créer le disque persistant : +```shell +gcloud beta compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` +Exemple de spec PersistentVolume : + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume + labels: + failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### Migration CSI + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +La fonctionnalité de migration CSI pour un disque persistant GCE, lorsque activée, fixe toutes les opérations de plugin depuis le plugin "in-tree" vers le pilote de l'interface CSI (Container Storage Interface) `pd.csi.storage.gke.io`. +Afin d'utiliser cette fonctionnalité, le [Pilote CSI de disque persistant GCE](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) doit être installé dans le cluster et les fonctionnalités Alpha `CSIMigration` et `CSIMigrationGCE` doivent être activées. + +### gitRepo (obsolète) {#gitrepo} + +{{< warning >}} +Le type de volume gitRepo est obsolète. Pour provisionner un conteneur avec un dépôt git, il faut monter un [EmptyDir](#emptydir) dans un InitContainer qui clone le dépôt en utilisant git, ensuite, monter le [EmptyDir](#emptydir) dans le conteneur du Pod. +{{< /warning >}} + +Un volume `gitRepo` est un exemple de ce qui peut être réalisé en tant que plugin de volume. +Cela monte un dossier vide et clone un dépôt git à l'intérieur, à la disposition d'un Pod. +Dans le futur, de tels volumes pourraient être déplacé vers un modèle encore plus découplé plutôt qu'étendre l'API Kubernetes pour chaque cas d'utilisation. + +Voici un exemple d'un volume gitRepo : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs {#glusterfs} + +Un volume `glusterfs` permet à un volume [Glusterfs](http://www.gluster.org) (un système de fichiers en réseau open +source) d'être monté dans un Pod. À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé. le contenu d'un volume `glusterfs` est préservé et le volume est simplement démonté. +Cela signifie qu'un volume glusterfs peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods. +GlusterFS peut être monté plusieurs fois en écriture simultanément. + +{{< caution >}} +Vous devez exécuter votre propre installation de GlusterFS avant de pouvoir l'utiliser. +{{< /caution >}} + +Voir [l'exemple GlusterFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) pour plus de détails. + +### hostPath {#hostpath} + +Un volume `hostPath` monte un fichier ou un dossier depuis le système de fichiers du nœud hôte à l'intérieur d'un Pod. +Ce ne sera pas requis pour la plupart des Pods, mais cela offre une puissante solution de secours pour certaines applications. + +Par exemple, des utilisations du `hostPath` peuvent être : + +* exécuter un conteneur qui nécessite l'accès aux éléments internes de Docker; utiliser un `hostPath` de `/var/lib/docker` +* exécuter cAdvisor dans un conteneur; utiliser un `hostPath` de `/sys` +* autoriser un Pod à spécifier si un `hostPath` donné devrait exister avant la mise en exécution du Pod, s'il devrait être créé et en tant que quoi il devrait exister. + +En plus de la propriété requise `path`, un utilisateur peut optionnellement spécifier un `type` pour un volume `hostPath`. + +Les valeurs supportées pour le champ `type` sont les suivantes : + + +| Valeur | Comportement | +|:------|:---------| +| | Une chaîne de caractères vide (par défaut) sert à la rétrocompatibilité, ce qui signifie qu'aucune vérification ne sera effectuée avant de monter le volume hostPath. | +| `DirectoryOrCreate` | Si rien n'existe au chemin fourni, un dossier vide y sera créé au besoin avec les permissions définies à 0755, avec le même groupe et la même possession que Kubelet. | +| `Directory` | Un dossier doit exister au chemin fourni | +| `FileOrCreate` | Si rien n'existe au chemin fourni, un fichier vide y sera créé au besoin avec les permissions définies à 0644, avec le même groupe et la même possession que Kubelet. | +| `File` | Un fichier doit exister au chemin fourni | +| `Socket` | Un socket UNIX doit exister au chemin fourni | +| `CharDevice` | Un périphérique en mode caractère doit exister au chemin fourni | +| `BlockDevice` | Un périphérique en mode bloc doit exister au chemin fourni | + +Une attention particulière doit être portée lors de l'utilisation de ce type de volume car : + +* les Pods avec une configuration identique (tels que ceux créés depuis un podTemplate) peuvent se comporter différemment sur des nœuds différents à cause de fichiers différents sur les nœuds. +* lorsque Kubernetes ajoute une planification tenant compte des ressources, comme prévu, il ne pourra pas prendre en compte les ressources utilisées par un `hostPath`. +* les fichiers ou dossiers créés sur les hôtes sous-jacents ne sont accessibles en écriture que par root. Vous devez soit exécuter votre programme en tant que root dans un [conteneur privilégié](/docs/user-guide/security-context) ou modifier les permissions du fichier sur l'hôte pour pouvoir écrire dans un volume `hostPath`. + +#### Exemple de Pod + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # chemin du dossier sur l'hôte + path: /data + # ce champ est optionnel + type: Directory +``` + +### iscsi {#iscsi} + +Un volume `iscsi` permet à un volume existant iSCSI (SCSI over IP) d'être monté dans un Pod. +À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `iscsi` est préservé et le volume est simplement démonté. +Cela signifie qu'un volume iscsi peut être prérempli avec des données que ces données peuvent être transmises entre les Pods. + +{{< caution >}} +Vous devez exécuter votre propre serveur iSCSI avec le volume créé avant de pouvoir l'utiliser. +{{< /caution >}} + +Une fonctionnalité de iSCSI est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément. +Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. +Malheureusement, les volumes iSCSI peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. + +Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) pour plus de détails. + +### local {#local} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +Un volume `local` représente un périphérique de stockage local monté tels qu'un disque, une partition ou un dossier. + +Les volumes locaux peuvent seulement être utilisés comme un PersistentVolume créé statiquement. +Le provisionnement dynamique n'est pas encore supporté. + +Comparés aux volumes `hostPath`, les volumes locaux peuvent être utilisés de manière durable et portable sans planifier manuellement des Pods sur les nœuds, puisque le système est conscient des contraintes de nœud du volume en examinant l'affinité de nœud sur le PersistentVolume. + +Toutefois, les volumes locaux sont encore sujets à la disponibilité du nœud sous-jacent et ne conviennent pas à toutes les applications. Si un nœud devient "en mauvaise santé" (unhealthy), alors le volume local deviendra également inaccessible et un Pod qui l'utilise ne sera pas en mesure de s'exécuter. Les applications qui utilisent des volumes locaux doivent être en mesure de tolérer cette disponibilité réduite, ainsi que de potentielles pertes de données, dépendamment des caractéristiques de durabilité du disque sous-jacent. + +L'exemple suivant traite d'une spec d'un PersistentVolume utilisant un volume `local` et une `nodeAffinity`: + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + # le champ volumeMode requiert l'activation de la "feature gate" Alpha BlockVolume + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + +La `nodeAffinity` d'un PersistentVolume est requise lors de l'utilisation de volumes locaux. +Cela permet au planificateur (scheduler) Kubernetes de planifier correctement des Pods utilisant des volumes locaux aux bons nœuds. + +Le `volumeMode` d'un PersistentVolume peut maintenant être configuré à "Block" (au lieu de la valeur par défaut "Filesystem") pour exposer le volume local en tant que périphérique bloc brut (raw block device). +Le champ `volumeMode` requiert l'activation de la "feature gate" Alpha `BlockVolume`. + +Lors de l'utilisation des volumes locaux, il est recommandé de créer une StorageClass avec `volumeBindingMode` configuré à `WaitForFirstConsumer`. Voir [l'exemple](/docs/concepts/storage/storage-classes/#local). Retarder la liaison (binding) du volume garantit que la décision de liaison du PersistentVolumeClaim sera également évaluée avec toutes les autres contraintes de nœud que le Pod peut avoir, tels que les exigences en ressources du nœud, les sélecteurs de nœud, leur affinité et leur anti-affinité. + +Un provisionneur statique externe peut être exécuté séparément pour une gestion améliorée du cycle de vie du volume local. +Noter que ce provisionneur ne supporte pas encore le provisionnement dynamique. Pour un exemple sur la façon d'exécuter un provisionneur externe local, voir le [guide utilisateur de provisionneur de volume local](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner). + +{{< note >}} +Le PersistentVolume local requiert un nettoyage manuel et une suppression par l'utilisateur si le provisionneur statique n'est pas utilisé pour gérer le cycle de vie du volume. +{{< /note >}} + +### nfs {#nfs} + +Un volume `nfs` permet à un partage NFS (Network File System) existant d'être monté dans un Pod. +À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `nfs` est préservé et le volume est simplement démonté. +Cela signifie qu'un volume NFS peut être prérempli avec des données et que les données peuvent être transmises entre les Pods. NFS peut être monté plusieurs fois en écriture simultanément. + +{{< caution >}} +Vous devez exécuter votre propre serveur NFS avec le partage exporté avant de pouvoir l'utiliser. +{{< /caution >}} + +Voir [l'exemple NFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) pour plus de détails. + +### persistentVolumeClaim {#persistentvolumeclaim} + +Un volume `persistentVolumeClaim` est utilisé pour monter un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) dans un Pod. Les PersistentVolumes sont une manière pour les utilisateurs de "revendiquer" un stockage durable (comme un PersistentDisk GCE ou un volume iSCSI) sans savoir les détails d'un environnement cloud particulier. + +Voir [l'exemple PersistentVolumes](/docs/concepts/storage/persistent-volumes/) pour plus de détails. + +### projected {#projected} + +Un volume `projected` mappe plusieurs sources de volume existantes dans le même dossier. + +Actuellement, les types de sources de volume suivantes peuvent être projetés : + +- [`secret`](#secret) +- [`downwardAPI`](#downwardapi) +- [`configMap`](#configmap) +- `serviceAccountToken` + +Toutes les sources doivent se trouver dans le même namespace que celui du Pod. Pour plus de détails, voir le [document de conception tout-en-un ](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). + +La projection des jetons de compte de service (service account) est une fonctionnalité introduite dans Kubernetes 1.11 et promue en Beta dans la version 1.12. +Pour activer cette fonctionnalité dans la version 1.11, il faut configurer explicitement la ["feature gate" `TokenRequestProjection`](/docs/reference/command-line-tools-reference/feature-gates/) à "True". + +#### Exemple d'un Pod avec un secret, une API downward et une configmap. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "cpu_limit" + resourceFieldRef: + containerName: container-test + resource: limits.cpu + - configMap: + name: myconfigmap + items: + - key: config + path: my-group/my-config +``` + +#### Exemple d'un Pod avec plusieurs secrets avec une configuration de mode de permission autre que celle par défaut. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - secret: + name: mysecret2 + items: + - key: password + path: my-group/my-password + mode: 511 +``` + +Chaque source de volume projeté est listée dans la spec, sous `sources`. Les paramètres sont à peu près les mêmes avec deux exceptions : + +* Pour les secrets, le champ `secretName` a été changé par `name` pour être consistant avec le nommage des ConfigMap. +* Le `defaultMode` peut seulement être spécifié au niveau projeté et non pour chaque source de volume. Cependant, tel qu'illustré au-dessus, il est possible de configurer explicitement le `mode` pour chaque projection individuelle. + +Lorsque la fonctionnalité `TokenRequestProjection` est activée, vous pouvez injecter le jeton pour le [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens) courant dans un Pod au chemin spécifié. Ci-dessous, un exemple : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: sa-token-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: token-vol + mountPath: "/service-account" + readOnly: true + volumes: + - name: token-vol + projected: + sources: + - serviceAccountToken: + audience: api + expirationSeconds: 3600 + path: token +``` + +Le pod d'exemple possède un volume projeté contenant le jeton injecté du service account. +Ce jeton peut être utilisé par des conteneurs de Pod pour accéder au service d'API Kubernetes API, par exemple. +Le champ `audience` contient l'audience-cible du jeton. +Un destinataire du jeton doit s'identifier avec un identificateur spécifié dans l'audience du jeton, sinon il doit rejeter le jeton. Ce champ est facultatif et sa valeur par défaut est l'identifiant du serveur API. + +Le champ `expirationSeconds` est la durée de validité attendue du jeton de service account. +Sa valeur par défaut est de 1 heure et doit être au moins de 10 minutes (600 secondes). Un administrateur peut aussi limiter sa valeur maximum en spécifiant l'option `--service-account-max-token-expiration` pour le serveur API. +Le champ `path` spécifie un chemin relatif au point de montage du volume projeté. + +{{< note >}} +Un conteneur utilisant une source de volume projeté en tant que point de montage de volume [subPath](#using-subpath) ne recevra pas de mises à jour pour ces sources de volume. +{{< /note >}} + +### portworxVolume {#portworxvolume} + +Un `portworxVolume` est une couche de stockage bloc élastique qui s'exécute de manière hyperconvergée avec Kubernetes. +[Portworx](https://portworx.com/use-case/kubernetes-storage/) donne l'empreinte digitale d'un stockage dans un serveur, tiers basés sur les capacités et agrège la capacité sur plusieurs serveurs. Portworx s'exécute en invité sur des machines virtuelles ou sur des nœuds Linux bare metal. + +Un `portworxVolume` peut être créé dynamiquement à travers Kubernetes ou il peut également être pré-provisionné et référencé à l'intérieur d'un Pod Kubernetes. +Voici un exemple de Pod référençant un PortworxVolume pré-provisionné : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # Ce volume Portworx doit déjà exister. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< caution >}} +Il faut s'assurer d'avoir un PortworxVolume existant avec le nom `pxvol` avant de l'utiliser dans le Pod. +{{< /caution >}} + +Plus de détails et d'exemples peuvent être trouvé [ici](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md). + +### quobyte {#quobyte} + +Un volume `quobyte` permet à un volume existant [Quobyte](http://www.quobyte.com) d'être monté dans un Pod. + +{{< caution >}} +Vous devez exécuter votre propre configuration Quobyte avec les volumes créés avant de pouvoir l'utiliser. +{{< /caution >}} + +Quobyte supporte le {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. +CSI est le plugin recommandé pour utiliser les volumes Quobyte volumes dans Kubernetes. Le projet GitHub Quobyte dispose [d'instructions](https://github.com/quobyte/quobyte-csi#quobyte-csi) pour déployer Quobyte en utilisant CSI, avec des exemples. + +### rbd {#rbd} + +Un volume `rbd` permet à un volume périphérique bloc Rados ([Rados Block +Device](http://ceph.com/docs/master/rbd/rbd/)) d'être monté dans un Pod. +À la différence d'un `emptyDir`, qui est écrasé lorsqu'un Pod est supprimé, le contenu d'un volume `rbd` est préservé et le volume est simplement démonté. +Cela signifie qu'un volume RBD peut être prérempli avec des données et que ces données peuvent être transmises entre les Pods. + +{{< caution >}} +Vous devez exécuter votre propre installation Ceph avant de pouvoir utiliser RBD. +{{< /caution >}} + +Une fonctionnalité de RBD est qu'il peut être monté en lecture seule par plusieurs consommateurs simultanément. +Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. +Malheureusement, les volumes RBD peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. + +Voir [l'exemple RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) pour plus de détails. + +### scaleIO {#scaleio} + +ScaleIO est une plateforme de stockage logicielle qui peut utiliser du matériel physique existant pour créer des clusters de stockage bloc partagé en réseau évolutif. +Le plugin de volume `scaleIO` permet aux Pods déployés d'accéder à des volumes ScaleIO existants (ou il peut provisionner dynamiquement de nouveaux volumes pour des revendications de volumes persistants, voir [ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)). + +{{< caution >}} +Vous devez exécuter un cluster ScaleIO déjà configuré avec les volumes créés avant de pouvoir les utiliser. +{{< /caution >}} + +L'exemple suivant montre une configuration de Pod avec ScaleIO : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-0 +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: pod-0 + volumeMounts: + - mountPath: /test-pd + name: vol-0 + volumes: + - name: vol-0 + scaleIO: + gateway: https://localhost:443/api + system: scaleio + protectionDomain: sd0 + storagePool: sp1 + volumeName: vol-0 + secretRef: + name: sio-secret + fsType: xfs +``` + +Pour plus de détails, consulter [les exemples ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio). + +### secret {#secret} + +Un volume `secret` est utilisé pour fournir des informations sensibles, comme des mots de passe, aux Pods. +Vous pouvez stocker des secrets dans l'API Kubernetes et les monter en tant que fichiers pour être utilisés par les Pods sans les coupler directement avec Kubernetes. Les volumes `secret` sont supportés par tmpfs (un système de fichiers en RAM) pour qu'ils ne soient jamais écrits sur du stockage non volatil. + +{{< caution >}} +Vous devez créer un secret dans l'API Kubernetes avant de pouvoir l'utiliser. +{{< /caution >}} + +{{< note >}} +Un conteneur utilisant un secret en tant que point de montage de volume [subPath](#using-subpath) ne recevra pas les mises à jour des secrets. +{{< /note >}} + +Les secrets sont décrits plus en détails [ici](/docs/user-guide/secrets). + +### storageOS {#storageos} + +Un volume `storageos` permet à un volume [StorageOS](https://www.storageos.com) existant d'être monté dans un Pod. + +StorageOS s'exécute en tant que conteneur dans l'environnement Kubernetes en rendant le stockage local ou attaché accessible depuis n'importe quel nœud dans le cluster Kubernetes. +Les données peuvent être répliquées pour se protéger des défaillances de nœuds. +Les techniques d'allocation fine et dynamique et de compression peuvent améliorer l'utilisation et réduire les coûts. + +À la base, StorageOS fournit un stockage bloc aux conteneurs accessible via un système de fichiers. + +Le conteneur StorageOS requiert Linux 64-bit et n'a pas besoin de dépendances supplémentaires. +Une licence développeur libre est disponible. + +{{< caution >}} +Vous devez exécuter le conteneur StorageOS sur chaque nœud qui souhaite accéder aux volumes StorageOS ou qui veut contribuer à la +capacité de stockage du pool. +Pour les instructions d'installation, consulter la [documentation StorageOS](https://docs.storageos.com). +{{< /caution >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # Le volume `redis-vol01` doit déjà exister dans StorageOS, dans le namespace `default`. + volumeName: redis-vol01 + fsType: ext4 +``` + +Pour plus d'informations incluant le provisionnement dynamique (Dynamic Provisioning) et les réclamations de volume persistant (Persistent Volume Claims), consulter les [exemples StorageOS](https://github.com/kubernetes/examples/blob/master/volumes/storageos). + +### vsphereVolume {#vspherevolume} + +{{< note >}} +Prérequis : Kubernetes avec vSphere Cloud Provider configuré. Pour la configuration cloudprovider, +se référer au [guide de mise en marche vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/). +{{< /note >}} + +Un volume `vsphereVolume` est utilisé pour monter un volume vSphere VMDK dans un Pod. Le contenu d'un volume est préservé lorsqu'il est démonté. Il supporte les banques de données (datastore) VMFS and VSAN. + +{{< caution >}} +Vous devez créer VMDK en utilisant une des méthodes suivantes avant de l'utiliser avec un Pod. +{{< /caution >}} + +#### Création d'un volume VMDK + +Choisir une des méthodes suivantes pour créer un VMDK. + +{{< tabs name="tabs_volumes" >}} +{{% tab name="Création en utilisant vmkfstools" %}} +Premièrement, se connecter en ssh dans l'ESX, ensuite, utiliser la commande suivante pour créer un VMDK : + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` +{{% /tab %}} +{{% tab name="Création en utilisant vmware-vdiskmanager" %}} +Utiliser la commande suivante pour créer un VMDK: + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` +{{% /tab %}} + +{{< /tabs >}} + + +#### Exemple de configuration vSphere VMDK + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-vmdk +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-vmdk + name: test-volume + volumes: + - name: test-volume + # Ce volume VMDK doit déjà exister. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + +Plus d'exemples sont disponibles [ici](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere). + + +## Utilisation de subPath + +Parfois, il est utile de partager un volume pour plusieurs utilisations dans un même Pod. +La propriété `volumeMounts.subPath` peut être utilisée pour spécifier un sous-chemin à l'intérieur du volume référencé au lieu de sa racine. + +Voici un exemple d'un Pod avec une stack LAMP (Linux Apache Mysql PHP) utilisant un unique volume partagé. +Le contenu HTML est mappé à son dossier `html` et les bases de données seront stockées dans son dossier `mysql` : + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + +### Utilisation d'un subPath avec des variables d'environnement étendues + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + + +Utiliser le champ `subPathExpr` pour construire des noms de dossier `subPath` depuis les variables d'environnement de l'API Downward. +Avant d'utiliser cette fonctionnalité, vous devez activer la "feature gate" `VolumeSubpathEnvExpansion`. +Les propriétés `subPath` et `subPathExpr` sont mutuellement exclusives. + +Dans cet exemple, un Pod utilise `subPathExpr` pour créer un dossier `pod1` à l'intérieur du volume hostPath `/var/log/pods`, en utilisant le nom du pod depuis l'API Downward. +Le dossier hôte `/var/log/pods/pod1` est monté sur `/logs` dans le conteneur. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox + command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] + volumeMounts: + - name: workdir1 + mountPath: /logs + subPathExpr: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + +## Ressources + +Le support de stockage (Disk, SSD, etc.) d'un volume `emptyDir` est déterminé par le support du système de fichiers +contenant le dossier racine de kubelet (typiquement `/var/lib/kubelet`). +Il n'y a pas de limite sur l'espace qu'un volume `emptyDir` ou `hostPath` peut consommer +et pas d'isolation entre les conteneurs ou entre les Pods. + +Dans le futur, il est prévu que les volumes `emptyDir` et `hostPath` soient en mesure de demander une certaine quantité d'espace en utilisant une spécification de [ressource](/docs/user-guide/compute-resources) et de sélectionner un type de support à utiliser, pour les clusters qui ont plusieurs types de support. + +## Plugins de volume Out-of-Tree +Les plugins de volume Out-of-tree incluent l'interface CSI (Container Storage Interface) et Flexvolume. +Ils permettent aux fournisseurs de stockage de créer des plugins de stockage personnalisés sans les ajouter au dépôt Kubernetes. + +Avant l'introduction de l'interface CSI et Flexvolume, tous les plugins de volume (tels que les types de volume listés plus haut) étaient "in-tree", ce qui signifie qu'ils étaient construits, liés, compilés et livrés avec les binaires de base Kubernetes et étendent l'API Kubernetes de base. +Cela signifiait que l'ajout d'un nouveau système de stockage à Kubernetes (un plugin de volume) requérait de vérifier le code dans le dépôt de base de Kubernetes. + +CSI et Flexvolume permettent à des plugins de volume d'être développés indépendamment de la base de code Kubernetes et déployés (installés) sur des clusters Kubernetes en tant qu'extensions. + +Pour les fournisseurs de stockage qui cherchent à créer un plugin de volume "out-of-tree", se référer à [cette FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### CSI + +L'interface [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) définit une interface standard pour les systèmes d'orchestration de conteneurs (comme Kubernetes) pour exposer des systèmes de stockage arbitraires aux charges de travail de leurs conteneurs. + +Pour plus d'informations, lire la [proposition de conception CSI](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md). + +Le support CSI a été introduit en alpha à partir de Kubernetes v1.9, a évolué en beta dans Kubernetes v1.10 et est en disponibilité générale (GA) depuis Kubernetes v1.13. + +{{< note >}} +Le support des versions spec CSI 0.2 et 0.3 sont obsolètes dans Kubernetes v1.13 et seront retirés dans une version future. +{{< /note >}} + +{{< note >}} +Les pilotes CSI peuvent ne pas être compatibles avec toutes les versions de Kubernetes. +Vérifier la documentation des pilotes CSI spécifiques pour les étapes de déploiement supportées pour chaque version de Kubernetes et la matrice de compatibilité. +{{< /note >}} + +Une fois qu'un pilote de volume CSI compatible est déployé dans un cluster Kubernetes, les utilisateurs peuvent +utiliser le type de volume `csi` pour attacher, monter, etc.., les volumes exposés par le pilote CSI. + +Le type de volume `csi` ne supporte pas de référence directe depuis un Pod et ne peut être référencé seulement dans un Pod que par un objet `PersistentVolumeClaim`. + +Les champs suivants sont disponibles aux administrateurs de stockage pour configurer un volume persistant CSI : + +- `driver`: Une valeur texte qui spécifie le nom du pilote de volume à utiliser. + Cette valeur doit correspondre à la valeur retournée dans le `GetPluginInfoResponse` par le pilote CSI tel que défini dans la + [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). + Elle est utilisée par Kubernetes pour identifier le pilote CSI à appeler et par les composants du pilote CSI + pour identifier quels objets PV appartiennent au pilote CSI. +- `volumeHandle`: Une valeur texte qui identifie le volume de manière unique. Cette valeur doit correspondre à la valeur retournée dans le champ `volume.id` de `CreateVolumeResponse` par le pilote CSI tel que défini dans la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). + La valeur est passée en tant que `volume_id` sur tous les appels au pilote de volume CSI lorsque le volume est référencé. +- `readOnly`: Une valeur booléenne optionnelle indiquant si le volume doit être + "ControllerPublished" (attaché) en lecture seule. La valeur par défaut est "false". Cette valeur est passées au pilote CSI + via le champ `readonly` dans le `ControllerPublishVolumeRequest`. +- `fsType`: Si le `VolumeMode` du PV est `Filesystem`, alors ce champ peut être utilisé pour spécifier le système de fichiers + qui devrait être utilisé pour monter le volume. Si le volume n'a pas été formaté et que le formatage est supporté, cette valeur sera + utilisée pour formater le volume. + Cette valeur est passée au pilote CSI driver via le champ `VolumeCapability` de + `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, et + `NodePublishVolumeRequest`. +- `volumeAttributes`: Un tableau associatif (map) string vers string qui spécifie les propriétés statiques d'un volume. Ce tableau associatif doit correspondre à celui retourné dans le champ + `volume.attributes` du `CreateVolumeResponse` par le pilote CSI tel que défini dans + la [spec CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). + Le tableau associatif est passé au pilote CSI via le champ `volume_attributes` dans la `ControllerPublishVolumeRequest`, `NodeStageV olumeRequest`, et `NodePublishVolumeRequest`. +- `controllerPublishSecretRef`: Une référence de l'objet de type secret contenant des informations sensibles à passer + au driver CSI pour compléter les appels CSI `ControllerPublishVolume` et `ControllerUnpublishVolume`. + Ce champ est optionnel et peut être vide si aucun secret n'est requis. + Si l'objet secret contient plus qu'un secret, tous les secrets sont passés. +- `nodeStageSecretRef`: Une référence à l'objet de type secret contenant des informations sensibles à passer au pilote CSI + pour compléter l'appel CSI `NodeStageVolume`. Ce champ est optionnel et peut être vide si aucun secret n'est requis. + Si l'objet secret contient plus qu'un secret, tous les secrets sont passés. +- `nodePublishSecretRef`: Une référence vers l'objet de type secret contenant des informations sensibles à passer au pilote CSI + pour compléter l'appel CSI `NodePublishVolume`. Ce champ est optionnel et peut être vide si aucun secret n'est requis. + Si l'objet secret contient plus qu'un secret, tous les secrets sont passés. + +#### Support de volume bloc brut CSI + +{{< feature-state for_k8s_version="v1.14" state="beta" >}} + +À partir de la version 1.11, CSI a introduit le support des volumes bloc bruts, qui s'appuient +sur la fonctionnalité de volume bloc brut introduite dans une version précédente de Kubernetes. +Cette fonctionnalité va permettre aux fournisseurs avec des pilotes CSI externes d'implémenter le support pour les volumes bloc bruts +dans les charges de travail Kubernetes. + +Le support volume bloc CSI est une "feature-gate", mais est activée par défaut. Les deux +"feature gates" qui doivent être activées pour cette fonctionnalité sont `BlockVolume` et `CSIBlockVolume`. + +Apprenez comment [configurer votre PV/PVC avec le support de volume bloc brut](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support). + +#### Volumes CSI éphémères + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +Cette fonctionnalité permet aux volumes CSI d'être embarqués directement dans la spécification du Pod au lieu de celle d'un PersistentVolume. Les Volumes spécifiés de cette manière sont éphémères et ne persistent pas lorsque le Pod redémarre. + +Exemple : + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: my-csi-app +spec: + containers: + - name: my-frontend + image: busybox + volumeMounts: + - mountPath: "/data" + name: my-csi-inline-vol + command: [ "sleep", "1000000" ] + volumes: + - name: my-csi-inline-vol + csi: + driver: inline.storage.kubernetes.io + volumeAttributes: + foo: bar +``` + +Cette fonctionnalité requiert l'activation de la "feature gate" CSIInlineVolume : + +``` +--feature-gates=CSIInlineVolume=true +``` + +Les volumes éphémères CSI sont seulement supportés par un sous-ensemble des pilotes CSI. La liste des pilotes CSI est disponible [ici](https://kubernetes-csi.github.io/docs/drivers.html). + +# Ressources pour développeur +Pour plus d'informations sur la manière de développer un pilote CSI, se référer à la [documentation kubernetes-csi](https://kubernetes-csi.github.io/docs/) + +#### Migration de pilotes CSI depuis des plugins "in-tree" + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +La fonctionnalité de migration CSI, lorsque activée, dirige les opérations sur les plugins "in-tree" existants vers les plugins CSI correspondants (qui sont sensés être installés et configurés). +Cette fonctionnalité implémente la logique de translation nécessaire et les fixations nécessaires pour rerouter les opérations +de manière transparente. En conséquence, les opérateurs n'ont pas à effectuer de changements de configuration aux classes de stockage (Storage Classes) existantes, PV ou PVC (référençant aux plugins "in-tree") lors de la transition vers un pilote CSI qui remplace un plugin "in-tree". + +Dans l'état alpha, les opérations et fonctionnalités qui sont supportées incluent provisionnement/suppression, attachement/détachement, montage/démontage et le redimensionnement des volumes. + +Les plugins "in-tree" qui supportent la migration CSI et qui ont un pilote CSI correspondant implémenté sont listés dans la section "Types de volumes" au-dessus. + +### Flexvolume {#flexVolume} + +Flexvolume est une interface de plugin "out-of-tree" qui existe dans Kubernetes depuis la version 1.2 (avant CSI). +Elle utilise un modèle basé sur exec pour s'interfacer avec les pilotes. Les binaires de pilote Flexvolume doivent être installés dans un chemin de volume de plugin prédéfini sur chaque nœud (et dans certains cas le nœud maître). + +Les Pods interagissent avec les pilotes Flexvolume à travers le plugin "in-tree" `flexvolume` +Plus de détails sont disponibles [ici](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md). + +## Propagation de montage + +La propagation de montage permet à des volumes partagés montés par un conteneur à d'autres conteneurs dans un même Pod, ou même à d'autres Pods dans le même nœud. + +La propagation de montage d'un volume est contrôlée par le champ `mountPropagation` dans Container.volumeMounts. +Ses valeurs sont : + + * `None` - Ce montage de volume ne recevra aucun montage subséquent qui est monté à ce volume ou n'importe lequel de ses sous-dossiers par l'hôte. De la même manière, aucun montage créé par le conteneur ne sera visible sur l'hôte. C'est le mode par défaut. + + Ce mode équivaut à une propagation de montage `private` tel que décrit dans la [documentation du noyau Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + + * `HostToContainer` - Ce montage de volume recevra les montages subséquents qui sont montés sur ce volume ou n'importe lequel de ses sous-dossiers. + + En d'autres termes, si l'hôte monte quoi que ce soit dans le montage de volume, le conteneur va le voir monté à cet endroit. + + De manière similaire, si un Pod avec la propagation de montage `Bidirectional` vers le même volume y monte quoi que ce soit, + le conteneur avec la propagation de montage `HostToContainer` le verra. + + Ce mode est équivalent à la propagation de montage `rslave` tel que décrit dans la + [documentation du noyau Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + + * `Bidirectional` - Ce montage de volume se comporte de la même manière que le montage `HostToContainer`. + De plus, tous les montages de volume créés par le conteneur seront propagés à l'hôte et à tous les conteneurs des autres Pods qui utilisent le même volume. + + Un cas d'utilisation typique pour ce mode est un Pod avec un Flexvolume ou un pilote CSI, ou un Pod qui nécessite de monter quelque chose sur l'hôte en utilisant un volume `hostPath`. + + Ce mode est équivalent à une propagation de montage `rshared` tel que décrit dans la + [documentation du noyau Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +{{< caution >}} +La propagation de montage `Bidirectional` peut être dangereuse. Elle peut endommager le système d'exploitation hôte +et est donc autorisée seulement dans des conteneurs privilégiés. +Il est fortement recommandé d'être familier avec le comportement du noyau Linux. +De plus, tous les montages de volume créés par des conteneurs dans des Pods doivent être détruits (démontés) par les conteneurs lors de la terminaison. +{{< /caution >}} + +### Configuration +Avant que la propagation de montage puisse fonctionner correctement sur certains déploiements (CoreOS, +RedHat/Centos, Ubuntu) le partage de montage doit être correctement configuré dans Docker tel qu'illustré ci-dessous : + +Modifiez le fichier de service `systemd` de votre Docker. Configurez votre `MountFlags` comme suit : +```shell +MountFlags=shared +``` +Ou bien retirez `MountFlags=slave` si présent. Redémarrez ensuite le démon Docker : +```shell +sudo systemctl daemon-reload +sudo systemctl restart docker +``` + + + +{{% capture whatsnext %}} +* Suivez un exemple de [déploiement de WordPress et MySQL avec des volumes persistants](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). +{{% /capture %}} diff --git a/content/fr/docs/concepts/workloads/pods/init-containers.md b/content/fr/docs/concepts/workloads/pods/init-containers.md new file mode 100644 index 0000000000..e33b9abcce --- /dev/null +++ b/content/fr/docs/concepts/workloads/pods/init-containers.md @@ -0,0 +1,329 @@ +--- +title: Init Containers +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +Cette page fournit une vue d'ensemble des _conteneurs d'initialisation_ (init containers) : des conteneurs spécialisés qui s'exécutent avant les conteneurs d'application dans un {{< glossary_tooltip text="Pod" term_id="pod" >}}. +Les init containers peuvent contenir des utilitaires ou des scripts d'installation qui ne sont pas présents dans une image d'application. + +Vous pouvez spécifier des init containers dans la spécification du Pod à côté du tableau `containers` (qui décrit les conteneurs d'application) +{{% /capture %}} + +{{% capture body %}} + +## Comprendre les init containers + +Un {{< glossary_tooltip text="Pod" term_id="pod" >}} peut avoir plusieurs conteneurs exécutant des applications mais peut aussi avoir un ou plusieurs init containers, qui sont exécutés avant que les conteneurs d'application ne démarrent. + +Les init containers se comportent comme les conteneurs réguliers, avec quelques différences : + +* Les init containers s'exécutent toujours jusqu'à la complétion. +* Chaque init container doit se terminer avec succès avant que le prochain ne démarre. + +Si le init container d'un Pod échoue, Kubernetes redémarre le Pod à répétition jusqu'à ce que le init container se termine avec succès. +Cependant, si le Pod a une `restartPolicy` à "Never", Kubernetes ne redémarre pas le Pod. + +Afin de spécifier un init container pour un Pod, il faut ajouter le champ `initContainers` dans la spécification du Pod, comme un +tableau d'objets de type [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core), au même niveau que le tableau d'applications `containers`. +Le statut des init containers est retourné dans le champ `.status.initContainerStatuses` +comme un tableau des statuts du conteneur (comparable au champ `.status.containerStatuses`). + +### Différences avec les conteneurs réguliers + +Les init containers supportent tous les champs et fonctionnalités des conteneurs d'application +incluant les limites de ressources, les volumes et les paramètres de sécurité. +Cependant, les demandes de ressources pour un init container sont gérées différemment des +limites de ressources, tel que documenté dans [Ressources](#ressources). + +De plus, les init containers ne supportent pas les readiness probes parce que ces conteneurs +s'exécutent jusqu'au bout avant que le Pod soit prêt. + +Si l'on spécifie plusieurs init containers pour un Pod, Kubelet exécute chaque +init container de manière séquentielle. +Chaque init container doit se terminer avec succès avant que le prochain ne puisse s'exécuter. +Lorsque tous les init containers se sont exécutés jusqu'au bout, Kubelet initialise +les conteneurs d'application pour le Pod et les exécute comme d'habitude. + +## Utiliser les init containers + +Puisque les init containers ont des images séparées des conteneurs d'application, +ils apportent certains avantages pour du code de mise en route : + +* Les init containers peuvent contenir des utilitaires ou du code de configuration personnalisé +qui ne sont pas présents dans une image d'application. +Par exemple, il n'y a pas besoin de faire hériter une image d'une autre (`FROM`) seulement pour utiliser +un outil comme `sed`, `awk`, `python`, ou `dig` pendant l'installation. +* Les init containers peuvent exécuter en toute sécurité des utilitaires qui rendraient moins sécurisée une image de conteneur d'application. +* Les rôles "builder" et "deployer" d'une image d'application peuvent travailler indépendamment sans qu'il n'y ait besoin +de créer conjointement une seule image d'application. +* Les init containers peuvent s'exécuter avec une vue du système de fichiers différente de celle des conteneurs d'application dans le même Pod. Par conséquent, on peut leur donner accès aux {{< glossary_tooltip text="Secrets" term_id="secret" >}}, auxquels les conteneurs d'application n'ont pas accès. +* Puisque les init containers s'exécutent jusqu'à la complétion avant qu'un conteneur d'application ne démarre, les init containers +offrent un mécanisme pour bloquer ou retarder le démarrage d'un conteneur d'application tant qu'un ensemble de préconditions n'est pas respecté. Une fois que les préconditions sont respectées, tous les conteneurs d'application dans un Pod peuvent démarrer en parallèle. + +### Exemples + +Voici plusieurs idées pour utiliser les init containers : + +* Attendre qu'un {{< glossary_tooltip text="Service" term_id="service">}} soit créé, + en utilisant une commande shell d'une ligne telle que : + ```shell + for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 + ``` + +* Enregistrer ce Pod à un serveur distant depuis l'API downward avec une commande telle que : + ```shell + curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()' + ``` + +* Attendre un certain temps avant de démarrer le conteneur d'application avec une commande telle que : + ```shell + sleep 60 + ``` + +* Cloner un dépôt Git dans un {{< glossary_tooltip text="Volume" term_id="volume" >}} + +* Placer des valeurs dans un fichier de configuration et exécuter un outil de templating pour générer +dynamiquement un fichier de configuration pour le conteneur d'application principal. +Par exemple, placer la valeur `POD_IP` dans une configuration et générer le fichier de configuration de l'application principale +en utilisant Jinja. + +#### Les init containers en utilisation + +Cet exemple définit un simple Pod possédant deux init containers. +Le premier attend `myservice` et le second attend `mydb`. Une fois que les deux +init containers terminent leur exécution, le Pod exécute le conteneur d'application décrit dans sa section `spec`. + + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app: myapp +spec: + containers: + - name: myapp-container + image: busybox:1.28 + command: ['sh', '-c', 'echo "L''app s''exécute!" && sleep 3600'] + initContainers: + - name: init-myservice + image: busybox:1.28 + command: ['sh', '-c', 'until nslookup myservice; do echo "En attente de myservice"; sleep 2; done;'] + - name: init-mydb + image: busybox:1.28 + command: ['sh', '-c', 'until nslookup mydb; do echo "En attente de mydb"; sleep 2; done;'] +``` + +Les fichiers YAML suivants résument les services `mydb` et `myservice` : + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: myservice +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +--- +apiVersion: v1 +kind: Service +metadata: + name: mydb +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9377 +``` + +Vous pouvez démarrer ce Pod en exécutant : + +```shell +kubectl apply -f myapp.yaml +``` +``` +pod/myapp-pod created +``` + +Et vérifier son statut avec : +```shell +kubectl get -f myapp.yaml +``` +``` +NAME READY STATUS RESTARTS AGE +myapp-pod 0/1 Init:0/2 0 6m +``` + +ou pour plus de détails : +```shell +kubectl describe -f myapp.yaml +``` +``` +Name: myapp-pod +Namespace: default +[...] +Labels: app=myapp +Status: Pending +[...] +Init Containers: + init-myservice: +[...] + State: Running +[...] + init-mydb: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Containers: + myapp-container: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 + 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 +``` + +Pour voir les logs des init containers dans ce Pod, exécuter : +```shell +kubectl logs myapp-pod -c init-myservice # Inspecter le premier init container +kubectl logs myapp-pod -c init-mydb # Inspecter le second init container +``` + +À ce stade, ces init containers attendent de découvrir les services nommés +`mydb` et `myservice`. + +Voici une configuration que vous pouvez utiliser pour faire apparaître ces Services : + +```yaml +--- +apiVersion: v1 +kind: Service +metadata: + name: myservice +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +--- +apiVersion: v1 +kind: Service +metadata: + name: mydb +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9377 +``` + +Pour créer les services `mydb` et `myservice` : + +```shell +kubectl apply -f services.yaml +``` +``` +service/myservice created +service/mydb created +``` + +Vous verrez ensuite que ces init containers se terminent et que le Pod `myapp-pod` évolue vers l'état "Running" (en exécution) : + +```shell +kubectl get -f myapp.yaml +``` +``` +NAME READY STATUS RESTARTS AGE +myapp-pod 1/1 Running 0 9m +``` + +Cet exemple simple devrait suffire à vous inspirer pour créer vos propres init containers. +[A suivre](#a-suivre) contient un lien vers un exemple plus détaillé. + +## Comportement détaillé + +Pendant le démarrage d'un Pod, chaque init container démarre en ordre, après que le réseau +et les volumes ont été initialisés. Chaque conteneur doit se terminer avec succès avant que le prochain +ne démarre. Si un conteneur n'arrive pas à démarrer à cause d'un problème d'exécution ou +se termine avec un échec, il est redémarré selon la `restartPolicy` du Pod. +Toutefois, si la `restartPolicy` du Pod est configurée à "Always", les init containers utilisent la `restartPolicy` "OnFailure". + +Un Pod ne peut pas être `Ready` tant que tous les init containers ne se sont pas exécutés avec succès. +Les ports d'un init container ne sont pas agrégés sous un Service. Un Pod qui s'initialise +est dans l'état `Pending` mais devrait avoir une condition `Initializing` configurée à "true". + +Si le Pod [redémarre](#raisons-du-redémarrage-d-un-pod) ou est redémarré, tous les init containers +doivent s'exécuter à nouveau. + +Les changements aux spec d'un init containers sont limités au champ image du conteneur. +Changer le champ image d'un init container équivaut à redémarrer le Pod. + +Puisque les init containers peuvent être redémarrés, réessayés ou ré-exécutés, +leur code doit être idempotent. En particulier, le code qui écrit dans des fichiers sur `EmptyDirs` +devrait être préparé à la possibilité qu'un fichier de sortie existe déjà. + +Les init containers ont tous les champs d'un conteneur d'application. +Cependant, Kubernetes interdit l'utilisation de `readinessProbe` parce que les init containers +ne peuvent pas définir une "readiness" distincte de la complétion. Ceci est appliqué lors de la validation. + +L'utilisation de `activeDeadlineSeconds` sur le Pod et `livenessProbe` sur le conteneur +permet d'empêcher les init containers d'échouer tout le temps. +La deadline active inclut les init containers. + +Le nom de chaque application et init container dans un Pod doit être unique; une erreur de validation +est générée pour tout conteneur partageant un nom avec un autre. + +### Ressources + +Étant donné l'ordonnancement et l'exécution des init containers, les règles suivantes s'appliquent pour l'utilisation des ressources : + +* La plus haute requête ou limite particulière de ressource définie pour tous les init containers +est la *limite/requête d'initialisation effective* +* La *limite/requête effective* d'un Pod pour une ressource est la plus haute parmis : + * la somme de toutes les requêtes/limites des conteneurs d'application pour une ressource + * la limite/requête d'initialisation effective pour une ressource +* Le Scheduling est effectué sur la base des requêtes/limites effectives, ce qui signifie +que les init containers peuvent réserver des ressources pour l'initialisation qui ne sont pas utilisées durant le +cycle de vie du Pod. +* La QoS (qualité de service) tierce de la *QoS tierce effective* d'un Pod est la QoS tierce aussi bien pour les init containers +que pour les conteneurs d'application. + +Les quotas et limites sont appliqués sur la base de la requête/limite effective d'un Pod. + +Les groupes de contrôle au niveau du Pod ({{< glossary_tooltip text="cgroups" term_id="cgroup" >}}) sont basés sur la requête/limite effective de Pod, la même que +celle du scheduler. + +### Raisons du redémarrage d'un Pod + +Un Pod peut redémarrer, ce qui cause la ré-exécution des init containers, pour les raisons suivantes : + +* Un utilisateur met à jour les spécifications du Pod, ce qui cause le changement de l'image de l'init container. +Tout changement à l'image du init container redémarre le Pod. Les changements au conteneur d'application entraînent seulement le +redémarrage du conteneur d'application. +* Le conteneur d'infrastructure Pod est redémarré. Ceci est peu commun et serait effectué par une personne ayant un accès root aux nœuds. +* Tous les conteneurs dans un Pod sont terminés tandis que `restartPolicy` est configurée à "Always", ce qui force le redémarrage, et l'enregistrement de complétion du init container a été perdu à cause d'une opération de garbage collection (récupération de mémoire). + +{{% /capture %}} + + +{{% capture whatsnext %}} + +* Lire à propos de la [création d'un Pod ayant un init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) +* Apprendre à [debugger les init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) + +{{% /capture %}} diff --git a/content/fr/docs/reference/glossary/admission-controller.md b/content/fr/docs/reference/glossary/admission-controller.md new file mode 100644 index 0000000000..9d1f400483 --- /dev/null +++ b/content/fr/docs/reference/glossary/admission-controller.md @@ -0,0 +1,22 @@ +--- +title: Admission Controller +id: admission-controller +date: 2019-06-28 +full_link: fr/docs/reference/access-authn-authz/admission-controllers/ +short_description: > + Un morceau de code qui intercepte les requêtes adressées au serveur API de Kubernetes avant la persistance de l'objet. + +aka: +tags: +- extension +- security +--- +Un morceau de code qui intercepte les requêtes adressées au serveur API de Kubernetes avant la persistance de l'objet. + + + +Les contrôleurs d'accès sont configurables pour le serveur API de Kubernetes. Un contrôleur d'accès peut être "validant" ("validating"), "modifiant" ("mutating"), ou +les deux. Tout contrôleur d'accès peut rejeter la demande. Les contrôleurs modifiant peuvent modifier les objets qu'ils admettent ; +alors que les contrôleurs validants ne le peuvent pas. + +* ["Contrôleur d'accès" dans la documentation de Kubernetes](fr/docs/reference/access-authn-authz/admission-controllers/) diff --git a/content/fr/docs/reference/glossary/applications.md b/content/fr/docs/reference/glossary/applications.md new file mode 100644 index 0000000000..6f2124e855 --- /dev/null +++ b/content/fr/docs/reference/glossary/applications.md @@ -0,0 +1,13 @@ +--- +title: Applications +id: appplications +date: 2019-05-12 +full_link: +short_description: > + La couche où s'exécutent diverses applications conteneurisées. + +aka: +tags: +- fundamental +--- + La couche où s'exécutent diverses applications conteneurisées. diff --git a/content/fr/docs/reference/glossary/approver.md b/content/fr/docs/reference/glossary/approver.md new file mode 100755 index 0000000000..b9dc84c1ce --- /dev/null +++ b/content/fr/docs/reference/glossary/approver.md @@ -0,0 +1,17 @@ +--- +title: Approbateur +id: approver +date: 2018-04-12 +full_link: +short_description: > + Personne pouvant passer en revue et approuver les contributions au code Kubernetes. + +aka: +tags: +- community +--- + Personne pouvant passer en revue et approuver les contributions au code Kubernetes. + + + +Alors que l'examen du code est axé sur la qualité et l'exactitude de ce dernier, l'approbation est, quant à elle, axée sur l'acceptation globale d'une contribution. L'acceptation globale inclut entre autres, la (rétro-)comptabilité, le respect des conventions concernant l'API et les drapeaux, les problèmes subtils de performance et d'exactitude, ainsi que les interactions avec d'autres parties du système. Le statut d'approbateur est limité à une partie de la base de code. Auparavant, les approbateurs étaient appelés mainteneurs. diff --git a/content/fr/docs/reference/glossary/cgroup.md b/content/fr/docs/reference/glossary/cgroup.md new file mode 100644 index 0000000000..1a93047fe1 --- /dev/null +++ b/content/fr/docs/reference/glossary/cgroup.md @@ -0,0 +1,16 @@ +--- +title: cgroup (control group) +id: cgroup +date: 2019-06-25 +full_link: +short_description: > + Un groupe de processus Linux avec des options d'isolation, de suivi, et de limites des ressources. + +aka: +tags: +- fundamental +--- +Un groupe de processus Linux avec des options d'isolation, de suivi, et de limite de l'utilisation des ressources. + + +cgroup est une fonctionnalité du noyau Linux qui limite, suit et isole l'utilisation des ressources (CPU, mémoire, E/S disque, réseau) pour un ensemble de processus. diff --git a/content/fr/docs/reference/glossary/cncf.md b/content/fr/docs/reference/glossary/cncf.md new file mode 100644 index 0000000000..9f2315972e --- /dev/null +++ b/content/fr/docs/reference/glossary/cncf.md @@ -0,0 +1,22 @@ +--- +title: Cloud Native Computing Foundation (CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + Cloud Native Computing Foundation + +aka: +tags: +- community +--- +La Cloud Native Computing Foundation (CNCF) construit des écosystèmes durables et +favorise la création d'une communauté autour des [projets](https://www.cncf.io/projects/) qui +orchestrent les conteneurs dans le cadre d'une architecture de microservices. + +Kubernetes est un projet de la CNCF. + + + +La CNCF est une sous-fondation de [Linux Foundation](https://www.linuxfoundation.org/). +Sa mission est de rendre le "cloud native computing" omniprésent. diff --git a/content/fr/docs/reference/glossary/code-contributor.md b/content/fr/docs/reference/glossary/code-contributor.md new file mode 100755 index 0000000000..b287422ad8 --- /dev/null +++ b/content/fr/docs/reference/glossary/code-contributor.md @@ -0,0 +1,18 @@ +--- +title: Contributeur de Code +id: code-contributor +date: 2018-04-12 +full_link: /docs/community/devel/ +short_description: > + Personne qui développe et contribue au code open source de Kubernetes. + +aka: +tags: +- community +- user-type +--- + Personne qui développe et contribue au code open source de Kubernetes. + + + +Cette personne est aussi un {{< glossary_tooltip text="membre actif de la communauté" term_id="member" >}} participant à un ou plusieurs {{< glossary_tooltip text="Groupes d'Intérêts Spéciaux (SIGs, de l'anglais Special Interest Groups)" term_id="sig" >}}. diff --git a/content/fr/docs/reference/glossary/configmap.md b/content/fr/docs/reference/glossary/configmap.md new file mode 100755 index 0000000000..04ca564a8b --- /dev/null +++ b/content/fr/docs/reference/glossary/configmap.md @@ -0,0 +1,17 @@ +--- +title: ConfigMap +id: configmap +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-pod-configmap/ +short_description: > + Un objet API utilisé pour stocker des données non confidentielles dans des paires clé-valeur. Peut être utilisé comme variable d'environnement, argument de ligne de commande ou fichier de configuration dans un volume. + +aka: +tags: +- core-object +--- + Un objet API utilisé pour stocker des données non confidentielles dans des paires clé-valeur. Peut être utilisé comme variable d'environnement, argument de ligne de commande ou fichier de configuration dans un {{< glossary_tooltip text="volume" term_id="volume" >}}. + + + +Permet de dissocier la configuration spécifique à l'environnement de vos {{< glossary_tooltip text="images de conteneurs" term_id="container" >}}, de sorte que vos applications soient facilement portable. Lorsque vous stockez des données confidentielles, utilisez un [Secret](/docs/concepts/configuration/secret/). diff --git a/content/fr/docs/reference/glossary/container-env-variables.md b/content/fr/docs/reference/glossary/container-env-variables.md new file mode 100755 index 0000000000..750e8ed3cb --- /dev/null +++ b/content/fr/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: Variables d'Environnement de Conteneur +id: container-env-variables +date: 2018-04-12 +full_link: /docs/concepts/containers/container-environment-variables/ +short_description: > + Les variables d'environnement de conteneur sont des paires nom=valeur qui fournissent des informations utiles aux conteneurs fonctionnant au sein d'un Pod. + +aka: +tags: +- fundamental +--- + Les variables d'environnement de conteneur sont des paires nom=valeur qui fournissent des informations utiles aux conteneurs fonctionnant au sein d'un Pod. + + + +Les variables d'environnement de conteneur fournissent les informations requises par les applications conteneurisées en cours d'exécution, ainsi que des informations sur les ressources importantes aux {{< glossary_tooltip text="Conteneurs" term_id="container" >}} comme les détails du système de fichiers, les informations sur le conteneur lui-même et d'autres ressources du cluster telles que les terminaux de services par exemple. diff --git a/content/fr/docs/reference/glossary/control-plane.md b/content/fr/docs/reference/glossary/control-plane.md new file mode 100644 index 0000000000..bd9660f412 --- /dev/null +++ b/content/fr/docs/reference/glossary/control-plane.md @@ -0,0 +1,13 @@ +--- +title: Plan de Contrôle +id: control-plane +date: 2019-05-12 +full_link: +short_description: > + Couche d'orchestration des conteneurs exposant l'API et les interfaces pour définir, déployer et gérer le cycle de vie des conteneurs. + +aka: +tags: +- fundamental +--- + Couche d'orchestration des conteneurs exposant l'API et les interfaces pour définir, déployer et gérer le cycle de vie des conteneurs. diff --git a/content/fr/docs/reference/glossary/controller.md b/content/fr/docs/reference/glossary/controller.md new file mode 100755 index 0000000000..19eaeb236f --- /dev/null +++ b/content/fr/docs/reference/glossary/controller.md @@ -0,0 +1,18 @@ +--- +title: Contrôleur +id: controller +date: 2018-04-12 +full_link: /docs/admin/kube-controller-manager/ +short_description: > + Boucle de contrôle surveillant l'état partagé du cluster à travers l'apiserver et effectuant des changements en essayant de déplacer l'état actuel vers l'état désiré. + +aka: +tags: +- architecture +- fundamental +--- + Boucle de contrôle surveillant l'état partagé du cluster à travers l'{{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} et effectuant des changements en essayant de déplacer l'état actuel vers l'état désiré. + + + +Parmis les contrôleurs livrés aujourd'hui avec Kubernetes se trouvent le contrôleur de réplication, le contrôleur d'endpoints, de namespace et de serviceaccounts. diff --git a/content/fr/docs/reference/glossary/cri-o.md b/content/fr/docs/reference/glossary/cri-o.md new file mode 100644 index 0000000000..2c39293a8a --- /dev/null +++ b/content/fr/docs/reference/glossary/cri-o.md @@ -0,0 +1,22 @@ +--- +title: CRI-O +id: cri-o +date: 2019-05-14 +full_link: https://cri-o.io/docs/ +short_description: > + Un runtime (environnement d'exécution) de conteneur, léger et spécifiquement conçu pour Kubernetes. + +aka: +tags: +- tool +--- +Un outil permettant d'utiliser les runtimes de conteneurs OCI avec Kubernetes CRI. + + + +CRI-O est une implémentation du {{< glossary_tooltip term_id="cri" >}} +permettant l'utilisation des runtimes de {{< glossary_tooltip text="conteneurs" term_id="container" >}} +compatibles avec l'Open Container Initiative (OCI) +[runtime spec](http://www.github.com/opencontainers/runtime-spec). + +Le déploiement de CRI-O permet à Kubernetes d'utiliser n'importe quel runtime conforme à l'OCI, en tant que runtime de conteneur, afin d'exécuter les {{< glossary_tooltip text="Pods" term_id="pod" >}}, et de récupérer les images de conteneurs OCI provenant de registres distants. diff --git a/content/fr/docs/reference/glossary/csi.md b/content/fr/docs/reference/glossary/csi.md new file mode 100644 index 0000000000..58a1eb0956 --- /dev/null +++ b/content/fr/docs/reference/glossary/csi.md @@ -0,0 +1,21 @@ +--- +title: Interface de Stockage de Conteneurs (CSI) +id: csi +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#csi +short_description: > + L'Interface de Stockage de Conteneurs (CSI, de l'anglais Container Storage Interface) définit une interface normalisée pour exposer les systèmes de stockage aux conteneurs. + + +aka: +tags: +- storage +--- + L'Interface de Stockage de Conteneurs, (CSI, de l'anglais Container Storage Interface) définit une interface normalisée pour exposer les systèmes de stockage aux conteneurs. + + + +L'Interface de Stockage de Conteneurs permet aux fournisseurs de créer des plugins de stockage personnalisés pour Kubernetes, sans les ajouter au référentiel Kubernetes (plugin hors arbre). Afin d'utiliser un pilote d'Interface de Stockage de Conteneurs d'un fournisseur de mémoire, vous devez d'abord [le déployer sur votre cluster](https://kubernetes-csi.github.io/docs/deploying.html). Vous pourrez alors créer une {{< glossary_tooltip text="Classe de Stockage" term_id="storage-class" >}} qui utilise le pilote de cette Interface de Stockage de Conteneurs. + +* [L'Interface de Stockage de Conteneurs dans la documentation de Kubernetes](/docs/concepts/storage/volumes/#csi) +* [Liste des pilotes d'Interface de Stockage de Conteneurs](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/fr/docs/reference/glossary/etcd.md b/content/fr/docs/reference/glossary/etcd.md new file mode 100755 index 0000000000..4a86d40bd9 --- /dev/null +++ b/content/fr/docs/reference/glossary/etcd.md @@ -0,0 +1,22 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster. + +aka: +tags: +- architecture +- storage +--- + Base de données clé-valeur consistante et hautement disponible utilisée comme mémoire de sauvegarde pour toutes les données du cluster. + + + +Si votre cluster Kubernetes utilise etcd comme mémoire de sauvegarde, assurez-vous d'avoir un plan de +[back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) pour ces données. + +Vous pouvez trouver plus d'informations à propos d'etcd dans la [documentation](https://etcd.io/docs/) officielle. + diff --git a/content/fr/docs/reference/glossary/kube-apiserver.md b/content/fr/docs/reference/glossary/kube-apiserver.md new file mode 100755 index 0000000000..491b1b65ce --- /dev/null +++ b/content/fr/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,19 @@ +--- +title: kube-apiserver +id: kube-apiserver +date: 2018-04-12 +full_link: /docs/reference/generated/kube-apiserver/ +short_description: > + Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes. + +aka: +tags: +- architecture +- fundamental +--- + Composant sur le master qui expose l'API Kubernetes. Il s'agit du front-end pour le plan de contrôle Kubernetes. + + + +Il est conçu pour une mise à l'échelle horizontale, ce qui veut dire qu'il met à l'échelle en déployant des instances supplémentaires. Voir [Construire des Clusters en Haute Disponibilité](/docs/admin/high-availability/). + diff --git a/content/fr/docs/reference/glossary/kube-controller-manager.md b/content/fr/docs/reference/glossary/kube-controller-manager.md new file mode 100755 index 0000000000..5342b8b116 --- /dev/null +++ b/content/fr/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,19 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/generated/kube-controller-manager/ +short_description: > + Composant du master qui exécute les contrôleurs. + +aka: +tags: +- architecture +- fundamental +--- + Composant du master qui exécute les {{< glossary_tooltip text="contrôleurs" term_id="controller" >}}. + + + +Logiquement, chaque {{< glossary_tooltip text="contrôleur" term_id="controller" >}} est un processus à part mais, +pour réduire la compléxité, les contrôleurs sont tous compilés dans un seul binaire et s'exécutent dans un seul processus. diff --git a/content/fr/docs/reference/glossary/kube-proxy.md b/content/fr/docs/reference/glossary/kube-proxy.md new file mode 100755 index 0000000000..db9097cd1b --- /dev/null +++ b/content/fr/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,24 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ +short_description: > + `kube-proxy` est un proxy réseau qui s'exécute sur chaque nœud du cluster. + +aka: +tags: +- fundamental +- networking +--- + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) est un +proxy réseau qui s'exécute sur chaque nœud du cluster et implémente une partie du +concept Kubernetes de {{< glossary_tooltip term_id="service">}}. + + + +kube-proxy maintient les règles réseau sur les nœuds. Ces règles réseau permettent +une communication réseau vers les Pods depuis des sessions réseau à l'intérieur ou à l'extérieur +du cluster. + +kube-proxy utilise la couche de filtrage de paquets du système d'exploitation s'il y en a une et qu'elle est disponible. Sinon, kube-proxy transmet le trafic lui-même. diff --git a/content/fr/docs/reference/glossary/kube-scheduler.md b/content/fr/docs/reference/glossary/kube-scheduler.md new file mode 100755 index 0000000000..8c72711795 --- /dev/null +++ b/content/fr/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,18 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +short_description: > + Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter. + +aka: +tags: +- architecture +--- + Composant sur le master qui surveille les pods nouvellement créés qui ne sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont s'exécuter. + + + +Les facteurs pris en compte pour les décisions de planification (scheduling) comprennent les exigences individuelles et collectives en ressources, les contraintes matérielles/logicielles/politiques, les spécifications d'affinité et d'anti-affinité, la localité des données, les interférences entre charges de travail et les dates limites. + diff --git a/content/fr/docs/reference/glossary/pod.md b/content/fr/docs/reference/glossary/pod.md new file mode 100644 index 0000000000..2d400c75a6 --- /dev/null +++ b/content/fr/docs/reference/glossary/pod.md @@ -0,0 +1,18 @@ +--- +title: Pod +id: pod +date: 2018-04-12 +full_link: fr/docs/concepts/workloads/pods/pod-overview/ +short_description: > + Le plus petit et le plus simple des objets Kubernetes. Un Pod est un ensemble de conteneurs fonctionnant sur votre cluster. + +aka: +tags: +- core-object +- fundamental +--- + Le plus petit et le plus simple des objets Kubernetes. Un Pod est un ensemble de {{< glossary_tooltip text="conteneurs" term_id="container" >}} fonctionnant sur votre cluster. + + + +Un Pod est généralement configuré pour faire fonctionner un seul conteneur primaire. Il peut également exécuter des conteneurs side-car optionnels qui ajoutent des fonctions supplémentaires comme le logging. Les Pods sont généralement gérés par un {{< glossary_tooltip="Deployment" term_id="deployment" >}}. diff --git a/content/fr/docs/reference/glossary/toleration.md b/content/fr/docs/reference/glossary/toleration.md new file mode 100644 index 0000000000..82547ecfc9 --- /dev/null +++ b/content/fr/docs/reference/glossary/toleration.md @@ -0,0 +1,18 @@ +--- +title: Toleration +id: toleration +date: 2019-01-11 +full_link: /docs/concepts/configuration/taint-and-toleration/ +short_description: > + Un objet de base composé de trois caractéristiques requises : clé, valeur et effet. Les tolérances permettent d'ordonnancer les pods sur les nœuds ou les groupes de nœuds qui ont un marquage compatible. + +aka: +tags: +- core-object +- fundamental +--- + Un objet de base composé de trois caractéristiques requises : clé, valeur et effet. Les tolérances permettent d'ordonnancer les pods sur les nœuds ou les groupes de nœuds qui ont des {{< glossary_tooltip text="marquages" term_id="taint" >}} compatibles. + + + +Tolérances et {{< glossary_tooltip text="marquages" term_id="taint" >}} fonctionnent ensemble pour s'assurer que les pods ne sont pas ordonnancés sur des nœuds inappropriés. Une ou plusieurs tolérances sont appliquées à un {{< glossary_tooltip text="pod" term_id="pod" >}}. Une tolérance indique que le {{< glossary_tooltip text="pod" term_id="pod" >}} est autorisé à (mais non obligé de) être ordonnancé sur les nœuds ou groupes de nœuds avec un {{< glossary_tooltip text="marquage" term_id="taint" >}} compatible. diff --git a/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md b/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md new file mode 100644 index 0000000000..338b54cdaa --- /dev/null +++ b/content/fr/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md @@ -0,0 +1,84 @@ + +Utilisez cette commande afin de configurer le control plane Kubernetes + +### Synopsis + +Utilisez cette commande afin de configurer le control plane Kubernetes + +La commande "init" exécute les phases suivantes : +``` +preflight Exécute les vérifications en amont +kubelet-start Sauvegarde les réglages kubelet et (re)démarre kubelet +certs Génération de certificats + /etcd-ca Génère le certificat CA auto signé pour fournir les identités à etcd + /apiserver-etcd-client Génère le certificat que l'apiserver utilisera pour communiquer avec etcd + /etcd-healthcheck-client Génère le certificat pour les sondes de vivacité (liveness) qui contrôlent etcd + /etcd-server Génère le certificat pour l'accès à etcd + /etcd-peer Génère le certificat pour que les noeuds etcd puissent communiquer ensemble + /ca Génère le certificat CA auto signé de Kubernetes pour fournir les identités aux autres composants Kubernetes + /apiserver Génère le certificat pour l'accès à l'API Kubernetes + /apiserver-kubelet-client Génère le certificat pour permettre à l'API server de se connecter à kubelet + /front-proxy-ca Génère le certificat CA auto signé pour fournir les identités au proxy frontal (front proxy) + /front-proxy-client Génère le certificat pour le client du proxy frontal + /sa Génère une clef privée pour signer les jetons ainsi que la clef publique du compte service +kubeconfig Génère tous les fichiers kubeconfig nécessaires pour la création du control plane et du fichier kubeconfig admin + /admin Génère un fichier kubeconfig pour utilisation par l'administrateur et kubeadm + /kubelet Génère un fichier kubeconfig pour utilisation par kubelet seulement à des fins d'installation initiale + /controller-manager Génère un fichier fichier kubeconfig for the controller manager to use + /scheduler Génère un fichier kubeconfig pour utilisation par le scheduler +control-plane Génère tous les manifests de Pod statiques nécessaires à la création du control plane + /apiserver Génère le manifest de Pod statique de l'apiserver + /controller-manager Génère le manifest de Pod statique du kube-controller-manager + /scheduler Génère le manifest de Pod statique du kube-schedule +etcd Génère le manifest de Pod statique pour l'etcd local + /local Génère le manifest de Pod statique pour une instance etcd locale, à un seul noeud +upload-config Téléverse les configurations kubeadm et kubelet vers une ConfigMap + /kubeadm Téléverse la ClusterConfiguration de kubeadm vers une ConfigMap + /kubelet Téléverse la configuration kubelet vers une ConfigMap +upload-certs Téléverse les certificats vers kubeadm-certs +mark-control-plane Marque un noeud en tant que control-plane +bootstrap-token Génère les jetons d'installation utilisés pour faire joindre un noeud à un cluster +addon Installe les extensions requises pour l'exécution des tests de Conformance + /coredns Installe l'extension CoreDNS à un cluster Kubernetes + /kube-proxy Installe l'extension kube-proxy à un cluster Kubernetes +``` + + +``` +kubeadm init [flags] +``` + +### Options + +``` + --apiserver-advertise-address string L'adresse IP que l'API Server utilisera pour s'annoncer. Si non spécifiée, l'interface réseau par défaut sera utilisée. + --apiserver-bind-port int32 Port d'écoute de l'API Server. (par default 6443) + --apiserver-cert-extra-sans strings Noms alternatifs (Subject Alternative Names ou encore SANs) optionnels, utilisés dans les certificats servis par l'API Server. Peuvent êtres des adresses IPs ou des noms DNS. + --cert-dir string Le répertoire où sauvegarder les certificats. (par défaut "/etc/kubernetes/pki") + --certificate-key string Clef utilisée pour chiffrer les certificats control-plane dans le Secret the kubeadm-certs. + --config string Chemin vers un fichier de configuration kubeadm. + --cri-socket string Chemin vers la socket CRI à laquelle la connexion doit s'effectuer. S'il n'est pas spécifié, kubeadm essaiera de le détecter; utiliser cette option seulement si vous avez plus d'un CRI installé ou si vous utilisez des sockets CRI non standard. + --dry-run N'effectue aucun changement; affiche seulement la sortie standard de ce qui serait effectué. + --feature-gates string Un ensemble de paires clef=valeur qui décrivent l'entrée de configuration pour des fonctionnalités diverses. Il n'y en a aucune dans cette version. + -h, --help aide pour l'initialisation (init) + --ignore-preflight-errors strings Une liste de contrôles dont les erreurs seront catégorisées comme "warnings" (avertissements). Par exemple : 'IsPrivilegedUser,Swap'. La valeur 'all' ignore les erreurs de tous les contrôles. + --image-repository string Choisis un container registry d'où télécharger les images du control plane. (par défaut "k8s.gcr.io") + --kubernetes-version string Choisis une version Kubernetes spécifique pour le control plane. (par défaut "stable-1") + --node-name string Spécifie le nom du noeud. + --pod-network-cidr string Spécifie l'intervalle des adresses IP pour le réseau des pods. Si fournie, le control plane allouera automatiquement les CIDRs pour chacun des noeuds. + --service-cidr string Utilise un intervalle différent pour les adresses IP des services prioritaires (VIPs). (par défaut "10.96.0.0/12") + --service-dns-domain string Utilise un domaine alternatif pour les services, par exemple : "myorg.internal". (par défaut "cluster.local") + --skip-certificate-key-print N'affiche pas la clef utilisée pour chiffrer les certificats du control-plane. + --skip-phases strings List des des phases à sauter + --skip-token-print N'affiche pas le jeton par défaut de l'installation qui a été généré lors de 'kubeadm init'. + --token string Le jeton à utiliser pour établir la confiance mutuelle entre les noeuds et les noeuds du control-plane. Le format correspond à la regexp : [a-z0-9]{6}\.[a-z0-9]{16} - par exemple : abcdef.0123456789abcdef + --token-ttl duration La durée au bout de laquelle le jeton sera automatiquement détruit (par exemple : 1s, 2m, 3h). Si réglée à '0', le jeton n'expirera jamais (par défaut 24h0m0s) + --upload-certs Téléverse les certificats du control-plane vers le Secret kubeadm-certs. +``` + +### Options héritées depuis la commande parent + +``` + --rootfs string [EXPERIMENTALE] Le chemin vers la "vraie" racine du système de fichiers de l'hôte. +``` + diff --git a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md new file mode 100644 index 0000000000..1564aed617 --- /dev/null +++ b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -0,0 +1,303 @@ +--- +title: kubeadm init +content_template: templates/concept +weight: 20 +--- +{{% capture overview %}} +Cette commande initialise un noeud Kubernetes control-plane. +{{% /capture %}} + +{{% capture body %}} + +{{< include "generated/kubeadm_init.md" >}} + +### Séquence d'initialisation {#init-workflow} +`kubeadm init` assemble un noeud Kubernetes control-plane en effectuant les étapes suivantes : + +1. Exécute une série de contrôles pour valider l'état du système avant d'y apporter des changements. + Certaines validations peuvent émettre seulement des avertissements (warnings), + d'autres peuvent générer des erreurs qui forceront l'interruption de kubeadm + jusqu'à ce que le problème soit résolu + ou jusqu'à ce que l'utilisateur spécifie `--ignore-preflight-errors=`. + +1. Génère une autorité de certification (CA) auto signée (ou utilise une existante si spécifiée) pour + installer les identités de chaque composant du cluster. Si l'utilisateur a fourni son propre certificat + et/ou clef de CA en le (la) copiant dans le répertoire des certificats, configuré avec `--cert-dir` + (`/etc/kubernetes/pki` par défaut) cette étape est sautée comme expliqué dans le document + [utiliser ses propres certificats](#custom-certificates). + Les certificats de l'API Server auront des entrées SAN additionnelles pour chaque argument `--apiserver-cert-extra-sans`. + +1. Ecrit les fichiers kubeconfig dans `/etc/kubernetes/` pour + kubelet, le controller-manager et l'ordonnanceur (scheduler) + qui seront utlisés pour les connexions à l'API server, chacun avec sa propre identité, + ainsi qu'un fichier kubeconfig supplémentaire pour l'administration, nommé `admin.conf`. + +1. Génère des manifestes statiques de Pod pour l'API server, + le controller manager et l'ordonnanceur. Au cas où aucun etcd externe n'est fourni, + un manifeste statique de Pod pour etcd est généré. + + Les manifestes statiques de Pod sont écrits dans `/etc/kubernetes/manifestes`; + kubelet surveille ce répertoire afin que les Pods soient créés au démarrage. + + Dès lors que les pods de control-plane sont démarrés, la séquence de `kubeadm init` peut alors continuer. + +1. Applique les étiquettes (labels) et marques (taints) au noeud control-plane afin qu'aucune charge de travail additionnelle ne s'y exécute. + +1. Génère le jeton que les noeuds additionnels peuvent utiliser pour s'enregistrer avec un control-plane. Il est possible que l'utilisateur fournisse un jeton en utilisant `--token`, + comme décrit dans la documentation [à propos du jeton kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-token/). + +1. Produit tous les fichiers de configuration requis pour autoriser les noeuds à rejoindre le cluster avec les + [jetons d'assemblage](/docs/reference/access-authn-authz/bootstrap-tokens/) et le mécanisme + [d'assemblage TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) : + + - Ecrit une ConfigMap pour produire toute la configuration nécessaire + pour rejoindre le cluster et installer les règles d'accès RBAC sous jacentes. + + - Permet aux jetons d'assemblage d'accéder à l'API CSR (Certificate Signing Request, requête de signature de certificat). + + - Configure l'acceptation automatique des nouvelles requêtes CSR. + + Voir [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) pour de l'information complémentaire. + +1. Installe un serveur DNS (CoreDNS) et les modules de l'extension kube-proxy en utilisant l'API Server. + Dans la version 1.11 (et au delà) de Kubernetes, CoreDNS est le serveur DNS par défaut. + Pour installer kube-dns au lieu de CoreDNS, l'extension DNS doit être configurée dans la `ClusterConfiguration` de kubeadm. + Pour plus d'information, se référer à la section ci-dessous intitulée : + `Utiliser kubeadm init avec un fichier de configuration`. + Vous remarquerez que bien que le serveur DNS soit déployé, il ne sera pas programmé pour exécution avant que le CNI soit installé. + +### Utiliser les phases d'initialisation avec kubeadm {#init-phases} + +Kubeadm vous permet de créer un noeud de type control-plane en plusieurs phases. Dans 1.13 la commande `kubeadm init phase` a été promue GA (disponibilité générale) alors que précédemment ce n'était qu'une commande alpha : `kubeadm alpha phase`. + +Pour voir la liste des phases et sous phases dans l'ordre, vous pouvez utiliser `kubeadm init --help`. La liste sera affichée en haut de l'écran d'aide et chaque phase aura une description associée. +Bon à savoir : en appelant `kubeadm init` toutes les phases et sous phases seront executées dans cet ordre. + +Certaines phases ont des options uniques, si vous désirez consulter la liste de ces options, ajoutez `--help`, par exemple : + +```shell +sudo kubeadm init phase control-plane controller-manager --help +``` + +Vous pouvez aussi utiliser `--help` pour voir la liste des sous-phases pour une phase parent : + +```shell +sudo kubeadm init phase control-plane --help +``` + +`kubeadm init` a aussi une option nommée `--skip-phases` qui peut être utilisée pour passer outre. Cette option accepte une liste de noms de phases, qui peuvent être retrouvées à partir de la liste ordonée précédente. + +Par exemple : + +```shell +sudo kubeadm init phase control-plane all --config=configfile.yaml +sudo kubeadm init phase etcd local --config=configfile.yaml +# vous pouvez modifier les fichiers manifestes du control-plane et d'etcd +sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml +``` + +Cet exemple écrirait les fichiers manifestes pour le control plane et etcd dans `/etc/kubernetes/manifestes` à partir de la configuration dans `configfile.yaml`. Cela permet de modifier les fichiers et d'ensuite sauter ces phases en utilisant `--skip-phases`. En invoquant la dernière commande, vous créerez un noeud de type control plane avec les les fichiers manifestes personnalisés. + +### Utiliser kubeadm init avec un fichier de configuration {#config-file} + +{{< caution >}} +L'utilisation d'un fichier de configuration est toujours considérée beta et le format du fichier pourrait changer dans les prochaines versions. +{{< /caution >}} + +C'est possible de configurer `kubeadm init` avec un fichier de configuration plutôt qu'avec des options en ligne de commande, et certaines fonctionnalités avancées sont d'ailleurs uniquement disponibles en tant qu'options du fichier de configuration. Ce fichier est passé à kubeadm avec l'option `--config`. + +Dans Kubernetes 1.11 et au delà, la configuration par défaut peut être affichée en utilisant la commande +[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/). + +Il est **recommandé** que vous migriez votre configuration `v1alpha3` vers `v1beta1` en utilisant +la commande [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/), +car le support de `v1alpha3` sera supprimé dans Kubernetes 1.15. + +Pour plus de détails à propos de chaque option de la configuration `v1beta1` vous pouvez consulter la +[référence de l'API](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1). + +### Ajouter des paramètres kube-proxy {#kube-proxy} + +Pour de l'information à propos des paramètres kube-proxy dans la configuration kubeadm, se référer à : +[kube-proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) + +Pour de l'information sur comment activer le mode IPVS avec kubeadm, se référer à : +[IPVS](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/README.md) + +### Passer des options personnalisées aux composants du control plane {#control-plane-flags} + +Pour de l'information sur comment passer des options aux composants du control plane, se référer à : +[control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/) + +### Utiliser des images personnalisées {#custom-images} + +Par défaut, kubeadm télécharge les images depuis `k8s.gcr.io`, à moins que la version demandée de Kubernetes soit une version Intégration Continue (CI). Dans ce cas, `gcr.io/kubernetes-ci-images` est utilisé. + +Vous pouvez outrepasser ce comportement en utilisant [kubeadm avec un fichier de configuration](#config-file). +Les personnalisations permises sont : + +* fournir un `imageRepository` à utiliser à la place de `k8s.gcr.io`. +* régler `useHyperKubeImage` à `true` pour utiliser l'image HyperKube. +* fournir un `imageRepository` et un `imageTag` pour etcd et l'extension (add-on) DNS. + +Notez que le champ de configurtation `kubernetesVersion` ou l'option ligne de commande `--kubernetes-version` affectent la version des images. + +### Utiliser des certificats personnalisés {#custom-certificates} + +Par défaut, kubeadm génère tous les certificats requis pour que votre cluster fonctionne. +Vous pouvez outrepasser ce comportement en fournissant vos propres certificats. + +Pour ce faire, vous devez les placer dans le répertoire spécifié via l'option `--cert-dir` ou spécifié via la propriété `CertificatesDir` de votre fichier de configuration. +Par défaut, le répertoire est `/etc/kubernetes/pki`. + +S'il existe un certificat et une clef privée dans ce répertoire, alors kubeadm sautera l'étape de génération et les fichiers fournis seront utilisés. +Cela signifie que vous pouvez, par exemple, copier un CA (Certificate Authority) existant vers `/etc/kubernetes/pki/ca.crt` +et `/etc/kubernetes/pki/ca.key`, et kubeadm utilisera ce CA pour signer le reste des certificats. + +#### Mode CA externe {#external-ca-mode} + +Il est aussi possible de fournir seulement le fichier `ca.crt` sans le fichier +`ca.key` (seulement dans le cas d'un fichier CA racine, pas pour d'autres paires de certificats). +Si tous les certificats et fichiers kubeconfig sont en place, kubeadm activera le mode "CA externe". +Kubeadm continuera sans clef CA locale. + +Ou alors, vous pouvez utiliser l'outil controller-manager avec `--controllers=csrsigner` en fournissant les emplacements du certificat CA et la clef. + +### Gérer le fichier kubeadm ad-hoc pour kubelet {#kubelet-drop-in} + +Le paquet kubeadm vient avec de la configuration concernant comment kubelet doit se comporter. +Vous remarquerez que la commande CLI `kubeadm` ne modifiera jamais ce fichier. +Ce fichier ad-hoc appartient au paquet deb/rpm de kubeadm. + +Pour en savoir plus sur comment kubeadm gère kubelet, vous pouvez consulter +[cette page](/docs/setup/independent/kubelet-integration). + +### Utilisation de kubeadm avec des runtimes CRI + +Depuis la version v1.6.0, Kubernetes a rendu possible par défaut l'utilisation de CRI, Container Runtime Interface. +Le runtime utilisé par défaut est Docker, activé à travers l'adaptateur fourni `dockershim`, une implémentation CRI, à l'intérieur de `kubelet`. + +Parmi les autres runtimes CRI, on retrouvera : + +- [cri-containerd](https://github.com/containerd/cri-containerd) +- [cri-o](https://github.com/kubernetes-incubator/cri-o) +- [frakti](https://github.com/kubernetes/frakti) +- [rkt](https://github.com/kubernetes-incubator/rktlet) + +Se référer aux [instructions d'installation CRI](/docs/setup/cri) pour plus d'information. + +Après avoir installé `kubeadm` et `kubelet`, exécuter ces étapes additionnelles : + +1. Installer l'adaptateur runtime sur chaque noeud, en suivant les instructions d'installation du projet mentionné ci-dessus. + +1. Configurer kubelet pour utiliser le runtime CRI distant. Ne pas oublier de modifier + `RUNTIME_ENDPOINT` en utilisant la valeur adéquate `/var/run/{your_runtime}.sock`: + +```shell +cat > /etc/systemd/system/kubelet.service.d/20-cri.conf <.<16 + caractères>`. Plus simplement, il doit correspondre à la regexp suivante : + `[a-z0-9]{6}\.[a-z0-9]{16}`. + + kubeadm peut générer un jeton pour vous : + + ```shell + kubeadm token generate + ``` + +1. Démarrer en parallèle le noeud control plane et les noeuds worker nodes avec ce jeton. + Lors de leurs démarrages, ils devraient pouvoir se trouver les uns les autres et former le cluster. + L'option `--token` peut être utilisée aussi bien pour `kubeadm init` que pour `kubeadm join`. + +Une fois que le cluster est correctement démarré, vous pouvez obtenir les identifiants admin depuis le noeud control plane depuis le fichier `/etc/kubernetes/admin.conf` +et les utiliser pour communiquer avec le cluster. + +Vous remarquerez que ce type d'installation présente un niveau de sécurité inférieur puisqu'il ne permet pas la validation du hash du certificat racine avec `--discovery-token-ca-cert-hash` +(puisqu'il n'est pas généré quand les noeuds sont provisionnés). Pour plus d'information, se référer à [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/). + +{{% /capture %}} + +{{% capture whatsnext %}} +* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) pour mieux comprendre les phases `kubeadm init` +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) pour amorcer un noeud Kubernetes worker node Kubernetes et le faire joindre le cluster +* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) pour mettre à jour un cluster Kubernetes vers une version plus récente +* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) pour annuler les changements appliqués avec `kubeadm init` ou `kubeadm join` à un noeud +{{% /capture %}} diff --git a/content/fr/docs/tasks/administer-cluster/developing-cloud-controller-manager.md b/content/fr/docs/tasks/administer-cluster/developing-cloud-controller-manager.md new file mode 100644 index 0000000000..4e76fe2e26 --- /dev/null +++ b/content/fr/docs/tasks/administer-cluster/developing-cloud-controller-manager.md @@ -0,0 +1,42 @@ +--- +title: Développer un Cloud Controller Manager +content_template: templates/concept +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} +Dans les prochaines versions, Cloud Controller Manager sera le moyen privilégié d’intégrer Kubernetes à n’importe quel cloud. +Cela garantira que les fournisseurs de cloud peuvent développer leurs fonctionnalités indépendamment des cycles de publication de Kubernetes. + +{{< feature-state for_k8s_version="1.8" state="alpha" >}} + +Avant d’expliquer comment créer votre propre gestionnaire de contrôleur de cloud, il est utile d’avoir quelques informations sur son fonctionnement interne. +Le cloud controller manager est un code de `kube-controller-manager` utilisant des interfaces Go pour permettre la mise en œuvre d'implémentations depuis n'importe quel cloud. +La plupart des implémentations de contrôleurs génériques seront au cœur du projet, mais elles seront toujours exécutées sur les interfaces de cloud fournies, à condition que l'[interface du fournisseur de cloud](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go#L42-L62) soit satisfaite. + +Pour approfondir un peu les détails de la mise en œuvre, tous les gestionnaires de contrôleurs de nuage vont importer des packages à partir de Kubernetes core, la seule différence étant que chaque projet enregistre son propre fournisseur de nuage en appelant [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go#L56-L66) où une variable globale des fournisseurs de cloud disponibles est mise à jour. + +{{% /capture %}} + +{{% capture body %}} + +## Développement + +### Out of Tree + +Pour construire un out-of-tree cloud-controller-manager pour votre cloud, suivez ces étapes: + +1. Créez un package Go avec une implémentation satisfaisant[cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). +2. Utilisez [main.go dans cloud-controller-manager](https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/controller-manager.go) de Kubernetes core en tant que modèle pour votre main.go. Comme mentionné ci-dessus, la seule différence devrait être le package cloud qui sera importé. +3. Importez votre paquet cloud dans `main.go`, assurez-vous que votre paquet a un bloc `init` à exécuter [cloudprovider.RegisterCloudProvider](https://github.com/kubernetes/cloud-provider/blob/master/plugins.go). + +Utiliser des exemples de fournisseurs de cloud out-of-tree peut être utile. +Vous pouvez trouver la liste [ici](/docs/tasks/administer-cluster/running-cloud-controller.md#examples). + +### In Tree + +Pour les cloud in-tree, vous pouvez exécuter le in-tree cloud controller manager comme un [Daemonset](/examples/admin/cloud/ccm-example.yaml) dans votre cluster. +Voir la [documentation sur l'exécution d'un cloud controller manager](/docs/tasks/administer-cluster/running-cloud-controller.md) pour plus de détails. + +{{% /capture %}} diff --git a/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md b/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md new file mode 100644 index 0000000000..a6b6a5b820 --- /dev/null +++ b/content/fr/docs/tasks/administer-cluster/running-cloud-controller.md @@ -0,0 +1,110 @@ +--- +title: Kubernetes cloud-controller-manager +content_template: templates/concept +--- + +{{% capture overview %}} + +{{< feature-state state="beta" >}} + +Kubernetes v1.6 a introduit un nouveau binaire appelé `cloud-controller-manager`. +`cloud-controller-manager` est un démon qui intègre des boucles de contrôle spécifiques au cloud. +Ces boucles de contrôle spécifiques au cloud étaient à l’origine dans le binaire `kube-controller-manager`. +Étant donné que les fournisseurs de cloud développent et publient à un rythme différent de celui du projet Kubernetes, fournir une abstraction du code du `cloud-controller-manager` permet aux fournisseurs de cloud d’évoluer indépendamment du code Kubernetes principal. + +Le `cloud-controller-manager` peut être lié à tout fournisseur de cloud satisfaisant l'interface [cloudprovider.Interface](https://github.com/kubernetes/cloud-provider/blob/master/cloud.go). +Pour des raisons de retro-compatibilité, le [cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager) fourni dans le projet de base Kubernetes utilise les mêmes bibliothèques ​​que `kube-controller-manager`. +Les fournisseurs de cloud déjà pris en charge nativement par Kubernetes devraient utiliser le cloud-controller-manager ​disponible ​dans le code de Kubernetes pour effectuer une transition visant à faire sortir cette prise en charge du code de Kubernetes. +Dans les futures versions de Kubernetes, tous les cloud-controller-manager seront développés en dehors du projet de base de Kubernetes géré par des sig leads ou des fournisseurs de cloud. + +{{% /capture %}} + +{{% capture body %}} + +## Administration + +### Pré-requis + +Chaque cloud a ses propres exigences pour l'exécution de sa propre intégration, ces exigences sont similaires à celles requises pour l'exécution de `kube-controller-manager`. +En règle générale, vous aurez besoin de: + +* cloud authentification/autorisation: votre cloud peut nécessiter un jeton ou des règles IAM pour permettre l'accès à leurs API +* kubernetes authentification/autorisation: cloud-controller-manager peut avoir besoin de règles RBAC définies pour parler à l'apiserver kubernetes +* la haute disponibilité: Comme pour kube-controller-manager, vous pouvez souhaiter une configuration hautement disponible pour le cloud controller mananger en utilisant l'élection de leader (activée par défaut). + +### Lancer cloud-controller-manager + +L'exécution réussie de cloud-controller-manager nécessite certaines modifications de la configuration de votre cluster. + +* `kube-apiserver` et `kube-controller-manager` NE DOIVENT PAS spécifier l'option `--cloud-provider`. +Cela garantit qu'il n'exécutera aucune boucle spécifique au cloud qui serait exécutée par le cloud-controller-manager. +À l'avenir, cet indicateur sera rendu obsolète et supprimé. +* `kubelet` doit s'exécuter avec `--cloud-provider=external`. +C’est pour nous assurer que le kubelet est conscient qu'il doit être initialisé par le cloud-controller-manager avant qu'il ne commence à travailler. + +N'oubliez pas que la configuration de votre cluster pour utiliser le cloud-controller-manager changera le comportement de votre cluster de plusieurs façons: + +* Les kubelets lancés avec `--cloud-provider=external` auront un marquage `node.cloudprovider.kubernetes.io/uninitialized` avec un effet `NoSchedule` pendant l'initialisation. +Cela indique que le nœud nécessite une seconde initialisation à partir d'un contrôleur externe avant de pouvoir planifier un travail. +Notez que si le cloud-controller-manager n'est pas disponible, les nouveaux nœuds du cluster ne seront pas valides. +Le marquage est important car le planificateur peut nécessiter des informations spécifiques au cloud à propos des nœuds, telles que leur région ou leur type (CPU performant, gpu, mémoire importante, instance ponctuelle, etc.). +* Les informations relatives aux nœuds s'exécutant dans le cloud ne seront plus récupérées à l'aide de métadonnées locales, mais tous les appels d'API pour récupérer les informations de ces nœuds passeront par le cloud-controller-manager. +Cela peut signifier que vous pouvez restreindre l'accès à votre API de cloud sur les kubelets pour une sécurité accrue. +Pour les clusters de plus grande taille, vous voudrez peut-être déterminer si le cloud-controller-manager atteindra les limites de requêtes sur les API de votre fournisseur de cloud puisqu'il est désormais responsable de la quasi-totalité des appels d'API vers votre cloud depuis le cluster. + +À partir de la version 1.8, le cloud-controller-manager peut implémenter: + +* contrôleur de nœud - responsable de la mise à jour des nœud kubernetes à l’aide des API de cloud et de la suppression des nœud kubernetes supprimés sur votre cloud. +* contrôleur de service - responsable des loadbalancers sur votre cloud vers des services de type LoadBalancer. +* contrôleur de route - responsable de la configuration des routes réseau sur votre cloud +* toute autre fonctionnalité que vous voudriez implémenter si vous exécutez en dehors de l'arborescence de Kubernetes. + +## Exemples + +Si vous utilisez un cloud actuellement pris en charge nativement dans Kubernetes et souhaitez adopter le cloud-controller-manager, reportez-vous à la section [cloud-controller-manager dans kubernetes core](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager). + +Pour les cloud-controller-manager ne faisant pas partie de Kubernetes, vous pouvez trouver les projets respectifs dans des dépôts maintenus par des fournisseurs de cloud ou des sig leads. + +* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [keepalived](https://github.com/munnerz/keepalived-cloud-provider) +* [Oracle Cloud Infrastructure](https://github.com/oracle/oci-cloud-controller-manager) +* [Rancher](https://github.com/rancher/rancher-cloud-controller-manager) + +Pour les fournisseurs qui se trouvent déjà dans Kubernetes, vous pouvez exécuter le cloud-controller-manager dans l'arborescence en tant que Daemonset dans votre cluster. +Utilisez ce qui suit comme guide: + +{{< codenew file="admin/cloud/ccm-example.yaml" >}} + +## Limitations + +L'exécution du cloud-controller-manager est soumise à quelques limitations. +Bien que ces limitations soient levées dans les prochaines versions, il est important que vous connaissiez ces limitations pour les charges de travail de production. + +### Prise en charge des volumes + +Le cloud-controller-manager n'implémente aucun des contrôleurs de volume trouvés dans `kube-controller-manager` car les intégrations de volume nécessitent également une coordination avec les kubelets. +Au fur et à mesure de l'évolution de CSI (interface de stockage de conteneur) et de la prise en charge renforcée des plug-ins de volume flexible, le cloud-controller-manager prendra en charge le support nécessaire afin que les clouds puissent pleinement s'intégrer aux volumes. +Pour en savoir plus sur les plug-ins de volume CSI en dehors des sources de Kubernetes consultez [ceci](https://github.com/kubernetes/features/issues/178). + +### Charge sur les APIs cloud + +Dans l'architecture précédente pour les fournisseurs de cloud, nous utilisions des kubelets utilisant un service de métadonnées local pour extraire des informations sur les nœuds. +Avec cette nouvelle architecture, nous comptons désormais entièrement sur les cloud-controller-manager pour extraire les informations de tous les nœuds. +Pour les très grand clusters, vous devez envisager les goulots d'étranglement tels que les besoins en ressources et la limitation de la vitesse des APIs de votre fournisseur cloud. + +### Problème de l'oeuf et de la poule + +L'objectif du projet des cloud-controller-manager est de dissocier le développement des fonctionnalités de cloud computing du projet de base Kubernetes. +Malheureusement, de nombreux aspects du projet Kubernetes supposent que les fonctionnalités de fournisseur de cloud soient étroitement intégrées au projet. +Par conséquent, l'adoption de cette nouvelle architecture peut créer plusieurs situations dans lesquelles une demande d'informations auprès d'un fournisseur de cloud est demandée, mais le cloud-controller-manager peut ne pas être en mesure de renvoyer ces informations sans que la demande d'origine soit complète. + +La fonctionnalité d’amorçage TLS dans Kubelet en est un bon exemple. +Actuellement, l’amorçage TLS suppose que Kubelet aie la possibilité de demander au fournisseur de cloud (ou à un service de métadonnées local) tous ses types d’adresses (privé, public, etc.), mais le cloud-controller-manager ne peut pas définir les types d’adresse d’un nœud sans être initialisé dans le système. Ce qui nécessite que le kubelet possède des certificats TLS pour communiquer avec l’apiserver. + +À mesure que cette initiative évoluera, des modifications seront apportées pour résoudre ces problèmes dans les prochaines versions. + +## Développer votre propre cloud-controller-manager + +Pour créer et développer votre propre cloud-controller-manager, lisez la documentation [Développer un cloud-controller-manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md). + +{{% /capture %}} diff --git a/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md new file mode 100644 index 0000000000..749d7495a6 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -0,0 +1,98 @@ +--- +title: Assigner des pods aux nœuds +content_template: templates/task +weight: 120 +--- + +{{% capture overview %}} +Cette page montre comment assigner un Pod à un nœud particulier dans un cluster Kubernetes. +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Ajouter un label à un nœud + +1. Listez les nœuds de votre cluster : + + ```shell + kubectl get nodes + ``` + + La sortie est la suivante : + + ```shell + NAME STATUS ROLES AGE VERSION + worker0 Ready 1d v1.13.0 + worker1 Ready 1d v1.13.0 + worker2 Ready 1d v1.13.0 + ``` +2. Choisissez l'un de vos nœuds et ajoutez-y un label : + + ```shell + kubectl label nodes disktype=ssd + ``` + + où `` est le nom du noeud que vous avez choisi. + +3. Vérifiez que le nœud que vous avez choisi a le label `disktype=ssd` : + + ```shell + kubectl get nodes --show-labels + ``` + + La sortie est la suivante : + + ```shell + NAME STATUS ROLES AGE VERSION LABELS + worker0 Ready 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0 + worker1 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker1 + worker2 Ready 1d v1.13.0 ...,kubernetes.io/hostname=worker2 + ``` + + Dans la sortie précédente, vous constatez que le nœud `worker0` possède le label `disktype=ssd`. + +## Créez un pod qui sera planifié sur un nœud sélectionné. + +Le fichier de configuration de pod décrit un pod qui possède un selector de nœud de type `disktype:ssd`. Cela signifie que le pod sera planifié sur un nœud ayant le label `disktype=ssd`. + +{{< codenew file="pods/pod-nginx.yaml" >}} + +1. Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur votre nœud choisi : + + ```shell + kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml + ``` + +2. Vérifiez que le pod fonctionne sur le nœud que vous avez choisi : + + ```shell + kubectl get pods --output=wide + ``` + + La sortie est la suivante : + + ```shell + NAME READY STATUS RESTARTS AGE IP NODE + nginx 1/1 Running 0 13s 10.200.0.4 worker0 + ``` +## Créez un pod qui va être planifié sur un nœud spécifique + +Vous pouvez également ordonnancer un pod sur un nœud spécifique via le paramètre `nodeName`. + +{{< codenew file="pods/pod-nginx-specific-node.yaml" >}} + +Utilisez le fichier de configuration pour créer un pod qui sera ordonnancé sur `foo-node` uniquement. + +{{% /capture %}} + +{{% capture whatsnext %}} +Pour en savoir plus sur +[labels et selectors](/docs/concepts/overview/working-with-objects/labels/). +{{% /capture %}} + diff --git a/content/fr/examples/admin/cloud/ccm-example.yaml b/content/fr/examples/admin/cloud/ccm-example.yaml new file mode 100644 index 0000000000..e3bc52e53c --- /dev/null +++ b/content/fr/examples/admin/cloud/ccm-example.yaml @@ -0,0 +1,67 @@ +# Voici un exemple de configuration de cloud-controller-manager en tant que Daemonset dans votre cluster. +# Il suppose que vos masters peuvent executer des pods et ont le role node-role.kubernetes.io/master +# Notez que ce Daemonset ne fonctionnera pas directement pour votre cloud, c’est juste un exemple. + +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:cloud-controller-manager +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin +subjects: +- kind: ServiceAccount + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + labels: + k8s-app: cloud-controller-manager + name: cloud-controller-manager + namespace: kube-system +spec: + selector: + matchLabels: + k8s-app: cloud-controller-manager + template: + metadata: + labels: + k8s-app: cloud-controller-manager + spec: + serviceAccountName: cloud-controller-manager + containers: + - name: cloud-controller-manager + # pour les fournisseurs in-tree, nous utilisons k8s.gcr.io/cloud-controller-manager + # cela peut être remplacé par n'importe quelle autre image pour les fournisseurs out-of-tree + image: k8s.gcr.io/cloud-controller-manager:v1.8.0 + command: + - /usr/local/bin/cloud-controller-manager + - --cloud-provider= # Ajoutez votre propre fournisseur de cloud ici! + - --leader-elect=true + - --use-service-account-credentials + # ces drapeaux varient pour chaque fournisseur de cloud + - --allocate-node-cidrs=true + - --configure-cloud-routes=true + - --cluster-cidr=172.17.0.0/16 + tolerations: + # cela est nécessaire pour que CCM puisse s'initialiser + - key: node.cloudprovider.kubernetes.io/uninitialized + value: "true" + effect: NoSchedule + # le daemonset doit pouvoir être exécuté sur les nœuds master. Le marquage peut varier en fonction de la configuration de votre cluster. + - key: node-role.kubernetes.io/master + effect: NoSchedule + # ceci limite le fonctionnement du CCM sur des nœuds master + # le sélecteur de nœud peut varier en fonction de la configuration de votre cluster + nodeSelector: + node-role.kubernetes.io/master: "" diff --git a/content/fr/examples/pods/pod-nginx-specific-node.yaml b/content/fr/examples/pods/pod-nginx-specific-node.yaml new file mode 100644 index 0000000000..5923400d64 --- /dev/null +++ b/content/fr/examples/pods/pod-nginx-specific-node.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx +spec: + nodeName: foo-node # schedule pod to specific node + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent diff --git a/content/fr/examples/pods/pod-nginx.yaml b/content/fr/examples/pods/pod-nginx.yaml new file mode 100644 index 0000000000..134ddae2aa --- /dev/null +++ b/content/fr/examples/pods/pod-nginx.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + nodeSelector: + disktype: ssd diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md index fad8351cb8..ab5cb4d091 100644 --- a/content/id/docs/concepts/architecture/nodes.md +++ b/content/id/docs/concepts/architecture/nodes.md @@ -138,7 +138,7 @@ Kontroler node memeriksa state masing-masing node untuk durasi yang diten Pada versi Kubernetes sebelum 1.13, `NodeStatus` adalah heartbeat yang diberikan oleh node. Setelah versi 1.13, fitur node lease diperkenalkan sebagai fitur alpha (fitur gate `NodeLease`, -[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). +[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Ketika fitur node lease diaktifasi, setiap node terhubung dengan obyek `Lease` di dalam namespace `kube-node-lease` yang terus diperbarui secara berkala. Kemudian, `NodeStatus` dan node lease keduanya dijadikan sebagai heartbeat dari node. Semua node lease diperbarui sesering mungkin, sedangkan `NodeStatus` dilaporkan dari node untuk master hanya ketika ada perubahan atau telah melewati periode waktu tertentu (default-nya 1 menit, lebih lama daripada default timeout node-node yang terputus jaringannya). diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md new file mode 100644 index 0000000000..8dc7ee5813 --- /dev/null +++ b/content/id/docs/concepts/cluster-administration/certificates.md @@ -0,0 +1,250 @@ +--- +title: Sertifikat +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +Saat menggunakan autentikasi sertifikat klien, kamu dapat membuat sertifikat +secara manual melalui `easyrsa`, `openssl` atau `cfssl`. + +{{% /capture %}} + + +{{% capture body %}} + +### easyrsa + +**easyrsa** dapat digunakan untuk menghasilkan sertifikat kluster kamu secara manual. + +1. Unduh, buka paket, dan inisialisasi versi tambal easyrsa3. + + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki +1. Hasilkan CA. (`--batch` untuk atur mode otomatis. `--req-cn` untuk menggunakan _default_ CN.) + + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass +1. Hasilkan sertifikat dan kunci _server_. + Argumen `--subject-alt-name` digunakan untuk mengatur alamat IP dan nama DNS yang dapat diakses + oleh _server_ API. `MASTER_CLUSTER_IP` biasanya merupakan IP pertama dari CIDR _service cluster_ + yang diset dengan argumen` --service-cluster-ip-range` untuk _server_ API dan + komponen manajer pengontrol. Argumen `--days` digunakan untuk mengatur jumlah hari + masa berlaku sertifikat. + Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama + _domain_ DNS _default_. + + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass +1. Salin `pki/ca.crt`, `pki/issued/server.crt`, dan `pki/private/server.key` ke direktori kamu. +1. Isi dan tambahkan parameter berikut ke dalam parameter mulai _server_ API: + + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + +### openssl + +**openssl** secara manual dapat menghasilkan sertifikat untuk kluster kamu. + +1. Hasilkan ca.key dengan 2048bit: + + openssl genrsa -out ca.key 2048 +1. Hasilkan ca.crt berdasarkan ca.key (gunakan -days untuk mengatur waktu efektif sertifikat): + + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt +1. Hasilkan server.key dengan 2048bit: + + openssl genrsa -out server.key 2048 +1. Buat _file_ konfigurasi untuk menghasilkan _Certificate Signing Request_ (CSR). + Pastikan untuk mengganti nilai yang ditandai dengan kurung sudut (mis. ``) + dengan nilai sebenarnya sebelum menyimpan ke _file_ (mis. `csr.conf`). + Perhatikan bahwa nilai `MASTER_CLUSTER_IP` adalah layanan IP kluster untuk + _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. + Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` + sebagai nama _domain_ DNS _default_. + + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names +1. Hasilkan permintaan penandatanganan sertifikat berdasarkan _file_ konfigurasi: + + openssl req -new -key server.key -out server.csr -config csr.conf +1. Hasilkan sertifikat _server_ menggunakan ca.key, ca.crt dan server.csr: + + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf +1. Lihat sertifikat: + + openssl x509 -noout -text -in ./server.crt + +Terakhir, tambahkan parameter yang sama ke dalam parameter mulai _server_ API. + +### cfssl + +**cfssl** adalah alat lain untuk pembuatan sertifikat. + +1. Unduh, buka paket dan siapkan _command line tools_ seperti yang ditunjukkan di bawah ini. + Perhatikan bahwa kamu mungkin perlu menyesuaikan contoh perintah berdasarkan arsitektur + perangkat keras dan versi cfssl yang kamu gunakan. + + curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl + chmod +x cfssl + curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson + chmod +x cfssljson + curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo +1. Buat direktori untuk menyimpan _artifacts_ dan inisialisasi cfssl: + + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json +1. Buat _file_ konfigurasi JSON untuk menghasilkan _file_ CA, misalnya, `ca-config.json`: + + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } +1. Buat _file_ konfigurasi JSON untuk CA _certificate signing request_ (CSR), misalnya, + `ca-csr.json`. Pastikan untuk mengganti nilai yang ditandai dengan kurung sudut + dengan nilai sebenarnya yang ingin kamu gunakan. + + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Hasilkan kunci CA (`ca-key.pem`) dan sertifikat (`ca.pem`): + + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca +1. Buat _file_ konfigurasi JSON untuk menghasilkan kunci dan sertifikat untuk API + _server_, misalnya, `server-csr.json`. Pastikan untuk mengganti nilai dalam kurung sudut + dengan nilai sebenarnya yang ingin kamu gunakan. `MASTER_CLUSTER_IP` adalah layanan + kluster IP untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. + Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai + nama _domain_ DNS _default_. + + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Buat kunci dan sertifikat untuk server API, yang mana awalnya di + simpan masing-masing ke dalam _file_ `server-key.pem` dan `server.pem`: + + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + + +## Distribusi Sertifikat _Self-Signed_ CA + +_Node_ klien dapat menolak untuk mengakui sertifikat CA yang ditandatangani sendiri sebagai valid. +Untuk _deployment_ non-produksi, atau untuk _deployment_ yang berjalan di belakang _firewall_ perusahaan, +kamu dapat mendistribusikan sertifikat CA yang ditandatangani sendiri untuk semua klien dan _refresh_ +daftar lokal untuk sertifikat yang valid. + +Pada setiap klien, lakukan operasi berikut: + +```bash +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +``` +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## Sertifikat API + +Kamu dapat menggunakan API `Certificate.k8s.io` untuk menyediakan +sertifikat x509 yang digunakan untuk autentikasi seperti yang didokumentasikan +[di sini](/docs/tasks/tls/managing-tls-in-a-cluster). + +{{% /capture %}} diff --git a/content/id/docs/concepts/storage/volume-snapshot-classes.md b/content/id/docs/concepts/storage/volume-snapshot-classes.md new file mode 100644 index 0000000000..5fd92fb42a --- /dev/null +++ b/content/id/docs/concepts/storage/volume-snapshot-classes.md @@ -0,0 +1,58 @@ +--- +title: VolumeSnapshotClass +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} + +Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan, +sangat disarankan untuk membaca [_snapshot_ volume](/docs/concepts/storage/volume-snapshots/) +dan [kelas penyimpanan (_storage class_)](/docs/concepts/storage/storage-classes) terlebih dahulu. + +{{% /capture %}} + + +{{% capture body %}} + +## Pengenalan + +Seperti halnya StorageClass yang menyediakan cara bagi admin untuk mendefinisikan +"kelas" penyimpanan yang mereka tawarkan saat proses penyediaan sebuah volume, VolumeSnapshotClass +menyediakan cara untuk mendefinisikan "kelas" penyimpanan saat menyediakan _snapshot_ volume. + +## Sumber Daya VolumeSnapshotClass + +Masing-masing VolumeSnapshotClass terdiri dari _field_ `snapshotter` dan `parameters`, +yang digunakan saat sebuah VolumeSnapshot yang dimiliki kelas tersebut perlu untuk +disediakan secara dinamis. + +Nama yang dimiliki suatu objek VolumeSnapshotClass sangatlah penting, karena digunakan +oleh pengguna saat meminta sebuah kelas tertentu. Admin dapat mengatur nama dan parameter +lainnya dari sebuah kelas saat pertama kali membuat objek VolumeSnapshotClass. Objek +tidak dapat diubah setelah dibuat. + +Admin dapat mengatur VolumeSnapshotClass _default_ untuk VolumeSnapshot yang tidak +memiliki spesifikasi kelas apapun. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1alpha1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +snapshotter: csi-hostpath +parameters: +``` + +### `snapshotter` + +VolumeSnapshotClass memiliki sebuah `snapshotter` yang menentukan plugin volume CSI +apa yang digunakan untuk penyediaan VolumeSnapshot. _Field_ ini wajib diatur. + +### `parameters` + +VolumeSnapshotClass memiliki parameter-parameter yang menggambarkan _snapshot_ volume +di dalam VolumeSnapshotClass. Parameter-parameter yang berbeda diperbolehkan tergantung +dari `shapshotter`. + +{{% /capture %}} diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md index bba9a7bf74..c7ca78917b 100644 --- a/content/it/docs/concepts/architecture/nodes.md +++ b/content/it/docs/concepts/architecture/nodes.md @@ -161,7 +161,7 @@ controlla lo stato di ogni nodo ogni `--node-monitor-period` secondi. Nelle versioni di Kubernetes precedenti alla 1.13, NodeStatus è l'heartbeat di nodo. A partire da Kubernetes 1.13, la funzionalità di lease del nodo viene introdotta come un funzione alfa (porta caratteristica `NodeLease`, -[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). +[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Quando la funzione di lease del nodo è abilitata, ogni nodo ha un oggetto `Lease` associato in spazio dei nomi `kube-node-lease` che viene rinnovato periodicamente dal nodo ed entrambi NodeStatus e lease del nodo vengono considerati heartbeat dal nodo. Locazioni di nodi diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 123d2683a2..c58db56c9e 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -21,7 +21,7 @@ weight: 10

目標

  • アプリケーションのデプロイについて学ぶ
    • -
  • kubectlを使って、Kubenretes上にはじめてのアプリケーションをデプロイする
    • +
  • kubectlを使って、Kubernetes上にはじめてのアプリケーションをデプロイする
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 3eb52d2199..cd639c39c7 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -126,7 +126,7 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll 세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, 노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. (ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. 쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가 된다. 쿠버네티스 1.13을 시작으로 node lease 기능이 알파 기능으로 (기능 게이트 `NodeLease`, -[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)) 소개되었다. node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 (기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) 노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. 노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과 성능 두 가지 측면에서 노드 하트비트를 상당히 경제적이도록 해준다. +[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)) 소개되었다. node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 (기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) 노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. 노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과 성능 두 가지 측면에서 노드 하트비트를 상당히 경제적이도록 해준다. 쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에 문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에) 더 개선된 문제 해결을 하도록 노드 컨트롤러의 로직을 업데이트 했다. 1.4를 시작으로, 노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터 내 모든 노드를 살핀다. diff --git a/content/pt/docs/concepts/cluster-administration/certificates.md b/content/pt/docs/concepts/cluster-administration/certificates.md new file mode 100644 index 0000000000..36554c1b88 --- /dev/null +++ b/content/pt/docs/concepts/cluster-administration/certificates.md @@ -0,0 +1,228 @@ +--- +title: Certificates +content_template: templates/concept +weight: 20 +--- + + +{{% capture overview %}} + +Ao usar um client para autenticação de certificado, você pode gerar certificados +manualmente através `easyrsa`, `openssl` ou `cfssl`. + +{{% /capture %}} + + +{{% capture body %}} + +### easyrsa + +**easyrsa** pode gerar manualmente certificados para o seu cluster. + +1. Baixe, descompacte e inicialize a versão corrigida do easyrsa3. + + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki +1. Gerar o CA. (`--batch` set automatic mode. `--req-cn` default CN to use.) + + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass +1. Gere o certificado e a chave do servidor. + O argumento `--subject-alt-name` define os possíveis IPs e nomes (DNS) que o servidor de API usará para ser acessado. O `MASTER_CLUSTER_IP` é geralmente o primeiro IP do serviço CIDR que é especificado como argumento em `--service-cluster-ip-range` para o servidor de API e o componente gerenciador do controlador. O argumento `--days` é usado para definir o número de dias após o qual o certificado expira. + O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão + + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass +1. Copie `pki/ca.crt`, `pki/issued/server.crt`, e `pki/private/server.key` para o seu diretório. +1. Preencha e adicione os seguintes parâmetros aos parâmetros de inicialização do servidor de API: + + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + +### openssl + +**openssl** pode gerar manualmente certificados para o seu cluster. + +1. Gere um ca.key com 2048bit: + + openssl genrsa -out ca.key 2048 +1. De acordo com o ca.key, gere um ca.crt (use -days para definir o tempo efetivo do certificado): + + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt +1. Gere um server.key com 2048bit: + + openssl genrsa -out server.key 2048 +1. Crie um arquivo de configuração para gerar uma solicitação de assinatura de certificado (CSR - Certificate Signing Request). Certifique-se de substituir os valores marcados com colchetes angulares (por exemplo, ``) com valores reais antes de salvá-lo em um arquivo (por exemplo, `csr.conf`). Note que o valor para o `MASTER_CLUSTER_IP` é o IP do cluster de serviços para o Servidor de API, conforme descrito na subseção anterior. O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão + + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names +1. Gere a solicitação de assinatura de certificado com base no arquivo de configuração: + + openssl req -new -key server.key -out server.csr -config csr.conf +1. Gere o certificado do servidor usando o ca.key, ca.crt e server.csr: + + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf +1. Veja o certificado: + + openssl x509 -noout -text -in ./server.crt + +Por fim, adicione os mesmos parâmetros nos parâmetros iniciais do Servidor de API. + +### cfssl + +**cfssl** é outra ferramenta para geração de certificados. + +1. Baixe, descompacte e prepare as ferramentas de linha de comando, conforme mostrado abaixo. Observe que você pode precisar adaptar os comandos de exemplo abaixo com base na arquitetura do hardware e versão cfssl que você está usando. + + curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o cfssl + chmod +x cfssl + curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson + chmod +x cfssljson + curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo +1. Crie um diretório para conter os artefatos e inicializar o cfssl: + + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json +1. Crie um arquivo de configuração JSON para gerar o arquivo CA, por exemplo, `ca-config.json`: + + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } +1. Crie um arquivo de configuração JSON para o CA - solicitação de assinatura de certificado (CSR - Certificate Signing Request), por exemplo, `ca-csr.json`. Certifique-se de substituir os valores marcados com colchetes angulares por valores reais que você deseja usar. + + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Gere a chave CA (`ca-key.pem`) e o certificado (` ca.pem`): + + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca +1. Crie um arquivo de configuração JSON para gerar chaves e certificados para o Servidor de API, por exemplo, `server-csr.json`. Certifique-se de substituir os valores entre colchetes angulares por valores reais que você deseja usar. O `MASTER_CLUSTER_IP` é o IP do serviço do cluster para o servidor da API, conforme descrito na subseção anterior. O exemplo abaixo também assume que você está usando `cluster.local` como DNS de domínio padrão + + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } +1. Gere a chave e o certificado para o Servidor de API, que são, por padrão, salvos nos arquivos `server-key.pem` e` server.pem` respectivamente: + + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + + +## Distribuindo Certificado CA auto assinado + +Um nó cliente pode se recusar a reconhecer o certificado CA self-signed como válido. +Para uma implementação de não produção ou para uma instalação que roda atrás de um firewall, você pode distribuir certificados auto-assinados para todos os clientes e atualizar a lista de certificados válidos. + +Em cada cliente, execute as seguintes operações: + +```bash +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +``` +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## API de certificados + +Você pode usar a API `certificates.k8s.io` para provisionar +certificados x509 a serem usados ​​para autenticação conforme documentado +[aqui](/docs/tasks/tls/managing-tls-in-a-cluster). + +{{% /capture %}} diff --git a/content/zh/docs/home/supported-doc-versions.md b/content/zh/docs/home/supported-doc-versions.md new file mode 100644 index 0000000000..eae8ac97b1 --- /dev/null +++ b/content/zh/docs/home/supported-doc-versions.md @@ -0,0 +1,29 @@ +--- +title: Kubernetes 文档支持的版本 +content_template: templates/concept +card: + name: about + weight: 10 + title: Kubernetes 文档支持的版本 +--- + +{{% capture overview %}} + +本网站包含了当前最新版本和之前四个版本的 Kubernetes。 + +{{% /capture %}} + +{{% capture body %}} + +## 当前最新版本 + +当前版本是 +[{{< param "version" >}}](/)。 + +## 往期版本 + +{{< versions-other >}} + +{{% /capture %}} + + diff --git a/data/user-personas/contributors/code-contributor.yaml b/data/user-personas/contributors/code-contributor.yaml index 24f007faf8..7be4ca78b7 100644 --- a/data/user-personas/contributors/code-contributor.yaml +++ b/data/user-personas/contributors/code-contributor.yaml @@ -9,7 +9,7 @@ foundational: intermediate: - label: "Learn about the Kubernetes Enhancement Proposal (KEP) process" icon: fa-upload - url: "https://github.com/kubernetes/community/blob/master/keps/0001-kubernetes-enhancement-proposal-process.md" + url: "https://github.com/kubernetes/enhancements/blob/master/keps/0001-kubernetes-enhancement-proposal-process.md" - label: "Understand the API conventions" icon: fa-map-o url: "https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md" diff --git a/layouts/blog/baseof.html b/layouts/blog/baseof.html index 358cb7bd3c..85095f152c 100644 --- a/layouts/blog/baseof.html +++ b/layouts/blog/baseof.html @@ -20,15 +20,15 @@
{{ with site.Home.OutputFormats.Get "rss" -}} - RSS Feed +
RSS Feed
 {{ end -}} - Submit a Post - @Kubernetesio - View on GitHub - #kubernetes-users - Stack Overflow - Forum - Download Kubernetes +
Submit a Post
 +
@Kubernetesio
 +
on GitHub
+
#kubernetes-users
+
Overflow
 +
Forum
+
Kubernetes
{{ partialCached "blog/archive.html" . }} diff --git a/layouts/partials/css.html b/layouts/partials/css.html index e36d1426fc..520611ec8c 100644 --- a/layouts/partials/css.html +++ b/layouts/partials/css.html @@ -17,7 +17,6 @@ {{- end }} - {{- if .Params.deprecated }} diff --git a/layouts/partials/docs/glossary-terms.html b/layouts/partials/docs/glossary-terms.html index b0153d49fb..b46949865c 100644 --- a/layouts/partials/docs/glossary-terms.html +++ b/layouts/partials/docs/glossary-terms.html @@ -3,9 +3,7 @@ {{ $pages := $glossaryBundle.Resources.ByType "page" }} {{- range site.Params.language_alternatives -}} {{- with (where $glossaryBundle.Translations ".Lang" . ) -}} - {{ $p := (index . 0) }} - {{ $pages = $pages | lang.Merge ($p.Resources.ByType "page") }} - {{ end }} + {{ $p := (index . 0) }}{{ $pages = $pages | lang.Merge ($p.Resources.ByType "page") }}{{ end }} {{ end }} {{- $.Scratch.Set "glossary_items" $pages -}} {{- else -}} diff --git a/layouts/partials/head.html b/layouts/partials/head.html index 30e3f28293..da38d8550e 100644 --- a/layouts/partials/head.html +++ b/layouts/partials/head.html @@ -37,7 +37,8 @@ - + + {{ with .Params.js }}{{ range (split . ",") }} diff --git a/static/css/blog.css b/static/css/blog.css index 7098e241ea..c584ee4e53 100644 --- a/static/css/blog.css +++ b/static/css/blog.css @@ -271,7 +271,7 @@ h3.post-title{ box-sizing: border-box; padding: 0 0 0 15px; margin: 10px 0; - line-height: 40px; + line-height: 50px; white-space: nowrap; font-family: Roboto, sans-serif; } @@ -401,10 +401,21 @@ ul { /* Sidebar Icon Styles */ .widget-link svg { - font-size: 48px; + font-size: 40px; color:#326DE6; + vertical-align: middle; + width: 40px !important; } +.widget-link div { + display: flex; +} + +.widget-link .widget-link-text { + margin-left: 6px; +} + + /* SideNavigation Styles */ .heading-year-toggle-checkbox, .heading-month-toggle-checkbox{ diff --git a/static/css/sweetalert.min.css b/static/css/sweetalert.min.css deleted file mode 100644 index f698e78dba..0000000000 --- a/static/css/sweetalert.min.css +++ /dev/null @@ -1,5 +0,0 @@ -body.stop-scrolling{height:100%;overflow:hidden}.sweet-overlay{background-color:black;-ms-filter:"alpha(opacity=40)";background-color:rgba(0,0,0,0.4);position:fixed;left:0;right:0;top:0;bottom:0;display:none;z-index:10000}.sweet-alert{background-color:white;font-family:'Open Sans','Helvetica Neue',Helvetica,Arial,sans-serif;width:478px;padding:17px;border-radius:5px;text-align:center;position:fixed;left:50%;top:50%;margin-left:-256px;margin-top:-200px;overflow:hidden;display:none;z-index:99999}@media all and (max-width:540px){.sweet-alert{width:auto;margin-left:0;margin-right:0;left:15px;right:15px}}.sweet-alert h2{color:#575757;font-size:30px;text-align:center;font-weight:600;text-transform:none;position:relative;margin:25px 0;padding:0;line-height:40px;display:block}.sweet-alert p{color:#797979;font-size:16px;text-align:center;font-weight:300;position:relative;text-align:inherit;float:none;margin:0;padding:0;line-height:normal}.sweet-alert fieldset{border:0;position:relative}.sweet-alert .sa-error-container{background-color:#f1f1f1;margin-left:-17px;margin-right:-17px;overflow:hidden;padding:0 10px;max-height:0;webkit-transition:padding .15s,max-height .15s;transition:padding .15s,max-height .15s}.sweet-alert .sa-error-container.show{padding:10px 0;max-height:100px;webkit-transition:padding .2s,max-height .2s;transition:padding .25s,max-height .25s}.sweet-alert .sa-error-container .icon{display:inline-block;width:24px;height:24px;border-radius:50%;background-color:#ea7d7d;color:white;line-height:24px;text-align:center;margin-right:3px}.sweet-alert .sa-error-container p{display:inline-block}.sweet-alert .sa-input-error{position:absolute;top:29px;right:26px;width:20px;height:20px;opacity:0;-webkit-transform:scale(0.5);transform:scale(0.5);-webkit-transform-origin:50% 50%;transform-origin:50% 50%;-webkit-transition:all .1s;transition:all .1s}.sweet-alert .sa-input-error::before,.sweet-alert .sa-input-error::after{content:"";width:20px;height:6px;background-color:#f06e57;border-radius:3px;position:absolute;top:50%;margin-top:-4px;left:50%;margin-left:-9px}.sweet-alert .sa-input-error::before{-webkit-transform:rotate(-45deg);transform:rotate(-45deg)}.sweet-alert .sa-input-error::after{-webkit-transform:rotate(45deg);transform:rotate(45deg)}.sweet-alert .sa-input-error.show{opacity:1;-webkit-transform:scale(1);transform:scale(1)}.sweet-alert input{width:100%;box-sizing:border-box;border-radius:3px;border:1px solid #d7d7d7;height:43px;margin-top:10px;margin-bottom:17px;font-size:18px;box-shadow:inset 0 1px 1px rgba(0,0,0,0.06);padding:0 12px;display:none;-webkit-transition:all .3s;transition:all .3s}.sweet-alert input:focus{outline:0;box-shadow:0 0 3px #c4e6f5;border:1px solid #b4dbed}.sweet-alert input:focus::-moz-placeholder{transition:opacity .3s .03s ease;opacity:.5}.sweet-alert input:focus:-ms-input-placeholder{transition:opacity .3s .03s ease;opacity:.5}.sweet-alert input:focus::-webkit-input-placeholder{transition:opacity .3s .03s ease;opacity:.5}.sweet-alert input::-moz-placeholder{color:#bdbdbd}.sweet-alert input:-ms-input-placeholder{color:#bdbdbd}.sweet-alert input::-webkit-input-placeholder{color:#bdbdbd}.sweet-alert.show-input input{display:block}.sweet-alert .sa-confirm-button-container{display:inline-block;position:relative}.sweet-alert .la-ball-fall{position:absolute;left:50%;top:50%;margin-left:-27px;margin-top:4px;opacity:0;visibility:hidden}.sweet-alert button{background-color:#8cd4f5;color:white;border:0;box-shadow:none;font-size:17px;font-weight:500;-webkit-border-radius:4px;border-radius:5px;padding:10px 32px;margin:26px 5px 0 5px;cursor:pointer}.sweet-alert button:focus{outline:0;box-shadow:0 0 2px rgba(128,179,235,0.5),inset 0 0 0 1px rgba(0,0,0,0.05)}.sweet-alert button:hover{background-color:#7ecff4}.sweet-alert button:active{background-color:#5dc2f1}.sweet-alert button.cancel{background-color:#c1c1c1}.sweet-alert button.cancel:hover{background-color:#b9b9b9}.sweet-alert button.cancel:active{background-color:#a8a8a8}.sweet-alert button.cancel:focus{box-shadow:rgba(197,205,211,0.8) 0 0 2px,rgba(0,0,0,0.0470588) 0 0 0 1px inset !important}.sweet-alert button[disabled]{opacity:.6;cursor:default}.sweet-alert button.confirm[disabled]{color:transparent}.sweet-alert button.confirm[disabled] ~ .la-ball-fall{opacity:1;visibility:visible;transition-delay:0}.sweet-alert button::-moz-focus-inner{border:0}.sweet-alert[data-has-cancel-button=false] button{box-shadow:none !important}.sweet-alert[data-has-confirm-button=false][data-has-cancel-button=false]{padding-bottom:40px}.sweet-alert .sa-icon{width:80px;height:80px;border:4px solid gray;-webkit-border-radius:40px;border-radius:40px;border-radius:50%;margin:20px auto;padding:0;position:relative;box-sizing:content-box}.sweet-alert .sa-icon.sa-error{border-color:#f27474}.sweet-alert .sa-icon.sa-error .sa-x-mark{position:relative;display:block}.sweet-alert .sa-icon.sa-error .sa-line{position:absolute;height:5px;width:47px;background-color:#f27474;display:block;top:37px;border-radius:2px}.sweet-alert .sa-icon.sa-error .sa-line.sa-left{-webkit-transform:rotate(45deg);transform:rotate(45deg);left:17px}.sweet-alert .sa-icon.sa-error .sa-line.sa-right{-webkit-transform:rotate(-45deg);transform:rotate(-45deg);right:16px}.sweet-alert .sa-icon.sa-warning{border-color:#f8bb86}.sweet-alert .sa-icon.sa-warning .sa-body{position:absolute;width:5px;height:47px;left:50%;top:10px;-webkit-border-radius:2px;border-radius:2px;margin-left:-2px;background-color:#f8bb86}.sweet-alert .sa-icon.sa-warning .sa-dot{position:absolute;width:7px;height:7px;-webkit-border-radius:50%;border-radius:50%;margin-left:-3px;left:50%;bottom:10px;background-color:#f8bb86}.sweet-alert .sa-icon.sa-info{border-color:#c9dae1}.sweet-alert .sa-icon.sa-info::before{content:"";position:absolute;width:5px;height:29px;left:50%;bottom:17px;border-radius:2px;margin-left:-2px;background-color:#c9dae1}.sweet-alert .sa-icon.sa-info::after{content:"";position:absolute;width:7px;height:7px;border-radius:50%;margin-left:-3px;top:19px;background-color:#c9dae1}.sweet-alert .sa-icon.sa-success{border-color:#a5dc86}.sweet-alert .sa-icon.sa-success::before,.sweet-alert .sa-icon.sa-success::after{content:'';-webkit-border-radius:40px;border-radius:40px;border-radius:50%;position:absolute;width:60px;height:120px;background:white;-webkit-transform:rotate(45deg);transform:rotate(45deg)}.sweet-alert .sa-icon.sa-success::before{-webkit-border-radius:120px 0 0 120px;border-radius:120px 0 0 120px;top:-7px;left:-33px;-webkit-transform:rotate(-45deg);transform:rotate(-45deg);-webkit-transform-origin:60px 60px;transform-origin:60px 60px}.sweet-alert .sa-icon.sa-success::after{-webkit-border-radius:0 120px 120px 0;border-radius:0 120px 120px 0;top:-11px;left:30px;-webkit-transform:rotate(-45deg);transform:rotate(-45deg);-webkit-transform-origin:0 60px;transform-origin:0 60px}.sweet-alert .sa-icon.sa-success .sa-placeholder{width:80px;height:80px;border:4px solid rgba(165,220,134,0.2);-webkit-border-radius:40px;border-radius:40px;border-radius:50%;box-sizing:content-box;position:absolute;left:-4px;top:-4px;z-index:2}.sweet-alert .sa-icon.sa-success .sa-fix{width:5px;height:90px;background-color:white;position:absolute;left:28px;top:8px;z-index:1;-webkit-transform:rotate(-45deg);transform:rotate(-45deg)}.sweet-alert .sa-icon.sa-success .sa-line{height:5px;background-color:#a5dc86;display:block;border-radius:2px;position:absolute;z-index:2}.sweet-alert .sa-icon.sa-success .sa-line.sa-tip{width:25px;left:14px;top:46px;-webkit-transform:rotate(45deg);transform:rotate(45deg)}.sweet-alert .sa-icon.sa-success .sa-line.sa-long{width:47px;right:8px;top:38px;-webkit-transform:rotate(-45deg);transform:rotate(-45deg)}.sweet-alert .sa-icon.sa-custom{background-size:contain;border-radius:0;border:0;background-position:center center;background-repeat:no-repeat}@-webkit-keyframes showSweetAlert{0{transform:scale(0.7);-webkit-transform:scale(0.7)}45%{transform:scale(1.05);-webkit-transform:scale(1.05)}80%{transform:scale(0.95);-webkit-transform:scale(0.95)}100%{transform:scale(1);-webkit-transform:scale(1)}}@keyframes showSweetAlert{0{transform:scale(0.7);-webkit-transform:scale(0.7)}45%{transform:scale(1.05);-webkit-transform:scale(1.05)}80%{transform:scale(0.95);-webkit-transform:scale(0.95)}100%{transform:scale(1);-webkit-transform:scale(1)}}@-webkit-keyframes hideSweetAlert{0{transform:scale(1);-webkit-transform:scale(1)}100%{transform:scale(0.5);-webkit-transform:scale(0.5)}}@keyframes hideSweetAlert{0{transform:scale(1);-webkit-transform:scale(1)}100%{transform:scale(0.5);-webkit-transform:scale(0.5)}}@-webkit-keyframes slideFromTop{0{top:0}100%{top:50%}}@keyframes slideFromTop{0{top:0}100%{top:50%}}@-webkit-keyframes slideToTop{0{top:50%}100%{top:0}}@keyframes slideToTop{0{top:50%}100%{top:0}}@-webkit-keyframes slideFromBottom{0{top:70%}100%{top:50%}}@keyframes slideFromBottom{0{top:70%}100%{top:50%}}@-webkit-keyframes slideToBottom{0{top:50%}100%{top:70%}}@keyframes slideToBottom{0{top:50%}100%{top:70%}}.showSweetAlert[data-animation=pop]{-webkit-animation:showSweetAlert .3s;animation:showSweetAlert .3s}.showSweetAlert[data-animation=none]{-webkit-animation:none;animation:none}.showSweetAlert[data-animation=slide-from-top]{-webkit-animation:slideFromTop .3s;animation:slideFromTop .3s}.showSweetAlert[data-animation=slide-from-bottom]{-webkit-animation:slideFromBottom .3s;animation:slideFromBottom .3s}.hideSweetAlert[data-animation=pop]{-webkit-animation:hideSweetAlert .2s;animation:hideSweetAlert .2s}.hideSweetAlert[data-animation=none]{-webkit-animation:none;animation:none}.hideSweetAlert[data-animation=slide-from-top]{-webkit-animation:slideToTop .4s;animation:slideToTop .4s}.hideSweetAlert[data-animation=slide-from-bottom]{-webkit-animation:slideToBottom .3s;animation:slideToBottom .3s}@-webkit-keyframes animateSuccessTip{0{width:0;left:1px;top:19px}54%{width:0;left:1px;top:19px}70%{width:50px;left:-8px;top:37px}84%{width:17px;left:21px;top:48px}100%{width:25px;left:14px;top:45px}}@keyframes animateSuccessTip{0{width:0;left:1px;top:19px}54%{width:0;left:1px;top:19px}70%{width:50px;left:-8px;top:37px}84%{width:17px;left:21px;top:48px}100%{width:25px;left:14px;top:45px}}@-webkit-keyframes animateSuccessLong{0{width:0;right:46px;top:54px}65%{width:0;right:46px;top:54px}84%{width:55px;right:0;top:35px}100%{width:47px;right:8px;top:38px}}@keyframes animateSuccessLong{0{width:0;right:46px;top:54px}65%{width:0;right:46px;top:54px}84%{width:55px;right:0;top:35px}100%{width:47px;right:8px;top:38px}}@-webkit-keyframes rotatePlaceholder{0{transform:rotate(-45deg);-webkit-transform:rotate(-45deg)}5%{transform:rotate(-45deg);-webkit-transform:rotate(-45deg)}12%{transform:rotate(-405deg);-webkit-transform:rotate(-405deg)}100%{transform:rotate(-405deg);-webkit-transform:rotate(-405deg)}}@keyframes rotatePlaceholder{0{transform:rotate(-45deg);-webkit-transform:rotate(-45deg)}5%{transform:rotate(-45deg);-webkit-transform:rotate(-45deg)}12%{transform:rotate(-405deg);-webkit-transform:rotate(-405deg)}100%{transform:rotate(-405deg);-webkit-transform:rotate(-405deg)}}.animateSuccessTip{-webkit-animation:animateSuccessTip .75s;animation:animateSuccessTip .75s}.animateSuccessLong{-webkit-animation:animateSuccessLong .75s;animation:animateSuccessLong .75s}.sa-icon.sa-success.animate::after{-webkit-animation:rotatePlaceholder 4.25s ease-in;animation:rotatePlaceholder 4.25s ease-in}@-webkit-keyframes animateErrorIcon{0{transform:rotateX(100deg);-webkit-transform:rotateX(100deg);opacity:0}100%{transform:rotateX(0);-webkit-transform:rotateX(0);opacity:1}}@keyframes animateErrorIcon{0{transform:rotateX(100deg);-webkit-transform:rotateX(100deg);opacity:0}100%{transform:rotateX(0);-webkit-transform:rotateX(0);opacity:1}}.animateErrorIcon{-webkit-animation:animateErrorIcon .5s;animation:animateErrorIcon .5s}@-webkit-keyframes animateXMark{0{transform:scale(0.4);-webkit-transform:scale(0.4);margin-top:26px;opacity:0}50%{transform:scale(0.4);-webkit-transform:scale(0.4);margin-top:26px;opacity:0}80%{transform:scale(1.15);-webkit-transform:scale(1.15);margin-top:-6px}100%{transform:scale(1);-webkit-transform:scale(1);margin-top:0;opacity:1}}@keyframes animateXMark{0{transform:scale(0.4);-webkit-transform:scale(0.4);margin-top:26px;opacity:0}50%{transform:scale(0.4);-webkit-transform:scale(0.4);margin-top:26px;opacity:0}80%{transform:scale(1.15);-webkit-transform:scale(1.15);margin-top:-6px}100%{transform:scale(1);-webkit-transform:scale(1);margin-top:0;opacity:1}}.animateXMark{-webkit-animation:animateXMark .5s;animation:animateXMark .5s}@-webkit-keyframes pulseWarning{0{border-color:#f8d486}100%{border-color:#f8bb86}}@keyframes pulseWarning{0{border-color:#f8d486}100%{border-color:#f8bb86}}.pulseWarning{-webkit-animation:pulseWarning .75s infinite alternate;animation:pulseWarning .75s infinite alternate}@-webkit-keyframes pulseWarningIns{0{background-color:#f8d486}100%{background-color:#f8bb86}}@keyframes pulseWarningIns{0{background-color:#f8d486}100%{background-color:#f8bb86}}.pulseWarningIns{-webkit-animation:pulseWarningIns .75s infinite alternate;animation:pulseWarningIns .75s infinite alternate}@-webkit-keyframes rotate-loading{0{transform:rotate(0)}100%{transform:rotate(360deg)}}@keyframes rotate-loading{0{transform:rotate(0)}100%{transform:rotate(360deg)}}.sweet-alert .sa-icon.sa-error .sa-line.sa-left{-ms-transform:rotate(45deg) \9}.sweet-alert .sa-icon.sa-error .sa-line.sa-right{-ms-transform:rotate(-45deg) \9}.sweet-alert .sa-icon.sa-success{border-color:transparent\9}.sweet-alert .sa-icon.sa-success .sa-line.sa-tip{-ms-transform:rotate(45deg) \9}.sweet-alert .sa-icon.sa-success .sa-line.sa-long{-ms-transform:rotate(-45deg) \9}/*! - * Load Awesome v1.1.0 (http://github.danielcardoso.net/load-awesome/) - * Copyright 2015 Daniel Cardoso <@DanielCardoso> - * Licensed under MIT - */.la-ball-fall,.la-ball-fall>div{position:relative;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}.la-ball-fall{display:block;font-size:0;color:#fff}.la-ball-fall.la-dark{color:#333}.la-ball-fall>div{display:inline-block;float:none;background-color:currentColor;border:0 solid currentColor}.la-ball-fall{width:54px;height:18px}.la-ball-fall>div{width:10px;height:10px;margin:4px;border-radius:100%;opacity:0;-webkit-animation:ball-fall 1s ease-in-out infinite;-moz-animation:ball-fall 1s ease-in-out infinite;-o-animation:ball-fall 1s ease-in-out infinite;animation:ball-fall 1s ease-in-out infinite}.la-ball-fall>div:nth-child(1){-webkit-animation-delay:-200ms;-moz-animation-delay:-200ms;-o-animation-delay:-200ms;animation-delay:-200ms}.la-ball-fall>div:nth-child(2){-webkit-animation-delay:-100ms;-moz-animation-delay:-100ms;-o-animation-delay:-100ms;animation-delay:-100ms}.la-ball-fall>div:nth-child(3){-webkit-animation-delay:0;-moz-animation-delay:0;-o-animation-delay:0;animation-delay:0}.la-ball-fall.la-sm{width:26px;height:8px}.la-ball-fall.la-sm>div{width:4px;height:4px;margin:2px}.la-ball-fall.la-2x{width:108px;height:36px}.la-ball-fall.la-2x>div{width:20px;height:20px;margin:8px}.la-ball-fall.la-3x{width:162px;height:54px}.la-ball-fall.la-3x>div{width:30px;height:30px;margin:12px}@-webkit-keyframes ball-fall{0{opacity:0;-webkit-transform:translateY(-145%);transform:translateY(-145%)}10%{opacity:.5}20%{opacity:1;-webkit-transform:translateY(0);transform:translateY(0)}80%{opacity:1;-webkit-transform:translateY(0);transform:translateY(0)}90%{opacity:.5}100%{opacity:0;-webkit-transform:translateY(145%);transform:translateY(145%)}}@-moz-keyframes ball-fall{0{opacity:0;-moz-transform:translateY(-145%);transform:translateY(-145%)}10%{opacity:.5}20%{opacity:1;-moz-transform:translateY(0);transform:translateY(0)}80%{opacity:1;-moz-transform:translateY(0);transform:translateY(0)}90%{opacity:.5}100%{opacity:0;-moz-transform:translateY(145%);transform:translateY(145%)}}@-o-keyframes ball-fall{0{opacity:0;-o-transform:translateY(-145%);transform:translateY(-145%)}10%{opacity:.5}20%{opacity:1;-o-transform:translateY(0);transform:translateY(0)}80%{opacity:1;-o-transform:translateY(0);transform:translateY(0)}90%{opacity:.5}100%{opacity:0;-o-transform:translateY(145%);transform:translateY(145%)}}@keyframes ball-fall{0{opacity:0;-webkit-transform:translateY(-145%);-moz-transform:translateY(-145%);-o-transform:translateY(-145%);transform:translateY(-145%)}10%{opacity:.5}20%{opacity:1;-webkit-transform:translateY(0);-moz-transform:translateY(0);-o-transform:translateY(0);transform:translateY(0)}80%{opacity:1;-webkit-transform:translateY(0);-moz-transform:translateY(0);-o-transform:translateY(0);transform:translateY(0)}90%{opacity:.5}100%{opacity:0;-webkit-transform:translateY(145%);-moz-transform:translateY(145%);-o-transform:translateY(145%);transform:translateY(145%)}} \ No newline at end of file diff --git a/static/images/docs/gcm.png b/static/images/docs/gcm.png deleted file mode 100644 index c2832c1d98..0000000000 Binary files a/static/images/docs/gcm.png and /dev/null differ diff --git a/static/js/script.js b/static/js/script.js index 45aa30a359..7c0d9bba5e 100755 --- a/static/js/script.js +++ b/static/js/script.js @@ -40,13 +40,13 @@ function copyCode(elem){ try { succeed = document.execCommand("copy"); } catch(e) { - sweetAlert("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard."); + swal("Oh, no...","Sorry, your browser doesn't support document.execCommand('copy'), so we can't copy this code to your clipboard."); succeed = false; } - if (succeed) sweetAlert("Copied to clipboard: ",elem); + if (succeed) swal("Copied to clipboard: ",elem); return succeed; } else { - sweetAlert("Oops!",elem + " not found when trying to copy code"); + swal("Oops!",elem + " not found when trying to copy code"); return false; } } diff --git a/static/js/sweetalert-1.1.3.min.js b/static/js/sweetalert-1.1.3.min.js deleted file mode 100644 index 5c997b4451..0000000000 --- a/static/js/sweetalert-1.1.3.min.js +++ /dev/null @@ -1 +0,0 @@ -!function(e,t,n){"use strict";!function o(e,t,n){function a(s,l){if(!t[s]){if(!e[s]){var i="function"==typeof require&&require;if(!l&&i)return i(s,!0);if(r)return r(s,!0);var u=new Error("Cannot find module '"+s+"'");throw u.code="MODULE_NOT_FOUND",u}var c=t[s]={exports:{}};e[s][0].call(c.exports,function(t){var n=e[s][1][t];return a(n?n:t)},c,c.exports,o,e,t,n)}return t[s].exports}for(var r="function"==typeof require&&require,s=0;s=0;)n=n.replace(" "+t+" "," ");e.className=n.replace(/^\s+|\s+$/g,"")}},i=function(e){var n=t.createElement("div");return n.appendChild(t.createTextNode(e)),n.innerHTML},u=function(e){e.style.opacity="",e.style.display="block"},c=function(e){if(e&&!e.length)return u(e);for(var t=0;t0?setTimeout(o,t):e.style.display="none"});o()},h=function(n){if("function"==typeof MouseEvent){var o=new MouseEvent("click",{view:e,bubbles:!1,cancelable:!0});n.dispatchEvent(o)}else if(t.createEvent){var a=t.createEvent("MouseEvents");a.initEvent("click",!1,!1),n.dispatchEvent(a)}else t.createEventObject?n.fireEvent("onclick"):"function"==typeof n.onclick&&n.onclick()},b=function(t){"function"==typeof t.stopPropagation?(t.stopPropagation(),t.preventDefault()):e.event&&e.event.hasOwnProperty("cancelBubble")&&(e.event.cancelBubble=!0)};a.hasClass=r,a.addClass=s,a.removeClass=l,a.escapeHtml=i,a._show=u,a.show=c,a._hide=d,a.hide=f,a.isDescendant=p,a.getTopMargin=m,a.fadeIn=v,a.fadeOut=y,a.fireClick=h,a.stopEventPropagation=b},{}],5:[function(t,o,a){Object.defineProperty(a,"__esModule",{value:!0});var r=t("./handle-dom"),s=t("./handle-swal-dom"),l=function(t,o,a){var l=t||e.event,i=l.keyCode||l.which,u=a.querySelector("button.confirm"),c=a.querySelector("button.cancel"),d=a.querySelectorAll("button[tabindex]");if(-1!==[9,13,32,27].indexOf(i)){for(var f=l.target||l.srcElement,p=-1,m=0;m"),i.innerHTML=e.html?e.text:s.escapeHtml(e.text||"").split("\n").join("
"),e.text&&s.show(i),e.customClass)s.addClass(t,e.customClass),t.setAttribute("data-custom-class",e.customClass);else{var d=t.getAttribute("data-custom-class");s.removeClass(t,d),t.setAttribute("data-custom-class","")}if(s.hide(t.querySelectorAll(".sa-icon")),e.type&&!a.isIE8()){var f=function(){for(var o=!1,a=0;ao;o++)n=parseInt(e.substr(2*o,2),16),n=Math.round(Math.min(Math.max(0,n+n*t),255)).toString(16),a+=("00"+n).substr(n.length);return a};o.extend=a,o.hexToRgb=r,o.isIE8=s,o.logStr=l,o.colorLuminance=i},{}]},{},[1]),"function"==typeof define&&define.amd?define(function(){return sweetAlert}):"undefined"!=typeof module&&module.exports&&(module.exports=sweetAlert)}(window,document); \ No newline at end of file diff --git a/static/js/sweetalert-2.1.2.min.js b/static/js/sweetalert-2.1.2.min.js new file mode 100644 index 0000000000..dc8f5e78ec --- /dev/null +++ b/static/js/sweetalert-2.1.2.min.js @@ -0,0 +1 @@ +!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.swal=e():t.swal=e()}(this,function(){return function(t){function e(o){if(n[o])return n[o].exports;var r=n[o]={i:o,l:!1,exports:{}};return t[o].call(r.exports,r,r.exports,e),r.l=!0,r.exports}var n={};return e.m=t,e.c=n,e.d=function(t,n,o){e.o(t,n)||Object.defineProperty(t,n,{configurable:!1,enumerable:!0,get:o})},e.n=function(t){var n=t&&t.__esModule?function(){return t.default}:function(){return t};return e.d(n,"a",n),n},e.o=function(t,e){return Object.prototype.hasOwnProperty.call(t,e)},e.p="",e(e.s=8)}([function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o="swal-button";e.CLASS_NAMES={MODAL:"swal-modal",OVERLAY:"swal-overlay",SHOW_MODAL:"swal-overlay--show-modal",MODAL_TITLE:"swal-title",MODAL_TEXT:"swal-text",ICON:"swal-icon",ICON_CUSTOM:"swal-icon--custom",CONTENT:"swal-content",FOOTER:"swal-footer",BUTTON_CONTAINER:"swal-button-container",BUTTON:o,CONFIRM_BUTTON:o+"--confirm",CANCEL_BUTTON:o+"--cancel",DANGER_BUTTON:o+"--danger",BUTTON_LOADING:o+"--loading",BUTTON_LOADER:o+"__loader"},e.default=e.CLASS_NAMES},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0}),e.getNode=function(t){var e="."+t;return document.querySelector(e)},e.stringToNode=function(t){var e=document.createElement("div");return e.innerHTML=t.trim(),e.firstChild},e.insertAfter=function(t,e){var n=e.nextSibling;e.parentNode.insertBefore(t,n)},e.removeNode=function(t){t.parentElement.removeChild(t)},e.throwErr=function(t){throw t=t.replace(/ +(?= )/g,""),"SweetAlert: "+(t=t.trim())},e.isPlainObject=function(t){if("[object Object]"!==Object.prototype.toString.call(t))return!1;var e=Object.getPrototypeOf(t);return null===e||e===Object.prototype},e.ordinalSuffixOf=function(t){var e=t%10,n=t%100;return 1===e&&11!==n?t+"st":2===e&&12!==n?t+"nd":3===e&&13!==n?t+"rd":t+"th"}},function(t,e,n){"use strict";function o(t){for(var n in t)e.hasOwnProperty(n)||(e[n]=t[n])}Object.defineProperty(e,"__esModule",{value:!0}),o(n(25));var r=n(26);e.overlayMarkup=r.default,o(n(27)),o(n(28)),o(n(29));var i=n(0),a=i.default.MODAL_TITLE,s=i.default.MODAL_TEXT,c=i.default.ICON,l=i.default.FOOTER;e.iconMarkup='\n
',e.titleMarkup='\n
\n',e.textMarkup='\n
',e.footerMarkup='\n
\n'},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(1);e.CONFIRM_KEY="confirm",e.CANCEL_KEY="cancel";var r={visible:!0,text:null,value:null,className:"",closeModal:!0},i=Object.assign({},r,{visible:!1,text:"Cancel",value:null}),a=Object.assign({},r,{text:"OK",value:!0});e.defaultButtonList={cancel:i,confirm:a};var s=function(t){switch(t){case e.CONFIRM_KEY:return a;case e.CANCEL_KEY:return i;default:var n=t.charAt(0).toUpperCase()+t.slice(1);return Object.assign({},r,{text:n,value:t})}},c=function(t,e){var n=s(t);return!0===e?Object.assign({},n,{visible:!0}):"string"==typeof e?Object.assign({},n,{visible:!0,text:e}):o.isPlainObject(e)?Object.assign({visible:!0},n,e):Object.assign({},n,{visible:!1})},l=function(t){for(var e={},n=0,o=Object.keys(t);n=0&&w.splice(e,1)}function s(t){var e=document.createElement("style");return t.attrs.type="text/css",l(e,t.attrs),i(t,e),e}function c(t){var e=document.createElement("link");return t.attrs.type="text/css",t.attrs.rel="stylesheet",l(e,t.attrs),i(t,e),e}function l(t,e){Object.keys(e).forEach(function(n){t.setAttribute(n,e[n])})}function u(t,e){var n,o,r,i;if(e.transform&&t.css){if(!(i=e.transform(t.css)))return function(){};t.css=i}if(e.singleton){var l=h++;n=g||(g=s(e)),o=f.bind(null,n,l,!1),r=f.bind(null,n,l,!0)}else t.sourceMap&&"function"==typeof URL&&"function"==typeof URL.createObjectURL&&"function"==typeof URL.revokeObjectURL&&"function"==typeof Blob&&"function"==typeof btoa?(n=c(e),o=p.bind(null,n,e),r=function(){a(n),n.href&&URL.revokeObjectURL(n.href)}):(n=s(e),o=d.bind(null,n),r=function(){a(n)});return o(t),function(e){if(e){if(e.css===t.css&&e.media===t.media&&e.sourceMap===t.sourceMap)return;o(t=e)}else r()}}function f(t,e,n,o){var r=n?"":o.css;if(t.styleSheet)t.styleSheet.cssText=x(e,r);else{var i=document.createTextNode(r),a=t.childNodes;a[e]&&t.removeChild(a[e]),a.length?t.insertBefore(i,a[e]):t.appendChild(i)}}function d(t,e){var n=e.css,o=e.media;if(o&&t.setAttribute("media",o),t.styleSheet)t.styleSheet.cssText=n;else{for(;t.firstChild;)t.removeChild(t.firstChild);t.appendChild(document.createTextNode(n))}}function p(t,e,n){var o=n.css,r=n.sourceMap,i=void 0===e.convertToAbsoluteUrls&&r;(e.convertToAbsoluteUrls||i)&&(o=y(o)),r&&(o+="\n/*# sourceMappingURL=data:application/json;base64,"+btoa(unescape(encodeURIComponent(JSON.stringify(r))))+" */");var a=new Blob([o],{type:"text/css"}),s=t.href;t.href=URL.createObjectURL(a),s&&URL.revokeObjectURL(s)}var m={},b=function(t){var e;return function(){return void 0===e&&(e=t.apply(this,arguments)),e}}(function(){return window&&document&&document.all&&!window.atob}),v=function(t){var e={};return function(n){return void 0===e[n]&&(e[n]=t.call(this,n)),e[n]}}(function(t){return document.querySelector(t)}),g=null,h=0,w=[],y=n(15);t.exports=function(t,e){if("undefined"!=typeof DEBUG&&DEBUG&&"object"!=typeof document)throw new Error("The style-loader cannot be used in a non-browser environment");e=e||{},e.attrs="object"==typeof e.attrs?e.attrs:{},e.singleton||(e.singleton=b()),e.insertInto||(e.insertInto="head"),e.insertAt||(e.insertAt="bottom");var n=r(t,e);return o(n,e),function(t){for(var i=[],a=0;athis.length)&&-1!==this.indexOf(t,e)}),Array.prototype.includes||Object.defineProperty(Array.prototype,"includes",{value:function(t,e){if(null==this)throw new TypeError('"this" is null or not defined');var n=Object(this),o=n.length>>>0;if(0===o)return!1;for(var r=0|e,i=Math.max(r>=0?r:o-Math.abs(r),0);i=0&&(t._idleTimeoutId=setTimeout(function(){t._onTimeout&&t._onTimeout()},e))},n(19),e.setImmediate=setImmediate,e.clearImmediate=clearImmediate},function(t,e,n){(function(t,e){!function(t,n){"use strict";function o(t){"function"!=typeof t&&(t=new Function(""+t));for(var e=new Array(arguments.length-1),n=0;n1)for(var n=1;n',e.default=e.modalMarkup},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(0),r=o.default.OVERLAY,i='
\n
';e.default=i},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(0),r=o.default.ICON;e.errorIconMarkup=function(){var t=r+"--error",e=t+"__line";return'\n
\n \n \n
\n '},e.warningIconMarkup=function(){var t=r+"--warning";return'\n \n \n \n '},e.successIconMarkup=function(){var t=r+"--success";return'\n \n \n\n
\n
\n '}},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(0),r=o.default.CONTENT;e.contentMarkup='\n
\n\n
\n'},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(0),r=o.default.BUTTON_CONTAINER,i=o.default.BUTTON,a=o.default.BUTTON_LOADER;e.buttonMarkup='\n
\n\n \n\n
\n
\n
\n
\n
\n\n
\n'},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(4),r=n(2),i=n(0),a=i.default.ICON,s=i.default.ICON_CUSTOM,c=["error","warning","success","info"],l={error:r.errorIconMarkup(),warning:r.warningIconMarkup(),success:r.successIconMarkup()},u=function(t,e){var n=a+"--"+t;e.classList.add(n);var o=l[t];o&&(e.innerHTML=o)},f=function(t,e){e.classList.add(s);var n=document.createElement("img");n.src=t,e.appendChild(n)},d=function(t){if(t){var e=o.injectElIntoModal(r.iconMarkup);c.includes(t)?u(t,e):f(t,e)}};e.default=d},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(2),r=n(4),i=function(t){navigator.userAgent.includes("AppleWebKit")&&(t.style.display="none",t.offsetHeight,t.style.display="")};e.initTitle=function(t){if(t){var e=r.injectElIntoModal(o.titleMarkup);e.textContent=t,i(e)}},e.initText=function(t){if(t){var e=document.createDocumentFragment();t.split("\n").forEach(function(t,n,o){e.appendChild(document.createTextNode(t)),n0}).forEach(function(t){b.classList.add(t)})}n&&t===c.CONFIRM_KEY&&b.classList.add(s),b.textContent=r;var g={};return g[t]=i,f.setActionValue(g),f.setActionOptionsFor(t,{closeModal:p}),b.addEventListener("click",function(){return u.onAction(t)}),m},p=function(t,e){var n=r.injectElIntoModal(l.footerMarkup);for(var o in t){var i=t[o],a=d(o,i,e);i.visible&&n.appendChild(a)}0===n.children.length&&n.remove()};e.default=p},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(3),r=n(4),i=n(2),a=n(5),s=n(6),c=n(0),l=c.default.CONTENT,u=function(t){t.addEventListener("input",function(t){var e=t.target,n=e.value;a.setActionValue(n)}),t.addEventListener("keyup",function(t){if("Enter"===t.key)return s.onAction(o.CONFIRM_KEY)}),setTimeout(function(){t.focus(),a.setActionValue("")},0)},f=function(t,e,n){var o=document.createElement(e),r=l+"__"+e;o.classList.add(r);for(var i in n){var a=n[i];o[i]=a}"input"===e&&u(o),t.appendChild(o)},d=function(t){if(t){var e=r.injectElIntoModal(i.contentMarkup),n=t.element,o=t.attributes;"string"==typeof n?f(e,n,o):e.appendChild(n)}};e.default=d},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(1),r=n(2),i=function(){var t=o.stringToNode(r.overlayMarkup);document.body.appendChild(t)};e.default=i},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(5),r=n(6),i=n(1),a=n(3),s=n(0),c=s.default.MODAL,l=s.default.BUTTON,u=s.default.OVERLAY,f=function(t){t.preventDefault(),v()},d=function(t){t.preventDefault(),g()},p=function(t){if(o.default.isOpen)switch(t.key){case"Escape":return r.onAction(a.CANCEL_KEY)}},m=function(t){if(o.default.isOpen)switch(t.key){case"Tab":return f(t)}},b=function(t){if(o.default.isOpen)return"Tab"===t.key&&t.shiftKey?d(t):void 0},v=function(){var t=i.getNode(l);t&&(t.tabIndex=0,t.focus())},g=function(){var t=i.getNode(c),e=t.querySelectorAll("."+l),n=e.length-1,o=e[n];o&&o.focus()},h=function(t){t[t.length-1].addEventListener("keydown",m)},w=function(t){t[0].addEventListener("keydown",b)},y=function(){var t=i.getNode(c),e=t.querySelectorAll("."+l);e.length&&(h(e),w(e))},x=function(t){if(i.getNode(u)===t.target)return r.onAction(a.CANCEL_KEY)},_=function(t){var e=i.getNode(u);e.removeEventListener("click",x),t&&e.addEventListener("click",x)},k=function(t){o.default.timer&&clearTimeout(o.default.timer),t&&(o.default.timer=window.setTimeout(function(){return r.onAction(a.CANCEL_KEY)},t))},O=function(t){t.closeOnEsc?document.addEventListener("keyup",p):document.removeEventListener("keyup",p),t.dangerMode?v():g(),y(),_(t.closeOnClickOutside),k(t.timer)};e.default=O},function(t,e,n){"use strict";Object.defineProperty(e,"__esModule",{value:!0});var o=n(1),r=n(3),i=n(37),a=n(38),s={title:null,text:null,icon:null,buttons:r.defaultButtonList,content:null,className:null,closeOnClickOutside:!0,closeOnEsc:!0,dangerMode:!1,timer:null},c=Object.assign({},s);e.setDefaults=function(t){c=Object.assign({},s,t)};var l=function(t){var e=t&&t.button,n=t&&t.buttons;return void 0!==e&&void 0!==n&&o.throwErr("Cannot set both 'button' and 'buttons' options!"),void 0!==e?{confirm:e}:n},u=function(t){return o.ordinalSuffixOf(t+1)},f=function(t,e){o.throwErr(u(e)+" argument ('"+t+"') is invalid")},d=function(t,e){var n=t+1,r=e[n];o.isPlainObject(r)||void 0===r||o.throwErr("Expected "+u(n)+" argument ('"+r+"') to be a plain object")},p=function(t,e){var n=t+1,r=e[n];void 0!==r&&o.throwErr("Unexpected "+u(n)+" argument ("+r+")")},m=function(t,e,n,r){var i=typeof e,a="string"===i,s=e instanceof Element;if(a){if(0===n)return{text:e};if(1===n)return{text:e,title:r[0]};if(2===n)return d(n,r),{icon:e};f(e,n)}else{if(s&&0===n)return d(n,r),{content:e};if(o.isPlainObject(e))return p(n,r),e;f(e,n)}};e.getOpts=function(){for(var t=[],e=0;e