diff --git a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md
new file mode 100644
index 0000000000000..29a32d2d053ea
--- /dev/null
+++ b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -0,0 +1,334 @@
+---
+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 (workflow) d'initialisation {#init-workflow}
+`kubeadm init` assemble un noeud Kubernetes control-plane en effectuant les étapes suivantes :
+
+1. Exécute une série de validations pour valider l'état du système avant d'y apporter des changements.
+   Certains validations ne peuvent juste qu'émettre 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-of-errors>`.
+
+1. Génère une autorité de certification (CA) auto signée (ou utilise une existante si spécifiée) pour
+   installer les identités de chaque composant du cluster. Si l'utilisateur a fourni son propre certificat 
+   et/ou clef de CA en le(la) copiant dans le répertoire des certificats, configuré avec  `--cert-dir`
+   (`/etc/kubernetes/pki` par défaut) cette étape est sautée comme expliqué dans le document
+   [Utiliser ses propres certificats](#custom-certificates).
+   Les certificats de l'APIServer auront des entrées SAN additionnelles pour chaque argument `--apiserver-cert-extra-sans` , en minuscule au besoin.
+
+1. Ecrit les fichiers kubeconfig dans `/etc/kubernetes/` pour la
+   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/manifests`; 
+   la 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 workload additionnelle ne s'y exécutent.
+
+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 [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.
+   Poiur 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`.
+   Remarque : bien que le serveur DNS soit déployé, il ne sera pas programmé pour exécution avant que CNI soit installé.
+
+### Using init phases with kubeadm {#init-phases}
+
+Kubeadm allows you create a control-plane node in phases. In 1.13 the `kubeadm init phase` command has graduated to GA from it’s previous alpha state under `kubeadm alpha phase`.
+
+To view the ordered list of phases and sub-phases you can call `kubeadm init --help`. The list will be located at the top of the help screen and each phase will have a description next to it.
+Note that by calling `kubeadm init` all of the phases and sub-phases will be executed in this exact order.
+
+Some phases have unique flags, so if you want to have a look at the list of available options add `--help`, for example:
+
+```shell
+sudo kubeadm init phase control-plane controller-manager --help
+```
+
+You can also use `--help` to see the list of sub-phases for a certain parent phase:
+
+```shell
+sudo kubeadm init phase control-plane --help
+```
+
+`kubeadm init` also expose a flag called `--skip-phases` that can be used to skip certain phases. The flag accepts a list of phase names and the names can be taken from the above ordered list.
+
+An example:
+
+```shell
+sudo kubeadm init phase control-plane all --config=configfile.yaml
+sudo kubeadm init phase etcd local --config=configfile.yaml
+# you can now modify the control plane and etcd manifest files
+sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml
+```
+
+What this example would do is write the manifest files for the control plane and etcd in `/etc/kubernetes/manifests` based on the configuration in `configfile.yaml`. This allows you to modify the files and then skip these phases using `--skip-phases`. By calling the last command you will create a control plane node with the custom manifest files.
+
+### Using kubeadm init with a configuration file {#config-file}
+
+{{< caution >}}
+The config file is still considered beta and may change in future versions.
+{{< /caution >}}
+
+It's possible to configure `kubeadm init` with a configuration file instead of command
+line flags, and some more advanced features may only be available as
+configuration file options. This file is passed in the `--config` option.
+
+In Kubernetes 1.11 and later, the default configuration can be printed out using the
+[kubeadm config print](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
+
+It is **recommended** that you migrate your old `v1alpha3` configuration to `v1beta1` using
+the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command,
+because `v1alpha3` will be removed in Kubernetes 1.15.
+
+For more details on each field in the `v1beta1` configuration you can navigate to our
+[API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta1).
+
+### Adding kube-proxy parameters {#kube-proxy}
+
+For information about kube-proxy parameters in the kubeadm configuration see:
+- [kube-proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration)
+
+For information about enabling IPVS mode with kubeadm see:
+- [IPVS](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/README.md)
+
+### Passing custom flags to control plane components {#control-plane-flags}
+
+For information about passing flags to control plane components see:
+- [control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
+
+### Using custom images {#custom-images}
+
+By default, kubeadm pulls images from `k8s.gcr.io`, unless
+the requested Kubernetes version is a CI version. In this case,
+`gcr.io/kubernetes-ci-images` is used.
+
+You can override this behavior by using [kubeadm with a configuration file](#config-file).
+Allowed customization are:
+
+* To provide an alternative `imageRepository` to be used instead of
+  `k8s.gcr.io`.
+* To set `useHyperKubeImage` to `true` to use the HyperKube image.
+* To provide a specific `imageRepository` and `imageTag` for etcd or DNS add-on.
+
+Please note that the configuration field `kubernetesVersion` or the command line flag
+`--kubernetes-version` affect the version of the images.
+
+### Using custom certificates {#custom-certificates}
+
+By default, kubeadm generates all the certificates needed for a cluster to run.
+You can override this behavior by providing your own certificates.
+
+To do so, you must place them in whatever directory is specified by the
+`--cert-dir` flag or `CertificatesDir` configuration file key. By default this
+is `/etc/kubernetes/pki`.
+
+If a given certificate and private key pair exists, kubeadm skips the
+generation step and existing files are used for the prescribed
+use case. This means you can, for example, copy an existing CA into `/etc/kubernetes/pki/ca.crt`
+and `/etc/kubernetes/pki/ca.key`, and kubeadm will use this CA for signing the rest
+of the certs.
+
+#### External CA mode {#external-ca-mode}
+
+It is also possible to provide just the `ca.crt` file and not the
+`ca.key` file (this is only available for the root CA file, not other cert pairs).
+If all other certificates and kubeconfig files are in place, kubeadm recognizes
+this condition and activates the "External CA" mode. kubeadm will proceed without the
+CA key on disk.
+
+Instead, run the controller-manager standalone with `--controllers=csrsigner` and
+point to the CA certificate and key.
+
+### Managing the kubeadm drop-in file for the kubelet {#kubelet-drop-in}
+
+The kubeadm package ships with configuration for how the kubelet should
+be run. Note that the `kubeadm` CLI command never touches this drop-in file.
+This drop-in file belongs to the kubeadm deb/rpm package.
+
+To find out more about how kubeadm manages the kubelet have a look at
+[this page](/docs/setup/independent/kubelet-integration).
+
+### Use kubeadm with CRI runtimes
+
+Since v1.6.0, Kubernetes has enabled the use of CRI, Container Runtime Interface, by default.
+The container runtime used by default is Docker, which is enabled through the built-in
+`dockershim` CRI implementation inside of the `kubelet`.
+
+Other CRI-based runtimes include:
+
+- [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)
+
+Refer to the [CRI installation instructions](/docs/setup/cri) for more information.
+
+After you have successfully installed `kubeadm` and `kubelet`, execute
+these two additional steps:
+
+1. Install the runtime shim on every node, following the installation
+   document in the runtime shim project listing above.
+
+1. Configure kubelet to use the remote CRI runtime. Please remember to change
+   `RUNTIME_ENDPOINT` to your own value like `/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
+```
+
+Now `kubelet` is ready to use the specified CRI runtime, and you can continue
+with the `kubeadm init` and `kubeadm join` workflow to deploy Kubernetes cluster.
+
+You may also want to set `--cri-socket` to `kubeadm init` and `kubeadm reset` when
+using an external CRI implementation.
+
+### Setting the node name
+
+By default, `kubeadm` assigns a node name based on a machine's host address. You can override this setting with the `--node-name`flag.
+The flag passes the appropriate [`--hostname-override`](/docs/reference/command-line-tools-reference/kubelet/#options)
+to the kubelet.
+
+Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
+
+### Self-hosting the Kubernetes control plane {#self-hosting}
+
+As of 1.8, you can experimentally create a _self-hosted_ Kubernetes control
+plane. This means that key components such as the API server, controller
+manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
+configured via the Kubernetes API instead of [static pods](/docs/tasks/administer-cluster/static-pod/)
+configured in the kubelet via static files.
+
+To create a self-hosted cluster see the `kubeadm alpha selfhosting` command.
+
+#### Caveats
+
+1. Self-hosting in 1.8 and later has some important limitations. In particular, a
+  self-hosted cluster _cannot recover from a reboot of the control-plane node_
+  without manual intervention.
+
+1. A self-hosted cluster is not upgradeable using `kubeadm upgrade`.
+
+1. By default, self-hosted control plane Pods rely on credentials loaded from
+  [`hostPath`](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
+  volumes. Except for initial creation, these credentials are not managed by
+  kubeadm.
+
+1. The self-hosted portion of the control plane does not include etcd,
+  which still runs as a static Pod.
+
+#### Process
+
+The self-hosting bootstrap process is documented in the [kubeadm design
+document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting).
+
+In summary, `kubeadm alpha selfhosting` works as follows:
+
+  1. Waits for this bootstrap static control plane to be running and
+    healthy. This is identical to the `kubeadm init` process without self-hosting.
+
+  1. Uses the static control plane Pod manifests to construct a set of
+    DaemonSet manifests that will run the self-hosted control plane.
+    It also modifies these manifests where necessary, for example adding new volumes
+    for secrets.
+
+  1. Creates DaemonSets in the `kube-system` namespace and waits for the
+     resulting Pods to be running.
+
+  1. Once self-hosted Pods are operational, their associated static Pods are deleted
+     and kubeadm moves on to install the next component. This triggers kubelet to
+     stop those static Pods.
+
+  1. When the original static control plane stops, the new self-hosted control
+    plane is able to bind to listening ports and become active.
+
+### Running kubeadm without an internet connection
+
+For running kubeadm without an internet connection you have to pre-pull the required control-plane images.
+
+In Kubernetes 1.11 and later, you can list and pull the images using the `kubeadm config images` sub-command:
+
+```shell
+kubeadm config images list
+kubeadm config images pull
+```
+
+In Kubernetes 1.12 and later, the `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` images
+don't require an `-${ARCH}` suffix.
+
+### Automating kubeadm
+
+Rather than copying the token you obtained from `kubeadm init` to each node, as
+in the [basic kubeadm tutorial](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), you can parallelize the
+token distribution for easier automation. To implement this automation, you must
+know the IP address that the control-plane node will have after it is started.
+
+1.  Generate a token. This token must have the form  `<6 character string>.<16
+    character string>`.  More formally, it must match the regex:
+    `[a-z0-9]{6}\.[a-z0-9]{16}`.
+
+    kubeadm can generate a token for you:
+
+    ```shell
+    kubeadm token generate
+    ```
+
+1. Start both the control-plane node and the worker nodes concurrently with this token.
+   As they come up they should find each other and form the cluster.  The same
+   `--token` argument can be used on both `kubeadm init` and `kubeadm join`.
+
+Once the cluster is up, you can grab the admin credentials from the control-plane node
+at `/etc/kubernetes/admin.conf` and use that to talk to the cluster.
+
+Note that this style of bootstrap has some relaxed security guarantees because
+it does not allow the root CA hash to be validated with
+`--discovery-token-ca-cert-hash` (since it's not generated when the nodes are
+provisioned). For details, see the [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/).
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+* [kubeadm init phase](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) to understand more about
+`kubeadm init` phases
+* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/) to bootstrap a Kubernetes worker node and join it to the cluster
+* [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/) to upgrade a Kubernetes cluster to a newer version
+* [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) to revert any changes made to this host by `kubeadm init` or `kubeadm join`
+{{% /capture %}}