Second Japanese l10n work for release-1.13 (#14465)
* Update k8s.io/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/ (#13153) * [ja] Translate Hello Minikube in tutorials (#13100) (#13161) * ja-trans: update supported-doc-versions.md (#13186) * [ja] Update /concepts/overview/what-is-kubernetes.md #13079 (#13187) * ja-trans: update expose-intro.html (#13215) * ja-trans: update expose-intro.html * ja-trans: fix broken links by linking to english pages * update deploy-intro.html (#13103) (#13208) * update deploy-intro.html (#13103) * Update content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html add /ja path Co-Authored-By: chidakiyo <chidakiyo@users.noreply.github.com> * [ja] Update /setup/release/building-from-source.md (#13095) (#13220) * ja-trans: update /ja/docs/setup/independent/control-plane-flags/ (#13228) * ja-trans: Update /setup/turnkey/azure.md (#13097) (#13224) * ja-trans: update /ja/docs/tutorials/kubernetes-basics/ (#13232) * ja-trans: update /ja/docs/tutorials/kubernetes-basics/ * ja-trans: translate card.title * ja-trans: update setup/minikube.md (#13091) (#13219) * [ja] Update content of setup/minikube.md, fixing the diff between551489f7b07d19. * [ja] Translate the content: content/ja/docs/setup/minikube.md (#13091) * Correct Katakana words, using long vowel words Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Fix typos Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Correct some changes, thanks for the FB Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * ja-trans: Update k8s.io/ja/docs/setup/pick-right-solution/ (#13094) (#13328) * ja-trans: Update the content of setup/pick-right-solution.md, only fixing the diff between551489fand7b07d19. (Not yet translating the content at the moment to only make sure fixing the diff is ok. Next commit will be actually the translation stuff) * ja-trans: Translate /ja/docs/setup/pick-right-solution.md (#13094) * Update content/ja/docs/setup/pick-right-solution.md Correct small changes based on the feedback Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Better translation and refer the Japanese document link Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Correct Japanese anchors Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * Correct translation mistakes Co-Authored-By: yukinagae <yuki.nagae1130@gmail.com> * ja: Translate /docs/home (#13366) * follow to the latest format * review * ja: fix some unnatural translation and formatting (#13367) * format * Update content/ja/docs/setup/certificates.md Co-Authored-By: inductor <kohei.ota@zozo.com> * ja-trans: Translate heading and subheading of docs/setup/version-skew-policy.md in Japanese (#13360) * copy content * remove reviewer block * Translate heading and subheading. * change translation * ja-trans: Translate heading and subheading of docs/setup/turnkey/icp.md in Japanese (#13359) * copy content * remove reviewer block * Translate heading and subheading. * ref. #13098 (#13358) * ref. #13096 (#13357) * ref. #13089 (#13353) * ref. #13087 (#13351) * ref. #13082 (#13348) * ref. #13085 (#13349) * ref. #13088 (#13352) * ref. #13090 (#13354) * ref. #13092 (#13355) * ref. #13093 (#13356) * ref. #13099 (#13361) * [ja] Translate the content: ja/docs/setup/independent/high-availability/ (#13364) * [ja] Translate the content: ja/docs/setup/independent/high-availability/ * remove redundant comma, words * Update content/ja/docs/setup/independent/high-availability.md 余分な文字を削除 Co-Authored-By: TSUDA-Kyosuke <tsuda@stmn.co.jp> * Update k8s.io/ja/docs/setup/cri/ (#13663) * fix content. * Update content/ja/docs/setup/cri.md Co-Authored-By: cstoku <cs.toku.mail@gmail.com> * Update cri.md * Update content/ja/docs/setup/cri.md Co-Authored-By: cstoku <cs.toku.mail@gmail.com> * Update content/ja/docs/setup/cri.md Co-Authored-By: cstoku <cs.toku.mail@gmail.com> * improve translation
This commit is contained in:
Takuya Tokuda
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
866b99cf72
commit
bbf3a979d4
@@ -6,6 +6,8 @@ weight: 40
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< feature-state for_k8s_version="1.12" state="stable" >}}
|
||||
|
||||
kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManager、およびSchedulerのようなコントロールプレーンの構成要素に渡されたデフォルトのフラグを上書きすることができる `extraArgs`の項目があります。
|
||||
その構成要素は次の項目で定義されています。
|
||||
|
||||
|
||||
@@ -151,39 +151,56 @@ The output should look like:
|
||||
```none
|
||||
[init] Using Kubernetes version: vX.Y.Z
|
||||
[preflight] Running pre-flight checks
|
||||
[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
|
||||
[certificates] Generated ca certificate and key.
|
||||
[certificates] Generated apiserver certificate and key.
|
||||
[certificates] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
|
||||
[certificates] Generated apiserver-kubelet-client certificate and key.
|
||||
[certificates] Generated sa key and public key.
|
||||
[certificates] Generated front-proxy-ca certificate and key.
|
||||
[certificates] Generated front-proxy-client certificate and key.
|
||||
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
|
||||
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
|
||||
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
|
||||
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
|
||||
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
|
||||
[init] This often takes around a minute; or longer if the control plane images have to be pulled.
|
||||
[apiclient] All control plane components are healthy after 39.511972 seconds
|
||||
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
|
||||
[markmaster] Will mark node master as master by adding a label and a taint
|
||||
[markmaster] Master master tainted and labelled with key/value: node-role.kubernetes.io/master=""
|
||||
[bootstraptoken] Using token: <token>
|
||||
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
|
||||
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
|
||||
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
|
||||
[preflight] Pulling images required for setting up a Kubernetes cluster
|
||||
[preflight] This might take a minute or two, depending on the speed of your internet connection
|
||||
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
|
||||
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
|
||||
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
|
||||
[kubelet-start] Activating the kubelet service
|
||||
[certs] Using certificateDir folder "/etc/kubernetes/pki"
|
||||
[certs] Generating "etcd/ca" certificate and key
|
||||
[certs] Generating "etcd/server" certificate and key
|
||||
[certs] etcd/server serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
|
||||
[certs] Generating "etcd/healthcheck-client" certificate and key
|
||||
[certs] Generating "etcd/peer" certificate and key
|
||||
[certs] etcd/peer serving cert is signed for DNS names [kubeadm-master localhost] and IPs [10.138.0.4 127.0.0.1 ::1]
|
||||
[certs] Generating "apiserver-etcd-client" certificate and key
|
||||
[certs] Generating "ca" certificate and key
|
||||
[certs] Generating "apiserver" certificate and key
|
||||
[certs] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
|
||||
[certs] Generating "apiserver-kubelet-client" certificate and key
|
||||
[certs] Generating "front-proxy-ca" certificate and key
|
||||
[certs] Generating "front-proxy-client" certificate and key
|
||||
[certs] Generating "sa" key and public key
|
||||
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
|
||||
[kubeconfig] Writing "admin.conf" kubeconfig file
|
||||
[kubeconfig] Writing "kubelet.conf" kubeconfig file
|
||||
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
|
||||
[kubeconfig] Writing "scheduler.conf" kubeconfig file
|
||||
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
|
||||
[control-plane] Creating static Pod manifest for "kube-apiserver"
|
||||
[control-plane] Creating static Pod manifest for "kube-controller-manager"
|
||||
[control-plane] Creating static Pod manifest for "kube-scheduler"
|
||||
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
|
||||
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
|
||||
[apiclient] All control plane components are healthy after 31.501735 seconds
|
||||
[uploadconfig] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
|
||||
[kubelet] Creating a ConfigMap "kubelet-config-X.Y" in namespace kube-system with the configuration for the kubelets in the cluster
|
||||
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "kubeadm-master" as an annotation
|
||||
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the label "node-role.kubernetes.io/master=''"
|
||||
[mark-control-plane] Marking the node kubeadm-master as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
|
||||
[bootstrap-token] Using token: <token>
|
||||
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
|
||||
[bootstraptoken] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
|
||||
[bootstraptoken] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
|
||||
[bootstraptoken] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
|
||||
[bootstraptoken] creating the "cluster-info" ConfigMap in the "kube-public" namespace
|
||||
[addons] Applied essential addon: CoreDNS
|
||||
[addons] Applied essential addon: kube-proxy
|
||||
|
||||
Your Kubernetes master has initialized successfully!
|
||||
|
||||
To start using your cluster, you need to run (as a regular user):
|
||||
To start using your cluster, you need to run the following as a regular user:
|
||||
|
||||
mkdir -p $HOME/.kube
|
||||
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
|
||||
@@ -196,7 +213,7 @@ Run "kubectl apply -f [podnetwork].yaml" with one of the addon options listed at
|
||||
You can now join any number of machines by running the following on each node
|
||||
as root:
|
||||
|
||||
kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>
|
||||
kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>
|
||||
```
|
||||
|
||||
To make kubectl work for your non-root user, run these commands, which are
|
||||
@@ -262,7 +279,7 @@ Please select one of the tabs to see installation instructions for the respectiv
|
||||
{{% tab name="Calico" %}}
|
||||
For more information about using Calico, see [Quickstart for Calico on Kubernetes](https://docs.projectcalico.org/latest/getting-started/kubernetes/), [Installing Calico for policy and networking](https://docs.projectcalico.org/latest/getting-started/kubernetes/installation/calico), and other related resources.
|
||||
|
||||
For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64` only.
|
||||
For Calico to work correctly, you need to pass `--pod-network-cidr=192.168.0.0/16` to `kubeadm init` or update the `calico.yml` file to match your Pod network. Note that Calico works on `amd64`, `arm64`, and `ppc64le` only.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
|
||||
@@ -283,31 +300,30 @@ kubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Cilium" %}}
|
||||
For more information about using Cilium with Kubernetes, see [Quickstart for Cilium on Kubernetes](http://docs.cilium.io/en/v1.2/kubernetes/quickinstall/) and [Kubernetes Install guide for Cilium](http://docs.cilium.io/en/v1.2/kubernetes/install/).
|
||||
|
||||
Passing `--pod-network-cidr` option to `kubeadm init` is not required, but highly recommended.
|
||||
For more information about using Cilium with Kubernetes, see [Kubernetes Install guide for Cilium](https://docs.cilium.io/en/stable/kubernetes/).
|
||||
|
||||
These commands will deploy Cilium with its own etcd managed by etcd operator.
|
||||
|
||||
_Note_: If you are running kubeadm in a single node please untaint it so that
|
||||
etcd-operator pods can be scheduled in the control-plane node.
|
||||
|
||||
```shell
|
||||
# Download required manifests from Cilium repository
|
||||
wget https://github.com/cilium/cilium/archive/v1.2.0.zip
|
||||
unzip v1.2.0.zip
|
||||
cd cilium-1.2.0/examples/kubernetes/addons/etcd-operator
|
||||
|
||||
# Generate and deploy etcd certificates
|
||||
export CLUSTER_DOMAIN=$(kubectl get ConfigMap --namespace kube-system coredns -o yaml | awk '/kubernetes/ {print $2}')
|
||||
tls/certs/gen-cert.sh $CLUSTER_DOMAIN
|
||||
tls/deploy-certs.sh
|
||||
|
||||
# Label kube-dns with fixed identity label
|
||||
kubectl label -n kube-system pod $(kubectl -n kube-system get pods -l k8s-app=kube-dns -o jsonpath='{range .items[]}{.metadata.name}{" "}{end}') io.cilium.fixed-identity=kube-dns
|
||||
|
||||
kubectl create -f ./
|
||||
|
||||
# Wait several minutes for Cilium, coredns and etcd pods to converge to a working state
|
||||
kubectl taint nodes <node-name> node-role.kubernetes.io/master:NoSchedule-
|
||||
```
|
||||
|
||||
To deploy Cilium you just need to run:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium.yaml
|
||||
```
|
||||
|
||||
Once all Cilium pods are marked as `READY`, you start using your cluster.
|
||||
|
||||
```shell
|
||||
$ kubectl get pods -n kube-system --selector=k8s-app=cilium
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cilium-drxkl 1/1 Running 0 18m
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Flannel" %}}
|
||||
@@ -318,10 +334,11 @@ Set `/proc/sys/net/bridge/bridge-nf-call-iptables` to `1` by running `sysctl net
|
||||
to pass bridged IPv4 traffic to iptables' chains. This is a requirement for some CNI plugins to work, for more information
|
||||
please see [here](/docs/concepts/cluster-administration/network-plugins/#network-plugin-requirements).
|
||||
|
||||
Note that `flannel` works on `amd64`, `arm`, `arm64` and `ppc64le`.
|
||||
Note that `flannel` works on `amd64`, `arm`, `arm64`, `ppc64le` and `s390x` under Linux.
|
||||
Windows (`amd64`) is claimed as supported in v0.11.0 but the usage is undocumented.
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
|
||||
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
For more information about `flannel`, see [the CoreOS flannel repository on GitHub
|
||||
@@ -379,6 +396,16 @@ There are multiple, flexible ways to install JuniperContrail/TungstenFabric CNI.
|
||||
|
||||
Kindly refer to this quickstart: [TungstenFabric](https://tungstenfabric.github.io/website/)
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="Contiv-VPP" %}}
|
||||
[Contiv-VPP](https://contivpp.io/) employs a programmable CNF vSwitch based on [FD.io VPP](https://fd.io/),
|
||||
offering feature-rich & high-performance cloud-native networking and services.
|
||||
|
||||
It implements k8s services and network policies in the user space (on VPP).
|
||||
|
||||
Please refer to this installation guide: [Contiv-VPP Manual Installation](https://github.com/contiv/vpp/blob/master/docs/setup/MANUAL_INSTALL.md)
|
||||
{{% /tab %}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
@@ -543,6 +570,18 @@ Then, on the node being removed, reset all kubeadm installed state:
|
||||
kubeadm reset
|
||||
```
|
||||
|
||||
The reset process does not reset or clean up iptables rules or IPVS tables. If you wish to reset iptables, you must do so manually:
|
||||
|
||||
```bash
|
||||
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
|
||||
```
|
||||
|
||||
If you want to reset the IPVS tables, you must run the following command:
|
||||
|
||||
```bash
|
||||
ipvsadm -C
|
||||
```
|
||||
|
||||
If you wish to start over simply run `kubeadm init` or `kubeadm join` with the
|
||||
appropriate arguments.
|
||||
|
||||
@@ -587,8 +626,10 @@ Due to that we can't see into the future, kubeadm CLI vX.Y may or may not be abl
|
||||
Example: kubeadm v1.8 can deploy both v1.7 and v1.8 clusters and upgrade v1.7 kubeadm-created clusters to
|
||||
v1.8.
|
||||
|
||||
Please also check our [installation guide](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
|
||||
for more information on the version skew between kubelets and the control plane.
|
||||
These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
|
||||
|
||||
* Kubernetes [version and version-skew policy](/docs/setup/version-skew-policy/)
|
||||
* Kubeadm-specific [installation guide](/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
|
||||
|
||||
## kubeadmは様々なプラットフォームで動く
|
||||
|
||||
|
||||
@@ -6,58 +6,42 @@ weight: 60
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
This page explains two different approaches to setting up a highly available Kubernetes
|
||||
cluster using kubeadm:
|
||||
このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
|
||||
|
||||
- With stacked control plane nodes. This approach requires less infrastructure. The etcd members
|
||||
and control plane nodes are co-located.
|
||||
- With an external etcd cluster. This approach requires more infrastructure. The
|
||||
control plane nodes and etcd members are separated.
|
||||
- 積み重なったコントロールプレーンノードを使う方法。こちらのアプローチは、必要なインフラストラクチャーが少ないです。etcdのメンバーと、コントロールプレーンノードは同じ場所に置かれます。
|
||||
- 外部のetcdクラスターを使う方法。こちらのアプローチには、より多くのインフラストラクチャーが必要です。コントロールプレーンノードと、etcdのメンバーは分離されます。
|
||||
|
||||
Before proceeding, you should carefully consideer which approach best meets the needs of your applications
|
||||
and environment. [This comparison topic](/docs/setup/independent/ha-topology/) outlines the advantages and disadvantages of each.
|
||||
先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。[こちらの比較](/docs/setup/independent/ha-topology/)が、それぞれの利点/欠点について概説しています。
|
||||
|
||||
Your clusters must run Kubernetes version 1.12 or later. You should also be aware that
|
||||
setting up HA clusters with kubeadm is still experimental and will be further simplified
|
||||
in future versions. You might encounter issues with upgrading your clusters, for example.
|
||||
We encourage you to try either approach, and provide us with feedback in the kubeadm
|
||||
[issue tracker](https://github.com/kubernetes/kubeadm/issues/new).
|
||||
クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmの[issue tracker](https://github.com/kubernetes/kubeadm/issues/new)で我々にフィードバックを提供してくれることを推奨します。
|
||||
|
||||
Note that the alpha feature gate `HighAvailability` is deprecated in v1.12 and removed in v1.13.
|
||||
alpha feature gateである`HighAvailability`はv1.12で非推奨となり、v1.13で削除されたことに留意してください。
|
||||
|
||||
See also [The HA upgrade documentation](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha).
|
||||
[高可用性クラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13)も参照してください。
|
||||
|
||||
{{< caution >}}
|
||||
This page does not address running your cluster on a cloud provider. In a cloud
|
||||
environment, neither approach documented here works with Service objects of type
|
||||
LoadBalancer, or with dynamic PersistentVolumes.
|
||||
このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
|
||||
{{< /caution >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
For both methods you need this infrastructure:
|
||||
どちらの方法でも、以下のインフラストラクチャーが必要です:
|
||||
|
||||
- Three machines that meet [kubeadm's minimum
|
||||
requirements](/docs/setup/independent/install-kubeadm/#before-you-begin) for
|
||||
the masters
|
||||
- Three machines that meet [kubeadm's minimum
|
||||
requirements](/docs/setup/independent/install-kubeadm/#before-you-begin) for
|
||||
the workers
|
||||
- Full network connectivity between all machines in the cluster (public or
|
||||
private network)
|
||||
- sudo privileges on all machines
|
||||
- SSH access from one device to all nodes in the system
|
||||
- `kubeadm` and `kubelet` installed on all machines. `kubectl` is optional.
|
||||
- master用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
|
||||
- worker用に、[kubeadmの最小要件](/ja/docs/setup/independent/install-kubeadm/#before-you-begin)を満たす3台のマシン
|
||||
- クラスター内のすべてのマシン間がフルにネットワーク接続可能であること(パブリック、もしくはプライベートネットワーク)
|
||||
- すべてのマシンにおいて、sudo権限
|
||||
- あるデバイスから、システム内のすべてのノードに対しSSH接続できること
|
||||
- `kubeadm`と`kubelet`がすべてのマシンにインストールされていること。 `kubectl`は任意です。
|
||||
|
||||
For the external etcd cluster only, you also need:
|
||||
外部etcdクラスターには、以下も必要です:
|
||||
|
||||
- Three additional machines for etcd members
|
||||
- etcdメンバー用に、追加で3台のマシン
|
||||
|
||||
{{< note >}}
|
||||
The following examples run Calico as the Pod networking provider. If you run another
|
||||
networking provider, make sure to replace any default values as needed.
|
||||
以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -67,83 +51,63 @@ networking provider, make sure to replace any default values as needed.
|
||||
## 両手順における最初のステップ
|
||||
|
||||
{{< note >}}
|
||||
**Note**: All commands on any control plane or etcd node should be
|
||||
run as root.
|
||||
コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。
|
||||
{{< /note >}}
|
||||
|
||||
- Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and
|
||||
some like Weave do not. See the see [the CNI network
|
||||
documentation](/docs/setup/independent/create-cluster-kubeadm/#pod-network).
|
||||
To add a pod CIDR set the `podSubnet: 192.168.0.0/16` field under
|
||||
the `networking` object of `ClusterConfiguration`.
|
||||
- CalicoなどのいくつかのCNIネットワークプラグインは`192.168.0.0/16`のようなCIDRを必要としますが、Weaveなどは必要としません。[CNIネットワークドキュメント](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)を参照してください。PodにCIDRを設定するには、`ClusterConfiguration`の`networking`オブジェクトに`podSubnet: 192.168.0.0/16`フィールドを設定してください。
|
||||
|
||||
### kube-apiserver用にロードバランサーを作成
|
||||
|
||||
{{< note >}}
|
||||
There are many configurations for load balancers. The following example is only one
|
||||
option. Your cluster requirements may need a different configuration.
|
||||
ロードバランサーには多くの設定項目があります。以下の例は、一選択肢に過ぎません。あなたのクラスター要件には、異なった設定が必要かもしれません。
|
||||
{{< /note >}}
|
||||
|
||||
1. Create a kube-apiserver load balancer with a name that resolves to DNS.
|
||||
1. DNSで解決される名前で、kube-apiserver用ロードバランサーを作成する。
|
||||
- クラウド環境では、コントロールプレーンノードをTCPフォワーディングロードバランサーの後ろに置かなければなりません。このロードバランサーはターゲットリストに含まれる、すべての健全なコントロールプレーンノードにトラフィックを分配します。apiserverへのヘルスチェックはkube-apiserverがリッスンするポート(デフォルト値: `:6443`)に対する、TCPチェックです。
|
||||
|
||||
- In a cloud environment you should place your control plane nodes behind a TCP
|
||||
forwarding load balancer. This load balancer distributes traffic to all
|
||||
healthy control plane nodes in its target list. The health check for
|
||||
an apiserver is a TCP check on the port the kube-apiserver listens on
|
||||
(default value `:6443`).
|
||||
- クラウド環境では、IPアドレスを直接使うことは推奨されません。
|
||||
|
||||
- It is not recommended to use an IP address directly in a cloud environment.
|
||||
- ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。
|
||||
|
||||
- The load balancer must be able to communicate with all control plane nodes
|
||||
on the apiserver port. It must also allow incoming traffic on its
|
||||
listening port.
|
||||
- [HAProxy](http://www.haproxy.org/)をロードバランサーとして使用することができます。
|
||||
|
||||
- [HAProxy](http://www.haproxy.org/) can be used as a load balancer.
|
||||
- ロードバランサーのアドレスは、常にkubeadmの`ControlPlaneEndpoint`のアドレスと一致することを確認してください。
|
||||
|
||||
- Make sure the address of the load balancer always matches
|
||||
the address of kubeadm's `ControlPlaneEndpoint`.
|
||||
|
||||
1. Add the first control plane nodes to the load balancer and test the
|
||||
connection:
|
||||
1. ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:
|
||||
|
||||
```sh
|
||||
nc -v LOAD_BALANCER_IP PORT
|
||||
```
|
||||
|
||||
- A connection refused error is expected because the apiserver is not yet
|
||||
running. A timeout, however, means the load balancer cannot communicate
|
||||
with the control plane node. If a timeout occurs, reconfigure the load
|
||||
balancer to communicate with the control plane node.
|
||||
- apiserverはまだ動いていないので、接続の拒否は想定通りです。しかし、タイムアウトしたのであれば、ロードバランサーはコントロールプレーンノードと通信できなかったことを意味します。もし、タイムアウトが起きたら、コントロールプレーンノードと通信できるように、ロードバランサーを再設定してください。
|
||||
|
||||
1. Add the remaining control plane nodes to the load balancer target group.
|
||||
1. 残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。
|
||||
|
||||
### SSHの設定
|
||||
|
||||
SSH is required if you want to control all nodes from a single machine.
|
||||
1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。
|
||||
|
||||
1. Enable ssh-agent on your main device that has access to all other nodes in
|
||||
the system:
|
||||
1. システム内の全ての他のノードにアクセスできるメインデバイスで、ssh-agentを有効にします
|
||||
|
||||
```
|
||||
eval $(ssh-agent)
|
||||
```
|
||||
|
||||
1. Add your SSH identity to the session:
|
||||
1. SSHの秘密鍵を、セッションに追加します:
|
||||
|
||||
```
|
||||
ssh-add ~/.ssh/path_to_private_key
|
||||
```
|
||||
|
||||
1. SSH between nodes to check that the connection is working correctly.
|
||||
1. 正常に接続できることを確認するために、ノード間でSSHします。
|
||||
|
||||
- When you SSH to any node, make sure to add the `-A` flag:
|
||||
- ノードにSSHする際は、必ず`-A`フラグをつけます:
|
||||
|
||||
```
|
||||
ssh -A 10.0.0.7
|
||||
```
|
||||
|
||||
- When using sudo on any node, make sure to preserve the environment so SSH
|
||||
forwarding works:
|
||||
- ノードでsudoするときは、SSHフォワーディングが動くように、環境変数を引き継ぎます:
|
||||
|
||||
```
|
||||
sudo -E -s
|
||||
@@ -153,7 +117,7 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
|
||||
### 最初のコントロールプレーンノードの手順
|
||||
|
||||
1. On the first control plane node, create a configuration file called `kubeadm-config.yaml`:
|
||||
1. 最初のコントロールプレーンノードで、`kubeadm-config.yaml`という設定ファイルを作成します:
|
||||
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
kind: ClusterConfiguration
|
||||
@@ -163,18 +127,17 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
- "LOAD_BALANCER_DNS"
|
||||
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
|
||||
|
||||
- `kubernetesVersion` should be set to the Kubernetes version to use. This
|
||||
example uses `stable`.
|
||||
- `controlPlaneEndpoint` should match the address or DNS and port of the load balancer.
|
||||
- It's recommended that the versions of kubeadm, kubelet, kubectl and Kubernetes match.
|
||||
- `kubernetesVersion`には使用するKubernetesのバージョンを設定します。この例では`stable`を使用しています。
|
||||
- `controlPlaneEndpoint` はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。
|
||||
- kubeadm、kubelet、kubectlとKubernetesのバージョンを一致させることが推奨されます。
|
||||
|
||||
1. Make sure that the node is in a clean state:
|
||||
1. ノードがきれいな状態であることを確認します:
|
||||
|
||||
```sh
|
||||
sudo kubeadm init --config=kubeadm-config.yaml
|
||||
```
|
||||
|
||||
You should see something like:
|
||||
このような出力がされます:
|
||||
|
||||
```sh
|
||||
...
|
||||
@@ -184,29 +147,27 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
|
||||
```
|
||||
|
||||
1. Copy this output to a text file. You will need it later to join other control plane nodes to the
|
||||
cluster.
|
||||
1. この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。
|
||||
|
||||
1. Apply the Weave CNI plugin:
|
||||
1. Weave CNIプラグインをapplyします:
|
||||
|
||||
```sh
|
||||
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
|
||||
```
|
||||
|
||||
1. Type the following and watch the pods of the components get started:
|
||||
1. 以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します:
|
||||
|
||||
```sh
|
||||
kubectl get pod -n kube-system -w
|
||||
```
|
||||
|
||||
- It's recommended that you join new control plane nodes only after the first node has finished initializing.
|
||||
- 最初のコントロールプレーンノードが初期化を完了してから、新しいノードを参加させることが推奨されます。
|
||||
|
||||
1. Copy the certificate files from the first control plane node to the rest:
|
||||
1. 証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします:
|
||||
|
||||
In the following example, replace `CONTROL_PLANE_IPS` with the IP addresses of the
|
||||
other control plane nodes.
|
||||
以下の例では、`CONTROL_PLANE_IPS`を他のコントロールプレーンノードのIPアドレスで置き換えます。
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
USER=ubuntu # 変更可能
|
||||
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
|
||||
for host in ${CONTROL_PLANE_IPS}; do
|
||||
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
|
||||
@@ -221,12 +182,16 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
done
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。
|
||||
{{< /caution >}}
|
||||
|
||||
### 残りのコントロールプレーンノードの手順
|
||||
|
||||
1. Move the files created by the previous step where `scp` was used:
|
||||
1. `scp`を使用する手順で作成したファイルを移動します:
|
||||
|
||||
```sh
|
||||
USER=ubuntu # customizable
|
||||
USER=ubuntu # 変更可能
|
||||
mkdir -p /etc/kubernetes/pki/etcd
|
||||
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
|
||||
mv /home/${USER}/ca.key /etc/kubernetes/pki/
|
||||
@@ -239,36 +204,32 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
This process writes all the requested files in the `/etc/kubernetes` folder.
|
||||
この手順で、`/etc/kubernetes`フォルダーに必要な全てのファイルが書き込まれます。
|
||||
|
||||
1. Start `kubeadm join` on this node using the join command that was previously given to you by `kubeadm init` on
|
||||
the first node. It should look something like this:
|
||||
1. `kubeadm init`を最初のノードで実行した際に取得したjoinコマンドを使って、このノードで`kubeadm join`を開始します。このようなコマンドになるはずです:
|
||||
|
||||
```sh
|
||||
sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
|
||||
```
|
||||
- `--experimental-control-plane`フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。
|
||||
|
||||
- Notice the addition of the `--experimental-control-plane` flag. This flag automates joining this
|
||||
control plane node to the cluster.
|
||||
|
||||
1. Type the following and watch the pods of the components get started:
|
||||
1. 以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します:
|
||||
|
||||
```sh
|
||||
kubectl get pod -n kube-system -w
|
||||
```
|
||||
|
||||
1. Repeat these steps for the rest of the control plane nodes.
|
||||
1. これらのステップを、残りのコントロールプレーンノードに対して繰り返します。
|
||||
|
||||
## 外部のetcdノード
|
||||
|
||||
### etcdクラスターの構築
|
||||
|
||||
- Follow [these instructions](/docs/setup/independent/setup-ha-etcd-with-kubeadm/)
|
||||
to set up the etcd cluster.
|
||||
- [こちらの手順](/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm/)にしたがって、etcdクラスターを構築してください。
|
||||
|
||||
### 最初のコントロールプレーンノードの構築
|
||||
|
||||
1. Copy the following files from any node from the etcd cluster to this node:
|
||||
1. 以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください:
|
||||
|
||||
```sh
|
||||
export CONTROL_PLANE="ubuntu@10.0.0.7"
|
||||
@@ -277,9 +238,9 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
+scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
|
||||
```
|
||||
|
||||
- Replace the value of `CONTROL_PLANE` with the `user@host` of this machine.
|
||||
- `CONTROL_PLANE`の値を、このマシンの`user@host`で置き換えます。
|
||||
|
||||
1. Create a file called `kubeadm-config.yaml` with the following contents:
|
||||
1. 以下の内容で、`kubeadm-config.yaml`という名前の設定ファイルを作成します:
|
||||
|
||||
apiVersion: kubeadm.k8s.io/v1beta1
|
||||
kind: ClusterConfiguration
|
||||
@@ -298,9 +259,9 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
|
||||
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
|
||||
|
||||
- The difference between stacked etcd and external etcd here is that we are using the `external` field for `etcd` in the kubeadm config. In the case of the stacked etcd topology this is managed automatically.
|
||||
- ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグの`etcd`に`external`フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。
|
||||
|
||||
- Replace the following variables in the template with the appropriate values for your cluster:
|
||||
- テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます:
|
||||
|
||||
- `LOAD_BALANCER_DNS`
|
||||
- `LOAD_BALANCER_PORT`
|
||||
@@ -308,11 +269,11 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
- `ETCD_1_IP`
|
||||
- `ETCD_2_IP`
|
||||
|
||||
1. Run `kubeadm init --config kubeadm-config.yaml` on this node.
|
||||
1. `kubeadm init --config kubeadm-config.yaml`をこのノードで実行します。
|
||||
|
||||
1. Write the join command that is returned to a text file for later use.
|
||||
1. 表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。
|
||||
|
||||
1. Apply the Weave CNI plugin:
|
||||
1. Weave CNIプラグインをapplyします:
|
||||
|
||||
```sh
|
||||
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
|
||||
@@ -320,27 +281,22 @@ SSH is required if you want to control all nodes from a single machine.
|
||||
|
||||
### 残りのコントロールプレーンノードの手順
|
||||
|
||||
To add the rest of the control plane nodes, follow [these instructions](#steps-for-the-rest-of-the-control-plane-nodes).
|
||||
The steps are the same as for the stacked etcd setup, with the exception that a local
|
||||
etcd member is not created.
|
||||
残りのコントロールプレーンノードを参加させるために、[こちらの手順](#残りのコントロールプレーンノードの手順)に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。
|
||||
|
||||
To summarize:
|
||||
まとめると:
|
||||
|
||||
- Make sure the first control plane node is fully initialized.
|
||||
- Copy certificates between the first control plane node and the other control plane nodes.
|
||||
- Join each control plane node with the join command you saved to a text file, plus add the `--experimental-control-plane` flag.
|
||||
- 最初のコントロールプレーンノードが完全に初期化されているのを確認します。
|
||||
- 証明書を、最初のコントロールプレーンノードから他のコントロールプレーンノードへコピーします。
|
||||
- テキストファイルに保存したjoinコマンドに`--experimental-control-plane` フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。
|
||||
|
||||
## コントロールプレーン起動後の共通タスク
|
||||
|
||||
### Podネットワークのインストール
|
||||
|
||||
[Follow these instructions](/docs/setup/independent/create-cluster-kubeadm/#pod-network) to install
|
||||
the pod network. Make sure this corresponds to whichever pod CIDR you provided
|
||||
in the master configuration file.
|
||||
Podネットワークをインストールするには、[こちらの手順に従ってください](/ja/docs/setup/independent/create-cluster-kubeadm/#pod-network)。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。
|
||||
|
||||
### ワーカーのインストール
|
||||
### workerのインストール
|
||||
|
||||
Each worker node can now be joined to the cluster with the command returned from any of the
|
||||
`kubeadm init` commands. The flag `--experimental-control-plane` should not be added to worker nodes.
|
||||
`kubeadm init`コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、`--experimental-control-plane`フラグを追加する必要はありません。
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: kubeadmのインストール
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
card:
|
||||
name: setup
|
||||
weight: 20
|
||||
title: kubeadmセットアップツールのインストール
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
@@ -90,7 +94,6 @@ Other CRI-based runtimes include:
|
||||
- [containerd](https://github.com/containerd/cri) (CRI plugin built into 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.
|
||||
|
||||
@@ -106,7 +109,7 @@ You will install these packages on all of your machines:
|
||||
* `kubectl`: the command line util to talk to your cluster.
|
||||
|
||||
kubeadm **will not** install or manage `kubelet` or `kubectl` for you, so you will
|
||||
need to ensure they match the version of the Kubernetes control panel you want
|
||||
need to ensure they match the version of the Kubernetes control plane you want
|
||||
kubeadm to install for you. If you do not, there is a risk of a version skew occurring that
|
||||
can lead to unexpected, buggy behaviour. However, _one_ minor version skew between the
|
||||
kubelet and the control plane is supported, but the kubelet version may never exceed the API
|
||||
@@ -119,8 +122,10 @@ This is because kubeadm and Kubernetes require
|
||||
[special attention to upgrade](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-11/).
|
||||
{{</ warning >}}
|
||||
|
||||
For more information on version skews, please read our
|
||||
[version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy).
|
||||
For more information on version skews, see:
|
||||
|
||||
* Kubernetes [version and version-skew policy](/docs/setup/version-skew-policy/)
|
||||
* Kubeadm-specific [version skew policy](/docs/setup/independent/create-cluster-kubeadm/#version-skew-policy)
|
||||
|
||||
{{< tabs name="k8s_install" >}}
|
||||
{{% tab name="Ubuntu, Debian or HypriotOS" %}}
|
||||
@@ -154,7 +159,7 @@ sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config
|
||||
|
||||
yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
|
||||
|
||||
systemctl enable kubelet && systemctl start kubelet
|
||||
systemctl enable --now kubelet
|
||||
```
|
||||
|
||||
**Note:**
|
||||
@@ -172,6 +177,7 @@ systemctl enable kubelet && systemctl start kubelet
|
||||
EOF
|
||||
sysctl --system
|
||||
```
|
||||
- Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `modprobe br_netfilter`.
|
||||
{{% /tab %}}
|
||||
{{% tab name="Container Linux" %}}
|
||||
Install CNI plugins (required for most pod network):
|
||||
@@ -208,7 +214,7 @@ curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/bu
|
||||
Enable and start `kubelet`:
|
||||
|
||||
```bash
|
||||
systemctl enable kubelet && systemctl start kubelet
|
||||
systemctl enable --now kubelet
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
@@ -182,7 +182,7 @@ This file specifies the default locations for all of the files managed by kubead
|
||||
- The file containing the kubelet's ComponentConfig is `/var/lib/kubelet/config.yaml`.
|
||||
- The dynamic environment file that contains `KUBELET_KUBEADM_ARGS` is sourced from `/var/lib/kubelet/kubeadm-flags.env`.
|
||||
- The file that can contain user-specified flag overrides with `KUBELET_EXTRA_ARGS` is sourced from
|
||||
`/etc/default/kubelet` (for DEBs), or `/etc/systconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
|
||||
`/etc/default/kubelet` (for DEBs), or `/etc/sysconfig/kubelet` (for RPMs). `KUBELET_EXTRA_ARGS`
|
||||
is last in the flag chain and has the highest priority in the event of conflicting settings.
|
||||
|
||||
## Kubernetesバイナリとパッケージの内容
|
||||
@@ -191,10 +191,10 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
|
||||
|
||||
| Package name | Description |
|
||||
|--------------|-------------|
|
||||
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and [The kubelet drop-in file(#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
|
||||
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
|
||||
| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
|
||||
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
|
||||
| `kubernetes-cni` | Installs the official CNI binaries into the `/opt/cni/bin` directory. |
|
||||
| `cri-tools` | Installs the `/usr/bin/crictl` binary from [https://github.com/kubernetes-incubator/cri-tools](https://github.com/kubernetes-incubator/cri-tools). |
|
||||
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-incubator/cri-tools). |
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -44,9 +44,8 @@ this example.
|
||||
|
||||
1. Configure the kubelet to be a service manager for etcd.
|
||||
|
||||
Running etcd is simpler than running kubernetes so you must override the
|
||||
kubeadm-provided kubelet unit file by creating a new one with a higher
|
||||
precedence.
|
||||
Since etcd was created first, you must override the service priority by creating a new unit file
|
||||
that has higher precedence than the kubeadm-provided kubelet unit file.
|
||||
|
||||
```sh
|
||||
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
|
||||
@@ -90,7 +89,7 @@ this example.
|
||||
peerCertSANs:
|
||||
- "${HOST}"
|
||||
extraArgs:
|
||||
initial-cluster: infra0=https://${ETCDHOSTS[0]}:2380,infra1=https://${ETCDHOSTS[1]}:2380,infra2=https://${ETCDHOSTS[2]}:2380
|
||||
initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380
|
||||
initial-cluster-state: new
|
||||
name: ${NAME}
|
||||
listen-peer-urls: https://${HOST}:2380
|
||||
@@ -256,7 +255,7 @@ this example.
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Once your have a working 3 member etcd cluster, you can continue setting up a
|
||||
Once you have a working 3 member etcd cluster, you can continue setting up a
|
||||
highly available control plane using the [external etcd method with
|
||||
kubeadm](/docs/setup/independent/high-availability/).
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@ This may be caused by a number of problems. The most common are:
|
||||
```
|
||||
|
||||
There are two common ways to fix the cgroup driver problem:
|
||||
|
||||
|
||||
1. Install Docker again following instructions
|
||||
[here](/docs/setup/independent/install-kubeadm/#installing-docker).
|
||||
1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to
|
||||
@@ -100,9 +100,8 @@ Right after `kubeadm init` there should not be any pods in these states.
|
||||
until you have deployed the network solution.
|
||||
- If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state
|
||||
after deploying the network solution and nothing happens to `coredns` (or `kube-dns`),
|
||||
it's very likely that the Pod Network solution and nothing happens to the DNS server, it's very
|
||||
likely that the Pod Network solution that you installed is somehow broken. You
|
||||
might have to grant it more RBAC privileges or use a newer version. Please file
|
||||
it's very likely that the Pod Network solution that you installed is somehow broken.
|
||||
You might have to grant it more RBAC privileges or use a newer version. Please file
|
||||
an issue in the Pod Network providers' issue tracker and get the issue triaged there.
|
||||
- If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option
|
||||
when booting `dockerd` with `systemd` and restart `docker`. You can see the MountFlags in `/usr/lib/systemd/system/docker.service`.
|
||||
@@ -155,6 +154,18 @@ Unable to connect to the server: x509: certificate signed by unknown authority (
|
||||
regenerate a certificate if necessary. The certificates in a kubeconfig file
|
||||
are base64 encoded. The `base64 -d` command can be used to decode the certificate
|
||||
and `openssl x509 -text -noout` can be used for viewing the certificate information.
|
||||
- Unset the `KUBECONFIG` environment variable using:
|
||||
|
||||
```sh
|
||||
unset KUBECONFIG
|
||||
```
|
||||
|
||||
Or set it to the default `KUBECONFIG` location:
|
||||
|
||||
```sh
|
||||
export KUBECONFIG=/etc/kubernetes/admin.conf
|
||||
```
|
||||
|
||||
- Another workaround is to overwrite the existing `kubeconfig` for the "admin" user:
|
||||
|
||||
```sh
|
||||
@@ -226,4 +237,28 @@ Disabling SELinux or setting `allowPrivilegeEscalation` to `true` can compromise
|
||||
the security of your cluster.
|
||||
{{< /warning >}}
|
||||
|
||||
## etcdのpodが継続的に再起動する
|
||||
|
||||
If you encounter the following error:
|
||||
|
||||
```
|
||||
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\""
|
||||
```
|
||||
|
||||
this issue appears if you run CentOS 7 with Docker 1.13.1.84.
|
||||
This version of Docker can prevent the kubelet from executing into the etcd container.
|
||||
|
||||
To work around the issue, choose one of these options:
|
||||
|
||||
- Roll back to an earlier version of Docker, such as 1.13.1-75
|
||||
```
|
||||
yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64
|
||||
```
|
||||
|
||||
- Install one of the more recent recommended versions, such as 18.06:
|
||||
```bash
|
||||
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
|
||||
yum install docker-ce-18.06.1.ce-3.el7.x86_64
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
Reference in New Issue
Block a user