Merge pull request #16039 from simplytunde/merged-master-dev-1.16
Merged master into dev-1.16
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
a8a811479c
4
OWNERS
4
OWNERS
|
|
@ -6,5 +6,9 @@ reviewers:
|
|||
approvers:
|
||||
- sig-docs-en-owners # Defined in OWNERS_ALIASES
|
||||
|
||||
emeritus_approvers:
|
||||
- chenopis
|
||||
- jaredbhatti
|
||||
|
||||
labels:
|
||||
- sig/docs
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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: {}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ reviewers:
|
|||
- dchen1107
|
||||
- roberthbailey
|
||||
- liggitt
|
||||
title: Master-Node communication
|
||||
title: Master-Node Communication
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
---
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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-<accountName>-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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -215,6 +215,11 @@ Use the following commands to install Containerd on your system:
|
|||
### Prerequisites
|
||||
|
||||
```shell
|
||||
cat > /etc/modules-load.d/containerd.conf <<EOF
|
||||
overlay
|
||||
br_netfilter
|
||||
EOF
|
||||
|
||||
modprobe overlay
|
||||
modprobe br_netfilter
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 109 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
|
|
@ -94,10 +94,9 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
|
|||
|
||||
1. In the `net-conf.json` section of your `kube-flannel.yml`, double-check:
|
||||
1. The cluster subnet (e.g. "10.244.0.0/16") is set as per your IP plan.
|
||||
* VNI 4096 is set in the backend
|
||||
* Port 4789 is set in the backend
|
||||
2. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
|
||||
|
||||
* VNI 4096 is set in the backend
|
||||
* Port 4789 is set in the backend
|
||||
1. In the `cni-conf.json` section of your `kube-flannel.yml`, change the network name to `vxlan0`.
|
||||
|
||||
Your `cni-conf.json` should look as follows:
|
||||
|
||||
|
|
@ -143,7 +142,18 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
|
|||
kubectl get pods --all-namespaces
|
||||
```
|
||||
|
||||
|
||||
The output looks like as follows:
|
||||
|
||||
```
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
kube-system etcd-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-apiserver-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-controller-manager-flannel-master 1/1 Running 0 1m
|
||||
kube-system kube-dns-86f4d74b45-hcx8x 3/3 Running 0 12m
|
||||
kube-system kube-flannel-ds-54954 1/1 Running 0 1m
|
||||
kube-system kube-proxy-Zjlxz 1/1 Running 0 1m
|
||||
kube-system kube-scheduler-flannel-master 1/1 Running 0 1m
|
||||
```
|
||||
|
||||
Verify that the Flannel DaemonSet has the NodeSelector applied.
|
||||
|
||||
|
|
@ -151,13 +161,20 @@ Once you have a Linux-based Kubernetes master node you are ready to choose a net
|
|||
kubectl get ds -n kube-system
|
||||
```
|
||||
|
||||
|
||||
The output looks like as follows. The NodeSelector `beta.kubernetes.io/os=linux` is applied.
|
||||
|
||||
```
|
||||
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
|
||||
kube-flannel-ds 2 2 2 2 2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux 21d
|
||||
kube-proxy 2 2 2 2 2 beta.kubernetes.io/os=linux 26d
|
||||
```
|
||||
|
||||
#### Join Windows Worker
|
||||
|
||||
In this section we'll cover configuring a Windows node from scratch to join a cluster on-prem. If your cluster is on a cloud you'll likely want to follow the cloud specific guides in the next section.
|
||||
|
||||
#### Preparing a Windows Node
|
||||
|
||||
{{< note >}}
|
||||
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.
|
||||
|
||||
|
||||
```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 <Windows Node IP> -NetworkMode overlay -ClusterCIDR <Cluster CIDR> -ServiceCIDR <Service CIDR> -KubeDnsServiceIP <Kube-dns Service IP> -LogDir <Log directory>
|
||||
cd c:\k
|
||||
.\start.ps1 -ManagementIP <Windows Node IP> `
|
||||
-NetworkMode overlay `
|
||||
-ClusterCIDR <Cluster CIDR> `
|
||||
-ServiceCIDR <Service CIDR> `
|
||||
-KubeDnsServiceIP <Kube-dns Service IP> `
|
||||
-LogDir <Log directory>
|
||||
```
|
||||
|
||||
| Parameter | Default Value | Notes |
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
|
|
@ -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=<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.
|
||||
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 %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 %}}
|
||||
|
|
|
|||
|
|
@ -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}'
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
clusters:
|
||||
- cluster:
|
||||
server: http://<ip_of_falco>: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 %}}
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
[](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 %}}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ spec:
|
|||
image: k8s.gcr.io/cloud-controller-manager:v1.8.0
|
||||
command:
|
||||
- /usr/local/bin/cloud-controller-manager
|
||||
- --cloud-provider=<YOUR_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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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`.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 %}}
|
||||
|
|
|
|||
|
|
@ -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 %}}
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -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=$(<POD_NAME>)&ip=$(<POD_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 %}}
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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/)
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
La CNCF est une sous-fondation de [Linux Foundation](https://www.linuxfoundation.org/).
|
||||
Sa mission est de rendre le "cloud native computing" omniprésent.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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" >}}.
|
||||
|
|
@ -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" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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/).
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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é.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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)
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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/).
|
||||
|
||||
|
|
@ -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" >}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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">}}.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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" >}}.
|
||||
|
|
@ -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.
|
||||
|
||||
<!--more-->
|
||||
|
||||
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.
|
||||
|
|
@ -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.
|
||||
```
|
||||
|
||||
|
|
@ -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=<list-des-erreurs>`.
|
||||
|
||||
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 <<EOF
|
||||
[Service]
|
||||
Environment="KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=$RUNTIME_ENDPOINT"
|
||||
EOF
|
||||
systemctl daemon-reload
|
||||
```
|
||||
|
||||
Maintenant `kubelet` est prête à utiliser le runtime CRI spécifié, et vous pouvez reprendre la séquence de déploiement avec `kubeadm init` et `kubeadm join`pour déployer votre cluster Kubernetes.
|
||||
|
||||
Il est aussi possible de configurer `--cri-socket` à `kubeadm init` et `kubeadm reset` lorsque vous utilisez une implémentation CRI externe.
|
||||
|
||||
### Paramétrer le nom du noeud
|
||||
|
||||
Par défaut, `kubeadm` donne un nom au noeud en utilisant l'adresse de la machine. Vous pouvez outrepasser ce réglage en utilisant l'option `--node-name`.
|
||||
Cette option se chargera de passer la valeur appropriée pour [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options) à kubelet.
|
||||
|
||||
Faîtes attention car forcer un nom d'hôte peut [interférer avec les fournisseurs de cloud](https://github.com/kubernetes/website/pull/8873).
|
||||
|
||||
### Héberger soi même le control plane Kubernetes {#self-hosting}
|
||||
|
||||
A partir de la version 1.8, vous pouvez expérimentalement créer un control plane Kubernetes _auto-hébergé (self-hosted)_ .
|
||||
Cela signifie que des composants clefs comme le serveur d'API, le controller manager et l'ordonnanceur sont démarrés en tant que
|
||||
[pods DaemonSet](/docs/concepts/workloads/controllers/daemonset/), configurés via l'API Kubernetes
|
||||
plutôt qu'en tant que [pods static](/docs/tasks/administer-cluster/static-pod/) configurés avec des fichiers statiques dans kubelet.
|
||||
|
||||
Pour créer un cluster auto-hébergé, se référer à la commande `kubeadm alpha selfhosting`.
|
||||
|
||||
#### Avertissements
|
||||
|
||||
1. L'auto-hébergement dans la version 1.8 et au delà comporte de sérieuses limitations.
|
||||
En particulier, un cluster auto-hébergé _ne peut pas survivre au redémarrage du noeud control plane_ sans intervention manuelle.
|
||||
|
||||
1. Un cluster auto-hébergé ne peut pas être mis à jour via la commande `kubeadm upgrade`.
|
||||
|
||||
1. Par défaut, les Pods d'un control plane auto-hébergé dépendent des identifiants chargés depuis des volumes de type
|
||||
[`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
|
||||
A part pour la création initiale, ces identifiants ne sont pas gérés par kubeadm.
|
||||
|
||||
1. La partie auto-hébergée du control plane n'inclut pas etcd,
|
||||
qui fonctionne toujours en tant que Pod statique.
|
||||
|
||||
#### Procédé
|
||||
|
||||
Le procédé de démarrage auto-hébergé est documenté dans le [document de conception de kubeadm](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
|
||||
|
||||
En bref, `kubeadm alpha selfhosting` fonctionne de la manière suivante :
|
||||
|
||||
1. Attend que le control plane statique soit démarré correctement. C'est la même chose que le procédé `kubeadm init` lorsque non auto-hébergé.
|
||||
|
||||
1. Utilise les manifestes du Pod statique du control plane pour construire un ensemble de manifestes DaemonSet qui vont lancer le control plane auto-hébergé.
|
||||
Cela modifie aussi les manifestes si nécessaires, par example pour ajouter des nouveaux volumes pour des secrets.
|
||||
|
||||
1. Crée des DaemonSets dans le namespace `kube-system` et attend que les pods ainsi créés soient démarrés.
|
||||
|
||||
1. Une fois que les Pods auto-hébergés sont opérationnels, les Pods statiques qui leurs sont associés sont supprimés et kubeadm installe ensuite le prochain composant.
|
||||
Cela déclenche l'arrêt par kubelet de ces Pods statiques.
|
||||
|
||||
1. Quand le control plane statique d'origine s'arrête, le nouveau control plane auto-hébergé est capable d'écouter sur les mêmes ports et devenir actif.
|
||||
|
||||
### Utiliser kubeadm sans connexion internet
|
||||
|
||||
Pour utiliser kubeadm sans connexion internet, vous devez télécharger les images requises par le control plane à l'avance.
|
||||
|
||||
A partir de Kubernetes 1.11, vous pouvez lister et télécharger les images en utilisant les sous commandes à `kubeadm config images` :
|
||||
|
||||
```shell
|
||||
kubeadm config images list
|
||||
kubeadm config images pull
|
||||
```
|
||||
|
||||
A partir de Kubernetes 1.12, les images prefixées par `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` et `k8s.gcr.io/pause`
|
||||
ne nécessitent pas un suffix `-${ARCH}`.
|
||||
|
||||
### Automatiser kubeadm
|
||||
|
||||
Plutôt que copier sur chaque noeud le jeton que vous avez obtenu avec `kubeadm init`, comme décrit dans
|
||||
le [tutoriel basique de kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), vous pouvez paralléliser la distribution du jeton afin d'automatiser cette tâche.
|
||||
Pour ce faire, vous devez connaître l'adresse IP que le noeud control plane obtiendra après son démarrage.
|
||||
|
||||
1. Générer un jeton. Ce jeton doit avoir correspondre à la chaîne suivante : `<6 caractères>.<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 %}}
|
||||
|
|
@ -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 %}}
|
||||
|
|
@ -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 %}}
|
||||
|
|
@ -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 <none> 1d v1.13.0
|
||||
worker1 Ready <none> 1d v1.13.0
|
||||
worker2 Ready <none> 1d v1.13.0
|
||||
```
|
||||
2. Choisissez l'un de vos nœuds et ajoutez-y un label :
|
||||
|
||||
```shell
|
||||
kubectl label nodes <your-node-name> disktype=ssd
|
||||
```
|
||||
|
||||
où `<your-node-name>` 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 <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0
|
||||
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
|
||||
worker2 Ready <none> 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 %}}
|
||||
|
||||
|
|
@ -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=<YOUR_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: ""
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -138,7 +138,7 @@ Kontroler node memeriksa <i>state</i> masing-masing node untuk durasi yang diten
|
|||
|
||||
Pada versi Kubernetes sebelum 1.13, `NodeStatus` adalah <i>heartbeat</i> yang diberikan oleh node.
|
||||
Setelah versi 1.13, fitur <i>node lease</i> 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 <i>node lease</i> diaktifasi, setiap node terhubung dengan obyek `Lease` di dalam <i>namespace</i> `kube-node-lease` yang terus diperbarui secara berkala.
|
||||
Kemudian, `NodeStatus` dan <i>node lease</i> keduanya dijadikan sebagai <i>heartbeat</i> dari node.
|
||||
Semua <i>node lease</i> diperbarui sesering mungkin, sedangkan `NodeStatus` dilaporkan dari node untuk master hanya ketika ada perubahan atau telah melewati periode waktu tertentu (<i>default</i>-nya 1 menit, lebih lama daripada <i>default timeout</i> node-node yang terputus jaringannya).
|
||||
|
|
|
|||
|
|
@ -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. `<MASTER_IP>`)
|
||||
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 = <country>
|
||||
ST = <state>
|
||||
L = <city>
|
||||
O = <organization>
|
||||
OU = <organization unit>
|
||||
CN = <MASTER_IP>
|
||||
|
||||
[ 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 = <MASTER_IP>
|
||||
IP.2 = <MASTER_CLUSTER_IP>
|
||||
|
||||
[ 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": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
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",
|
||||
"<MASTER_IP>",
|
||||
"<MASTER_CLUSTER_IP>",
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
"kubernetes.default.svc.cluster",
|
||||
"kubernetes.default.svc.cluster.local"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
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 %}}
|
||||
|
|
@ -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 %}}
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ weight: 10
|
|||
<h3>目標</h3>
|
||||
<ul>
|
||||
<li>アプリケーションのデプロイについて学ぶ</li>
|
||||
<li>kubectlを使って、Kubenretes上にはじめてのアプリケーションをデプロイする</li>
|
||||
<li>kubectlを使って、Kubernetes上にはじめてのアプリケーションをデプロイする</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -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를 시작으로, 노드 컨트롤러는 파드 축출에 대한 결정을 내릴 경우 클러스터 내 모든 노드를 살핀다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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, `<MASTER_IP>`) 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 = <country>
|
||||
ST = <state>
|
||||
L = <city>
|
||||
O = <organization>
|
||||
OU = <organization unit>
|
||||
CN = <MASTER_IP>
|
||||
|
||||
[ 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 = <MASTER_IP>
|
||||
IP.2 = <MASTER_CLUSTER_IP>
|
||||
|
||||
[ 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": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
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",
|
||||
"<MASTER_IP>",
|
||||
"<MASTER_CLUSTER_IP>",
|
||||
"kubernetes",
|
||||
"kubernetes.default",
|
||||
"kubernetes.default.svc",
|
||||
"kubernetes.default.svc.cluster",
|
||||
"kubernetes.default.svc.cluster.local"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [{
|
||||
"C": "<country>",
|
||||
"ST": "<state>",
|
||||
"L": "<city>",
|
||||
"O": "<organization>",
|
||||
"OU": "<organization unit>"
|
||||
}]
|
||||
}
|
||||
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 %}}
|
||||
|
|
@ -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 %}}
|
||||
|
||||
|
||||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -20,15 +20,15 @@
|
|||
<div class="widget-content">
|
||||
{{ with site.Home.OutputFormats.Get "rss" -}}
|
||||
<link rel="{{ .Rel }}" type="{{ .MediaType.Type }}" href="{{ .Permalink | safeURL }}" title="{{ site.Title }}">
|
||||
<a class="widget-link" href="{{ .Permalink | safeURL }}"> <i class="fas fa-rss fab-icon"> </i> RSS Feed </a>
|
||||
<a class="widget-link" href="{{ .Permalink | safeURL }}"><div> <i class="fas fa-rss fab-icon"> </i> <div class="widget-link-text">RSS Feed</div></div> </a>
|
||||
{{ end -}}
|
||||
<a class="widget-link" href="https://kubernetes.io/docs/contribute/start/#write-a-blog-post"><i class="fa fa-edit fab-icon"></i> Submit a Post</a>
|
||||
<a class="widget-link" href="https://twitter.com/kubernetesio"> <i class="fab fa-twitter-square fab-icon"> </i> @Kubernetesio</a>
|
||||
<a class="widget-link" href="https://github.com/kubernetes/kubernetes"> <i class="fab fa-github-square fab-icon"></i> View on GitHub </a>
|
||||
<a class="widget-link" href="http://slack.k8s.io"><i class="fab fa-slack fab-icon"> </i> #kubernetes-users </a>
|
||||
<a class="widget-link" href="https://stackoverflow.com/questions/tagged/kubernetes"><i class="fab fa-stack-overflow fab-icon"></i> Stack Overflow</a>
|
||||
<a class="widget-link" href="https://discuss.kubernetes.io"><i class="fab fa-discourse fab-icon"></i>Forum</a>
|
||||
<a class="widget-link" href="https://kubernetes.io/docs/setup"><i class="fa fa-download fab-icon"></i> Download Kubernetes</a>
|
||||
<a class="widget-link" href="https://kubernetes.io/docs/contribute/start/#write-a-blog-post"><div> <i class="fa fa-edit fab-icon"></i> <div class="widget-link-text">Submit a Post</div></div></a>
|
||||
<a class="widget-link" href="https://twitter.com/kubernetesio"><div> <i class="fab fa-twitter-square fab-icon"> </i> <div class="widget-link-text"> @Kubernetesio</div></div></a>
|
||||
<a class="widget-link" href="https://github.com/kubernetes/kubernetes"><div> <i class="fab fa-github-square fab-icon"></i> <div class="widget-link-text"> on GitHub </div></div></a>
|
||||
<a class="widget-link" href="http://slack.k8s.io"><div><i class="fab fa-slack fab-icon"> </i> <div class="widget-link-text">#kubernetes-users </div></div></a>
|
||||
<a class="widget-link" href="https://stackoverflow.com/questions/tagged/kubernetes"><div><i class="fab fa-stack-overflow fab-icon"></i> <div class="widget-link-text"> Overflow</div></div></a>
|
||||
<a class="widget-link" href="https://discuss.kubernetes.io"><div> <i class="fab fa-discourse fab-icon"></i><div class="widget-link-text"> Forum </div></div></a>
|
||||
<a class="widget-link" href="https://kubernetes.io/docs/setup"><div><i class="fa fa-download fab-icon"></i> <div class="widget-link-text"> Kubernetes</div></div></a>
|
||||
</div>
|
||||
{{ partialCached "blog/archive.html" . }}
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,6 @@
|
|||
<link rel="stylesheet" href="/css/case-study-styles.css">
|
||||
{{- end }}
|
||||
<link rel="stylesheet" href="{{ "css/jquery-ui.min.css" | relURL }}">
|
||||
<link rel="stylesheet" href="{{ "css/sweetalert.min.css" | relURL }}">
|
||||
<link rel="stylesheet" href="{{ "css/callouts.css" | relURL }}">
|
||||
<link rel="stylesheet" href="{{ "css/custom-jekyll/tags.css" | relURL }}">
|
||||
{{- if .Params.deprecated }}
|
||||
|
|
|
|||
|
|
@ -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 -}}
|
||||
|
|
|
|||
|
|
@ -37,7 +37,8 @@
|
|||
<script src="{{ "js/jquery-3.2.1.min.js" | relURL }}"></script>
|
||||
<script src="{{ "js/jquery-ui-1.12.1.min.js" | relURL }}"></script>
|
||||
<script src="{{ "js/bootstrap-4.3.1.min.js" | relURL }}"></script>
|
||||
<script src="{{ "js/sweetalert-1.1.3.min.js" | relURL }}"></script>
|
||||
<script src="{{ "js/sweetalert-2.1.2.min.js" | relURL }}"></script>
|
||||
|
||||
<script src="{{ "js/script.js" | relURL }}"></script>
|
||||
<script src="{{ "js/custom-jekyll/tags.js" | relURL }}"></script>
|
||||
{{ with .Params.js }}{{ range (split . ",") }}<script src="{{ (trim . " ") | relURL }}"></script><!-- custom js added -->
|
||||
|
|
|
|||
|
|
@ -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{
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
Binary file not shown.
|
Before Width: | Height: | Size: 204 KiB |
|
|
@ -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;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
Loading…
Reference in New Issue