diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 5301362b36..776642c92f 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -2,6 +2,9 @@ title: Kubernetesとは何か？ content_template: templates/concept weight: 10 +card: + name: concepts + weight: 10 --- {{% capture overview %}} diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index d143a45170..4f086ca39b 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -1,11 +1,9 @@ --- title: Kubernetesドキュメント -layout: docsportal_home noedit: true -cid: userJourneys -css: /css/style_user_journeys.css -js: /js/user-journeys/home.js, https://use.fontawesome.com/4bcc658a89.js -display_browse_numbers: true +cid: docsHome +layout: docsportal_home +class: gridPage linkTitle: "ホーム" main_menu: true weight: 10 @@ -16,4 +14,43 @@ menu: weight: 20 post: >

チュートリアル、サンプルやドキュメントのリファレンスを使って Kubernetes の利用方法を学んでください。あなたはドキュメントへコントリビュートをすることもできます!

+overview: > + Kubernetesは、自動デプロイ、スケーリング、およびコンテナ化されたアプリケーションの管理を行うための、オープンソースのコンテナオーケストレーションエンジンです。本オープンソースプロジェクトは、Cloud Native Computing Foundation (CNCF).によって管理されています。 +cards: +- name: concepts + title: "基本を理解する" + description: "Kubernetesに基本的なコンセプトについて学びます。" + button: "コンセプトを学ぶ" + button_path: "/ja/docs/concepts" +- name: tutorials + title: "Kubernetesを試用する" + description: "チュートリアルに沿って、Kubernetesにアプリケーションをデプロイする方法を学びます。" + button: "チュートリアルを見る" + button_path: "/ja/docs/tutorials" +- name: setup + title: "クラスターを立ち上げる" + description: "ご自身のリソースや要件に合わせたKubernetes環境を動かしてみましょう。" + button: "Kubernetesをセットアップする" + button_path: "/ja/docs/setup" +- name: tasks + title: "Kubernetesの使い方を学ぶ" + description: "一般的な使い方と、それらを実行するための短い手順を調べます。" + button: "View Tasks" + button_path: "/ja/docs/tasks" +- name: reference + title: 参考情報を探す + description: 用語、コマンドラインの構文、APIのリソースタイプ、およびセットアップツールのドキュメントを参照します。 + button: View Reference + button_path: /ja/docs/reference +- name: contribute + title: ドキュメントに貢献する + description: 本プロジェクトに不慣れな方でも、久しぶりの方も、どなたでも貢献することができます。 + button: ドキュメントに貢献する + button_path: /ja/docs/contribute +- name: download + title: Kubernetesをダウンロードする + description: Kubernetesをインストールする場合や最新バージョンにアップグレードする場合は、現在のリリースノートを参照してください。 +- name: about + title: ドキュメントについて + description: このWebサイトには、Kubernetesの現在および以前の4つのバージョンに関するドキュメントが含まれています。 --- diff --git a/content/ja/docs/home/supported-doc-versions.md b/content/ja/docs/home/supported-doc-versions.md index 56fbec0b9f..d15db3875b 100644 --- a/content/ja/docs/home/supported-doc-versions.md +++ b/content/ja/docs/home/supported-doc-versions.md @@ -1,6 +1,10 @@ --- title: Kubernetesドキュメントがサポートしているバージョン content_template: templates/concept +card: + name: about + weight: 10 + title: ドキュメントがサポートしているバージョン --- {{% capture overview %}} diff --git a/content/ja/docs/setup/certificates.md b/content/ja/docs/setup/certificates.md index e71a93507c..253d0348b5 100644 --- a/content/ja/docs/setup/certificates.md +++ b/content/ja/docs/setup/certificates.md @@ -14,7 +14,7 @@ This page explains the certificates that your cluster requires. {{% capture body %}} -## あなたのクラスタではどのように証明書が使われているのか +## クラスタではどのように証明書が使われているのか Kubernetes requires PKI for the following operations: @@ -43,7 +43,7 @@ If you don't want kubeadm to generate the required certificates, you can create ### 単一ルート認証局 -You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself. +You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself. Required CAs: @@ -55,7 +55,7 @@ Required CAs: ### 全ての証明書 -If you don't wish to copy these private keys to your API servers, you can generate all certificates yourself. +If you don't wish to copy these private keys to your API servers, you can generate all certificates yourself. Required certificates: @@ -85,14 +85,15 @@ Certificates should be placed in a recommended path (as used by [kubeadm][kubead | Default CN | recommend key path | recommended cert path | command | key argument | cert argument | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| | etcd-ca | | etcd/ca.crt | kube-apiserver | | --etcd-cafile | -| etcd-client | apiserver-etcd-client.crt | apiserver-etcd-client.crt | kube-apiserver | --etcd-certfile | --etcd-keyfile | -| kubernetes-ca | | ca.crt | kube-apiserver | --client-ca-file | | -| kube-apiserver | apiserver.crt | apiserver.key | kube-apiserver | --tls-cert-file | --tls-private-key | -| apiserver-kubelet-client | apiserver-kubelet-client.crt | | kube-apiserver | --kubelet-client-certificate | | -| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-cert-file | --proxy-client-key-file | +| etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | +| kubernetes-ca | | ca.crt | kube-apiserver | | --client-ca-file | +| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file | +| apiserver-kubelet-client | | apiserver-kubelet-client.crt| kube-apiserver | | --kubelet-client-certificate | +| front-proxy-ca | | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | | | | | | | | | etcd-ca | | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | -| kube-etcd | | etcd/server.crt | etcd | | --cert-file | +| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | | etcd-ca | | etcd/ca.crt | etcdctl[2] | | --cacert | | kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl[2] | --key | --cert | @@ -101,15 +102,19 @@ Certificates should be placed in a recommended path (as used by [kubeadm][kubead ## ユーザアカウント用に証明書を設定する -You must manually configure these administrator account and service accounts: +You must manually configure these administrator account and service accounts: | filename | credential name | Default CN | O (in Subject) | |-------------------------|----------------------------|--------------------------------|----------------| | admin.conf | default-admin | kubernetes-admin | system:masters | -| kubelet.conf | default-auth | system:node:`` | system:nodes | +| kubelet.conf | default-auth | system:node:`` (see note) | system:nodes | | controller-manager.conf | default-controller-manager | system:kube-controller-manager | | | scheduler.conf | default-manager | system:kube-scheduler | | +{{< note >}} +The value of `` for `kubelet.conf` **must** match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the [Node Authorization](/docs/reference/access-authn-authz/node/). +{{< /note >}} + 1. For each config, generate an x509 cert/key pair with the given CN and O. 1. Run `kubectl` as follows for each config: diff --git a/content/ja/docs/setup/cri.md b/content/ja/docs/setup/cri.md index 598dd96846..43c71ed497 100644 --- a/content/ja/docs/setup/cri.md +++ b/content/ja/docs/setup/cri.md @@ -4,48 +4,83 @@ content_template: templates/concept weight: 100 --- {{% capture overview %}} -Kubernetesでは、v1.6.0からデフォルトでCRI(Container Runtime Interface)を利用できます。 -このページでは、様々なCRIのインストール方法について説明します。 +{{< feature-state for_k8s_version="v1.6" state="stable" >}} +Podのコンテナを実行するために、Kubernetesはコンテナランタイムを使用します。 +様々なランタイムのインストール手順は次のとおりです。 {{% /capture %}} {{% capture body %}} -手順を進めるにあたっては、下記に示しているコマンドを、ご利用のOSのものに従ってrootユーザとして実行してください。 -環境によっては、それぞれのホストへSSHで接続した後に`sudo -i`を実行することで、rootユーザになることができる場合があります。 + +{{< caution >}} +コンテナ実行時にruncがシステムファイルディスクリプターを扱える脆弱性が見つかりました。 +悪意のあるコンテナがこの脆弱性を利用してruncのバイナリを上書きし、 +コンテナホストシステム上で任意のコマンドを実行する可能性があります。 + +この問題の更なる情報は以下のリンクを参照してください。 +[cve-2019-5736 : runc vulnerability](https://access.redhat.com/security/cve/cve-2019-5736) +{{< /caution >}} + +### 適用性 + +{{< note >}} +このドキュメントはLinuxにCRIをインストールするユーザーの為に書かれています。 +他のオペレーティングシステムの場合、プラットフォーム固有のドキュメントを見つけてください。 +{{< /note >}} + +このガイドでは全てのコマンドを `root` で実行します。 +例として、コマンドに `sudo` を付けたり、 `root` になってそのユーザーでコマンドを実行します。 + +### Cgroupドライバー + +systemdがLinuxのディストリビューションのinitシステムとして選択されている場合、 +initプロセスが作成され、rootコントロールグループ(`cgroup`)を使い、cgroupマネージャーとして行動します。 +systemdはcgroupと密接に統合されており、プロセスごとにcgroupを割り当てます。 +`cgroupfs` を使うように、あなたのコンテナランライムとkubeletを設定することができます。 +systemdと一緒に `cgroupfs` を使用するということは、2つの異なるcgroupマネージャーがあることを意味します。 + +コントロールグループはプロセスに割り当てられるリソースを制御するために使用されます。 +単一のcgroupマネージャーは、割り当てられているリソースのビューを単純化し、 +デフォルトでは使用可能なリソースと使用中のリソースについてより一貫性のあるビューになります。 +2つのマネージャーがある場合、それらのリソースについて2つのビューが得られます。 +kubeletとDockerに `cgroupfs` を使用し、ノード上で実行されている残りのプロセスに `systemd` を使用するように設定されたノードが、 +リソース圧迫下で不安定になる場合があります。 + +あなたのコンテナランタイムとkubeletにcgroupドライバーとしてsystemdを使用するように設定を変更することはシステムを安定させました。 +以下のDocker設定の `native.cgroupdriver=systemd` オプションに注意してください。 ## Docker それぞれのマシンに対してDockerをインストールします。 -バージョン18.06が推奨されていますが、1.11、1.12、1.13、17.03についても動作が確認されています。 +バージョン18.06.2が推奨されていますが、1.11、1.12、1.13、17.03、18.09についても動作が確認されています。 Kubernetesのリリースノートにある、Dockerの動作確認済み最新バージョンについてもご確認ください。 システムへDockerをインストールするには、次のコマンドを実行します。 {{< tabs name="tab-cri-docker-installation" >}} {{< tab name="Ubuntu 16.04" codelang="bash" >}} -# UbuntuのリポジトリからDockerをインストールする場合は次を実行します: -apt-get update -apt-get install -y docker.io +# Docker CEのインストール +## リポジトリをセットアップ +### aptパッケージインデックスを更新 + apt-get update -# または、UbuntuやDebian向けのDockerのリポジトリからDocker CE 18.06をインストールする場合は、次を実行します: +### HTTPS越しのリポジトリの使用をaptに許可するために、パッケージをインストール + apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common -## 必要なパッケージをインストールします。 -apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common +### Docker公式のGPG鍵を追加 + curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - -## GPGキーをダウンロードします。 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +### dockerのaptリポジトリを追加 + add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" -## dockerパッケージ用のaptリポジトリを追加します。 -add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" +## docker ceのインストール +apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu -## dockerをインストールします。 -apt-get update && apt-get install docker-ce=18.06.0~ce~3-0~ubuntu - -# デーモンをセットアップします。 +# デーモンをセットアップ cat > /etc/docker/daemon.json <}} {{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -# CentOSやRHELのリポジトリからDockerをインストールする場合は、次を実行します: -yum install -y docker +# Docker CEのインストール +## リポジトリをセットアップ +### 必要なパッケージのインストール + yum install yum-utils device-mapper-persistent-data lvm2 -# または、CentOS向けのDockerのリポジトリからDocker CE 18.06をインストールする場合は、次を実行します: - -## 必要なパッケージをインストールします。 -yum install yum-utils device-mapper-persistent-data lvm2 - -## dockerパッケージ用のyumリポジトリを追加します。 +### dockerパッケージ用のyumリポジトリを追加 yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo -## dockerをインストールします。 -yum update && yum install docker-ce-18.06.1.ce +## docker ceのインストール +yum update && yum install docker-ce-18.06.2.ce -## /etc/docker ディレクトリを作成します。 +## /etc/docker ディレクトリを作成 mkdir /etc/docker -# デーモンをセットアップします。 +# デーモンをセットアップ cat > /etc/docker/daemon.json <}} @@ -217,8 +249,8 @@ tar --no-overwrite-dir -C / -xzf cri-containerd-${CONTAINERD_VERSION}.linux-amd6 systemctl start containerd ``` -## その他のCRIランタイム(rktletおよびfrakti)について +## その他のCRIランタイム: frakti -詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)および[Rktletのクイックスタートガイド](https://github.com/kubernetes-incubator/rktlet/blob/master/docs/getting-started-guide.md)を参照してください。 +詳細については[Fraktiのクイックスタートガイド](https://github.com/kubernetes/frakti#quickstart)を参照してください。 {{% /capture %}} diff --git a/content/ja/docs/setup/independent/control-plane-flags.md b/content/ja/docs/setup/independent/control-plane-flags.md index e0b227983b..22dcb71230 100644 --- a/content/ja/docs/setup/independent/control-plane-flags.md +++ b/content/ja/docs/setup/independent/control-plane-flags.md @@ -6,6 +6,8 @@ weight: 40 {{% capture overview %}} +{{< feature-state for_k8s_version="1.12" state="stable" >}} + kubeadmの`ClusterConfiguration`オブジェクトはAPIServer、ControllerManager、およびSchedulerのようなコントロールプレーンの構成要素に渡されたデフォルトのフラグを上書きすることができる `extraArgs`の項目があります。 その構成要素は次の項目で定義されています。 diff --git a/content/ja/docs/setup/independent/create-cluster-kubeadm.md b/content/ja/docs/setup/independent/create-cluster-kubeadm.md index a01787f780..1a6e76780d 100644 --- a/content/ja/docs/setup/independent/create-cluster-kubeadm.md +++ b/content/ja/docs/setup/independent/create-cluster-kubeadm.md @@ -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: -[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: +[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 : --discovery-token-ca-cert-hash sha256: + kubeadm join : --token --discovery-token-ca-cert-hash sha256: ``` 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-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は様々なプラットフォームで動く diff --git a/content/ja/docs/setup/independent/high-availability.md b/content/ja/docs/setup/independent/high-availability.md index ca9c410546..ebc38791b8 100644 --- a/content/ja/docs/setup/independent/high-availability.md +++ b/content/ja/docs/setup/independent/high-availability.md @@ -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 %}} diff --git a/content/ja/docs/setup/independent/install-kubeadm.md b/content/ja/docs/setup/independent/install-kubeadm.md index 3733f37801..01be568323 100644 --- a/content/ja/docs/setup/independent/install-kubeadm.md +++ b/content/ja/docs/setup/independent/install-kubeadm.md @@ -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/). {{}} -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 >}} diff --git a/content/ja/docs/setup/independent/kubelet-integration.md b/content/ja/docs/setup/independent/kubelet-integration.md index e346db2615..702febe081 100644 --- a/content/ja/docs/setup/independent/kubelet-integration.md +++ b/content/ja/docs/setup/independent/kubelet-integration.md @@ -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 %}} diff --git a/content/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm.md b/content/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm.md index 6e77c66e3e..30bc58ff23 100644 --- a/content/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm.md +++ b/content/ja/docs/setup/independent/setup-ha-etcd-with-kubeadm.md @@ -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/). diff --git a/content/ja/docs/setup/independent/troubleshooting-kubeadm.md b/content/ja/docs/setup/independent/troubleshooting-kubeadm.md index 8ece7268d8..d150d81819 100644 --- a/content/ja/docs/setup/independent/troubleshooting-kubeadm.md +++ b/content/ja/docs/setup/independent/troubleshooting-kubeadm.md @@ -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 %}} diff --git a/content/ja/docs/setup/minikube.md b/content/ja/docs/setup/minikube.md index c3c971226c..913a9b18ba 100644 --- a/content/ja/docs/setup/minikube.md +++ b/content/ja/docs/setup/minikube.md @@ -1,11 +1,11 @@ --- -title: Minikubを使用してローカル環境でKubernetesを動かす +title: Minikubeを使用してローカル環境でKubernetesを動かす content_template: templates/concept --- {{% capture overview %}} -Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a single-node Kubernetes cluster inside a VM on your laptop for users looking to try out Kubernetes or develop with it day-to-day. +Minikubeはローカル環境でKubernetesを簡単に実行するためのツールです。Kubernetesを試したり日々の開発への使用を検討するユーザー向けに、PC上のVM内でシングルノードのKubernetesクラスタを実行することができます。 {{% /capture %}} @@ -13,59 +13,79 @@ Minikube is a tool that makes it easy to run Kubernetes locally. Minikube runs a ## Minikubeの機能 -* Minikube supports Kubernetes features such as: +* MinikubeのサポートするKubernetesの機能: * DNS * 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) - * Enabling CNI (Container Network Interface) + * ConfigMapsとSecrets + * ダッシュボード + * コンテナランタイム: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o), [containerd](https://github.com/containerd/containerd) + * CNI (Container Network Interface) の有効化 * Ingress ## インストール -See [Installing Minikube](/docs/tasks/tools/install-minikube/). +[Minikubeのインストール](/docs/tasks/tools/install-minikube/) を参照 ## クイックスタート -Here's a brief demo of Minikube usage. -If you want to change the VM driver add the appropriate `--vm-driver=xxx` flag to `minikube start`. Minikube supports -the following drivers: +これはMinikubeの使い方の簡単なデモです。 +もしVMドライバを変更したい場合は、適切な `--vm-driver=xxx` フラグを `minikube start` に設定してください。Minikubeは以下のドライバをサポートしています。 * virtualbox * vmwarefusion * kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) * kvm ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver)) * hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated) - -Note that the IP below is dynamic and can change. It can be retrieved with `minikube ip`. +* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (非推奨) +* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +注意: 以下のIPは動的であり、変更される可能性があります。IPは `minikube ip` で取得することができます。 +* none (VMではなくホスト上でKubernetesコンポーネントを起動する。このドライバを使用するにはDocker ([docker install](https://docs.docker.com/install/linux/docker-ce/ubuntu/)) とLinux環境を必要とします) ```shell -$ minikube start +minikube start +``` +``` Starting local Kubernetes cluster... Running pre-create checks... Creating machine... Starting local Kubernetes cluster... - -$ kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080 +``` +```shell +kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080 +``` +``` deployment.apps/hello-minikube created -$ kubectl expose deployment hello-minikube --type=NodePort -service/hello-minikube exposed +``` +```shell +kubectl expose deployment hello-minikube --type=NodePort +``` +``` +service/hello-minikube exposed +``` +``` # We have now launched an echoserver pod but we have to wait until the pod is up before curling/accessing it # via the exposed service. # To check whether the pod is up and running we can use the following: -$ kubectl get pod +kubectl get pod +``` +``` NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s +``` +```shell # We can see that the pod is still being created from the ContainerCreating status -$ kubectl get pod +kubectl get pod +``` +``` NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 1/1 Running 0 13s +``` +```shell # We can see that the pod is now Running and we will now be able to curl it: -$ curl $(minikube service hello-minikube --url) - +curl $(minikube service hello-minikube --url) +``` +``` Hostname: hello-minikube-7c77b68cff-8wdzq @@ -91,13 +111,26 @@ Request Headers: Request Body: -no body in request- +``` - -$ kubectl delete services hello-minikube +```shell +kubectl delete services hello-minikube +``` +``` service "hello-minikube" deleted -$ kubectl delete deployment hello-minikube +``` + +```shell +kubectl delete deployment hello-minikube +``` +``` deployment.extensions "hello-minikube" deleted -$ minikube stop +``` + +```shell +minikube stop +``` +``` Stopping local Kubernetes cluster... Stopping "minikube"... ``` @@ -106,20 +139,22 @@ Stopping "minikube"... #### containerd -To use [containerd](https://github.com/containerd/containerd) as the container runtime, run: +[containerd](https://github.com/containerd/containerd) をコンテナランタイムとして使用するには以下を実行してください: ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ + --enable-default-cni \ --container-runtime=containerd \ --bootstrapper=kubeadm ``` -Or you can use the extended version: +もしくは拡張バージョンを使用することもできます: ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ + --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ @@ -128,20 +163,22 @@ $ minikube start \ #### CRI-O -To use [CRI-O](https://github.com/kubernetes-incubator/cri-o) as the container runtime, run: +[CRI-O](https://github.com/kubernetes-incubator/cri-o) をコンテナランタイムとして使用するには以下を実行してください: ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ + --enable-default-cni \ --container-runtime=cri-o \ --bootstrapper=kubeadm ``` -Or you can use the extended version: +もしくは拡張バージョンを使用することもできます: ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ + --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \ --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ @@ -150,44 +187,44 @@ $ minikube start \ #### rktコンテナエンジン -To use [rkt](https://github.com/rkt/rkt) as the container runtime run: +[rkt](https://github.com/rkt/rkt) をコンテナランタイムとして使用するには以下を実行してください: ```shell -$ minikube start \ +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. +これはrktとDockerの両方を含んだ代替のMinikubeのISOイメージを使用し、CNIネットワークを有効にします。 ### ドライバープラグイン -See [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) for details on supported drivers and how to install -plugins, if required. +サポートされているドライバとプラグインのインストールの詳細については [DRIVERS](https://git.k8s.io/minikube/docs/drivers.md) を参照してください。 ### Dockerデーモンの再利用によるローカルイメージの使用 -When using a single VM of Kubernetes, it's really handy to reuse the Minikube's built-in Docker daemon; as this means you don't have to build a docker registry on your host machine and push the image into it - you can just build inside the same docker daemon as minikube which speeds up local experiments. Just make sure you tag your Docker image with something other than 'latest' and use that tag while you pull the image. Otherwise, if you do not specify version of your image, it will be assumed as `:latest`, with pull image policy of `Always` correspondingly, which may eventually result in `ErrImagePull` as you may not have any versions of your Docker image out there in the default docker registry (usually DockerHub) yet. +Kubernetesの単一のVMを使用する場合、Minikube組み込みのDockerデーモンの再利用がおすすめです。ホストマシン上にDockerレジストリを構築してイメージをプッシュする必要がなく、ローカルでの実験を加速させるMinikubeと同じDockerデーモンの中に構築することができます。ただDockerイメージに'latest'以外のタグを付け、そのタグを使用してイメージをプルしてください。イメージのバージョンを指定しなければ、`Always` のプルイメージポリシーにより `:latest` と仮定され、もしデフォルトのDockerレジストリ(通常はDockerHub)にどのバージョンのDockerイメージもまだ存在しない場合には、`ErrImagePull` になる恐れがあります。 -To be able to work with the docker daemon on your mac/linux host use the `docker-env command` in your shell: +Mac/LinuxのホストでDockerデーモンを操作できるようにするには、shell内で `docker-env command` を使います: ```shell eval $(minikube docker-env) ``` -You should now be able to use docker on the command line on your host mac/linux machine talking to the docker daemon inside the minikube VM: +これにより、MinikubeのVM内のDockerデーモンと通信しているホストのMac/LinuxマシンのコマンドラインでDockerを使用できるようになっているはずです。 ```shell docker ps ``` -On Centos 7, docker may report the following error: +CentOS 7では、Dockerが以下のエラーを出力することがあります: ```shell Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory ``` -The fix is to update /etc/sysconfig/docker to ensure that Minikube's environment changes are respected: +修正方法としては、/etc/sysconfig/docker を更新してMinikube環境の変更が確実に反映されるようにすることです: ```shell < DOCKER_CERT_PATH=/etc/docker @@ -197,32 +234,32 @@ The fix is to update /etc/sysconfig/docker to ensure that Minikube's environment > fi ``` -Remember to turn off the imagePullPolicy:Always, otherwise Kubernetes won't use images you built locally. +imagePullPolicy:Alwaysをオフにすることを忘れないでください: さもなければKubernetesはローカルに構築したイメージを使用しません。 ## クラスターの管理 ### クラスターの起動 -The `minikube start` command can be used to start your cluster. -This command creates and configures a Virtual Machine that runs a single-node Kubernetes cluster. -This command also configures your [kubectl](/docs/user-guide/kubectl-overview/) installation to communicate with this cluster. +`minikube start` コマンドはクラスターを起動することができます。 +このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。 +また、このクラスターと通信する [kubectl](/docs/user-guide/kubectl-overview/) のインストールも設定します。 -If you are behind a web proxy, you will need to pass this information to the `minikube start` command: +もしWebプロキシーを通している場合、そのプロキシー情報を `minikube start` コマンドに渡す必要があります: ```shell https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 ``` -Unfortunately just setting the environment variables will not work. +残念なことに、ただ環境変数を設定するだけではうまく動作しません。 -Minikube will also create a "minikube" context, and set it to default in kubectl. -To switch back to this context later, run this command: `kubectl config use-context minikube`. +Minikubeは "minikube" コンテキストも作成し、そのコンテキストをデフォルト設定としてkubectlに設定します。 +あとでコンテキストを切り戻すには、このコマンドを実行してください: `kubectl config use-context minikube` #### Kubernetesバージョンの指定 -You can specify the specific version of Kubernetes for Minikube to use by -adding the `--kubernetes-version` string to the `minikube start` command. For -example, to run version `v1.7.3`, you would run the following: +`minikube start` コマンドに `--kubernetes-version` 文字列を追加することで、 +MinikubeにKubernetesの特定のバージョンを指定することができます。 +例えば、`v1.7.3` のバージョンを実行するには以下を実行します: ``` minikube start --kubernetes-version v1.7.3 @@ -230,16 +267,16 @@ minikube start --kubernetes-version v1.7.3 ### Kubernetesの設定 -Minikube has a "configurator" feature that allows users to configure the Kubernetes components with arbitrary values. -To use this feature, you can use the `--extra-config` flag on the `minikube start` command. +Minikubeにはユーザーが任意の値でKubenetesコンポーネントを設定することを可能にする "configurator" 機能があります。 +この機能を使うには、`minikube start` コマンドに `--extra-config` フラグを使うことができます。 -This flag is repeated, so you can pass it several times with several different values to set multiple options. +このフラグは繰り返されるので、複数のオプションを設定するためにいくつかの異なる値を使って何度も渡すことができます。 -This flag takes a string of the form `component.key=value`, where `component` is one of the strings from the below list, `key` is a value on the -configuration struct and `value` is the value to set. +このフラグは `component.key=value` 形式の文字列を取ります。`component` は下記のリストの文字列の1つです。 +`key`は設定構造体上の値で、 `value` は設定する値です。 -Valid keys can be found by examining the documentation for the Kubernetes `componentconfigs` for each component. -Here is the documentation for each supported configuration: +各コンポーネントのKubernetes `componentconfigs` のドキュメントを調べることで有効なキーを見つけることができます。 +サポートされている各設定のドキュメントは次のとおりです: * [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) * [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) @@ -250,37 +287,37 @@ Here is the documentation for each supported configuration: #### 例 -To change the `MaxPods` setting to 5 on the Kubelet, pass this flag: `--extra-config=kubelet.MaxPods=5`. +Kubeletの `MaxPods` 設定を5に変更するには、このフラグを渡します: `--extra-config=kubelet.MaxPods=5` -This feature also supports nested structs. To change the `LeaderElection.LeaderElect` setting to `true` on the scheduler, pass this flag: `--extra-config=scheduler.LeaderElection.LeaderElect=true`. +この機能はネストした構造体もサポートします。スケジューラーの `LeaderElection.LeaderElect` を `true` に設定するには、このフラグを渡します: `--extra-config=scheduler.LeaderElection.LeaderElect=true` -To set the `AuthorizationMode` on the `apiserver` to `RBAC`, you can use: `--extra-config=apiserver.authorization-mode=RBAC`. +`apiserver` の `AuthorizationMode` を `RABC` に設定するには、このフラグを使います: `--extra-config=apiserver.authorization-mode=RBAC`. ### クラスターの停止 -The `minikube stop` command can be used to stop your cluster. -This command shuts down the Minikube Virtual Machine, but preserves all cluster state and data. -Starting the cluster again will restore it to it's previous state. +`minikube stop` コマンドを使ってクラスターを停止することができます。 +このコマンドはMinikube仮想マシンをシャットダウンしますが、すべてのクラスターの状態とデータを保存します。 +クラスターを再起動すると、以前の状態に復元されます。 ### クラスターの削除 -The `minikube delete` command can be used to delete your cluster. -This command shuts down and deletes the Minikube Virtual Machine. No data or state is preserved. +`minikube delete` コマンドを使ってクラスターを削除することができます。 +このコマンドはMinikube仮想マシンをシャットダウンして削除します。データや状態は保存されません。 ## クラスターに触れてみよう ### Kubectl -The `minikube start` command creates a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) called "minikube". -This context contains the configuration to communicate with your Minikube cluster. +`minikube start` コマンドは "minikube" という[kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-)を作成します。 +このコンテキストはMinikubeクラスターと通信するための設定が含まれています。 -Minikube sets this context to default automatically, but if you need to switch back to it in the future, run: +Minikubeはこのコンテキストを自動的にデフォルトに設定しますが、将来的に設定を切り戻す場合には次のコマンドを実行してください: `kubectl config use-context minikube`, -Or pass the context on each command like this: `kubectl get pods --context=minikube`. +もしくは各コマンドにコンテキストを次のように渡します: `kubectl get pods --context=minikube` ### ダッシュボード -To access the [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), run this command in a shell after starting Minikube to get the address: +[Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/)にアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください: ```shell minikube dashboard @@ -288,7 +325,7 @@ minikube dashboard ### サービス -To access a service exposed via a node port, run this command in a shell after starting Minikube to get the address: +ノードポート経由で公開されているサービスにアクセスするには、Minikubeを起動してアドレスを取得した後、シェルでこのコマンドを実行してください: ```shell minikube service [-n NAMESPACE] [--url] NAME @@ -296,25 +333,25 @@ minikube service [-n NAMESPACE] [--url] NAME ## ネットワーク -The Minikube VM is exposed to the host system via a host-only IP address, that can be obtained with the `minikube ip` command. -Any services of type `NodePort` can be accessed over that IP address, on the NodePort. +MinikubeのVMは `minikube ip`コマンドで取得できるホストオンリーIPアドレスを介してホストシステムに公開されます。 +NodePort上では、 `NodePort` タイプのどのサービスもそのIPアドレスを介してアクセスできます。 -To determine the NodePort for your service, you can use a `kubectl` command like this: +サービスのNodePortを決定するには、`kubectl` コマンドを次のように使用します: `kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'` ## 永続化ボリューム -Minikube supports [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) of type `hostPath`. -These PersistentVolumes are mapped to a directory inside the Minikube VM. +Minikubeは `hostPath` タイプの[PersistentVolumes](/docs/concepts/storage/persistent-volumes/)をサポートします。 +このPersistentVolumesはMinikubeのVM内のディレクトリーにマッピングされます。 -The Minikube VM boots into a tmpfs, so most directories will not be persisted across reboots (`minikube stop`). -However, Minikube is configured to persist files stored under the following host directories: +MinikubeのVMはtmpfsで起動するため、ほとんどのディレクトリーは再起動しても持続しません (`minikube stop`)。 +しかし、Minikubeは以下のホストディレクトリーに保存されているファイルを保持するように設定されています: * `/data` * `/var/lib/minikube` * `/var/lib/docker` -Here is an example PersistentVolume config to persist data in the `/data` directory: +以下は `/data` ディレクトリのデータを永続化するPersistentVolumeの設定例です: ```yaml apiVersion: v1 @@ -331,10 +368,10 @@ spec: ``` ## ホストフォルダーのマウント -Some drivers will mount a host folder within the VM so that you can easily share files between the VM and host. These are not configurable at the moment and different for the driver and OS you are using. +一部のドライバーはVM内にホストフォルダーをマウントするため、VMとホストの間でファイルを簡単に共有できます。これらは現時点では設定可能ではなく、使用しているドライバーとOSによって異なります。 {{< note >}} -Host folder sharing is not implemented in the KVM driver yet. +ホストフォルダーの共有はKVMドライバーにはまだ実装されていません。 {{< /note >}} | Driver | OS | HostFolder | VM | @@ -347,62 +384,61 @@ Host folder sharing is not implemented in the KVM driver yet. ## プライベートコンテナレジストリ -To access a private container registry, follow the steps on [this page](/docs/concepts/containers/images/). +プライベートコンテナレジストリにアクセスするには、[このページ](/docs/concepts/containers/images/)の手順に従ってください。 -We recommend you use `ImagePullSecrets`, but if you would like to configure access on the Minikube VM you can place the `.dockercfg` in the `/home/docker` directory or the `config.json` in the `/home/docker/.docker` directory. +`ImagePullSecrets` を使用することをおすすめしますが、MinikubeのVM内でアクセス設定したい場合には、`/home/docker` ディレクトリに `.dockercfg` を置くか、または `/home/docker/.docker` ディレクトリに `config.json` を置いてください。 ## アドオン -In order to have Minikube properly start or restart custom addons, -place the addons you wish to be launched with Minikube in the `~/.minikube/addons` -directory. Addons in this folder will be moved to the Minikube VM and -launched each time Minikube is started or restarted. +カスタムアドオンを正しく起動または再起動させるには、 +Minikubeで起動したいアドオンを `~/.minikube/addons` ディレクトリに置きます。 +このフォルダ内のアドオンはMinikubeのVMに移動され、Minikubeが起動または再起動されるたびにアドオンが起動されます。 ## HTTPプロキシ経由のMinikube利用 -Minikube creates a Virtual Machine that includes Kubernetes and a Docker daemon. -When Kubernetes attempts to schedule containers using Docker, the Docker daemon may require external network access to pull containers. +MinikubeはKubernetesとDockerデーモンを含む仮想マシンを作成します。 +KubernetesがDockerを使用してコンテナをスケジュールしようとする際、Dockerデーモンはコンテナをプルするために外部ネットワークを必要とする場合があります。 -If you are behind an HTTP proxy, you may need to supply Docker with the proxy settings. -To do this, pass the required environment variables as flags during `minikube start`. +HTTPプロキシーを通している場合には、プロキシー設定をDockerに提供する必要があります。 +これを行うには、`minikube start` に必要な環境変数をフラグとして渡します。 -For example: +例: ```shell -$ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ - --docker-env https_proxy=https://$YOURPROXY:PORT +minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ + --docker-env https_proxy=https://$YOURPROXY:PORT ``` -If your Virtual Machine address is 192.168.99.100, then chances are your proxy settings will prevent `kubectl` from directly reaching it. -To by-pass proxy configuration for this IP address, you should modify your no_proxy settings. You can do so with: +仮想マシンのアドレスが192.168.99.100の場合、プロキシーの設定により `kubectl` が直接アクセスできない可能性があります。 +このIPアドレスのプロキシー設定を迂回するには、以下のようにno_proxy設定を変更する必要があります。 ```shell -$ export no_proxy=$no_proxy,$(minikube ip) +export no_proxy=$no_proxy,$(minikube ip) ``` ## 既知の問題 -* Features that require a Cloud Provider will not work in Minikube. These include: - * LoadBalancers -* Features that require multiple nodes. These include: - * Advanced scheduling policies +* クラウドプロバイダーを必要とする機能はMinikubeでは動作しません + * ロードバランサー +* 複数ノードを必要とする機能 + * 高度なスケジューリングポリシー ## 設計 -Minikube uses [libmachine](https://github.com/docker/machine/tree/master/libmachine) for provisioning VMs, and [kubeadm](https://github.com/kubernetes/kubeadm) to provision a Kubernetes cluster. +MinikubeはVMのプロビジョニングに[libmachine](https://github.com/docker/machine/tree/master/libmachine)を使用し、[kubeadm](https://github.com/kubernetes/kubeadm)をKubernetesクラスターのプロビジョニングに使用します。 -For more information about Minikube, see the [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md). +Minikubeの詳細については、[proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md)を参照してください。 ## 追加リンク集 -* **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md). -* **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests. -* **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md). -* **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md). -* **Adding a New Addon**: For instruction on how to add a new addon for Minikube see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md). -* **Updating Kubernetes**: For instructions on how to update Kubernetes see the [updating Kubernetes guide](https://git.k8s.io/minikube/docs/contributors/updating_kubernetes.md). +* **目標と非目標**: Minikubeプロジェクトの目標と非目標については、[ロードマップ](https://git.k8s.io/minikube/docs/contributors/roadmap.md)を参照してください。 +* **開発ガイド**: プルリクエストを送る方法の概要については、[CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md)を参照してください。 +* **Minikubeのビルド**: Minikubeをソースからビルド/テストする方法については、[ビルドガイド](https://git.k8s.io/minikube/docs/contributors/build_guide.md)を参照してください。 +* **新しい依存性の追加**: Minikubeに新しい依存性を追加する方法については、[依存性追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)を参照してください。 +* **新しいアドオンの追加**: Minikubeに新しいアドオンを追加する方法については、[アドオン追加ガイド](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)を参照してください。 +* **MicroK8s**: 仮想マシンを実行したくないLinuxユーザーは代わりに[MicroK8s](https://microk8s.io/)を検討してみてください。 ## コミュニティ -Contributions, questions, and comments are all welcomed and encouraged! Minikube developers hang out on [Slack](https://kubernetes.slack.com) in the #minikube channel (get an invitation [here](http://slack.kubernetes.io/)). We also have the [kubernetes-dev Google Groups mailing list](https://groups.google.com/forum/#!forum/kubernetes-dev). If you are posting to the list please prefix your subject with "minikube: ". +コントリビューションや質問、コメントは歓迎・奨励されています! Minikubeの開発者は[Slack](https://kubernetes.slack.com)の#minikubeチャンネルにいます(Slackへの招待状は[こちら](http://slack.kubernetes.io/))。[kubernetes-dev Google Groupsメーリングリスト](https://groups.google.com/forum/#!forum/kubernetes-dev)もあります。メーリングリストに投稿する際は件名の最初に "minikube: " をつけてください。 {{% /capture %}} diff --git a/content/ja/docs/setup/multiple-zones.md b/content/ja/docs/setup/multiple-zones.md index 951111f312..1c02785ac5 100644 --- a/content/ja/docs/setup/multiple-zones.md +++ b/content/ja/docs/setup/multiple-zones.md @@ -1,8 +1,17 @@ --- title: 複数のゾーンで動かす weight: 90 +content_template: templates/concept --- +{{% capture overview %}} + +This page describes how to run a cluster in multiple zones. + +{{% /capture %}} + +{{% capture body %}} + ## 始めに Kubernetes 1.2 adds support for running a single cluster in multiple failure zones @@ -23,8 +32,6 @@ add similar support for other clouds or even bare metal, by simply arranging for the appropriate labels to be added to nodes and volumes). -{{< toc >}} - ## 機能性 When nodes are started, the kubelet automatically adds labels to them with @@ -118,14 +125,17 @@ labels are `failure-domain.beta.kubernetes.io/region` for the region, and `failure-domain.beta.kubernetes.io/zone` for the zone: ```shell -> kubectl get nodes --show-labels +kubectl get nodes --show-labels +``` +The output is similar to this: +```shell NAME STATUS ROLES AGE VERSION LABELS -kubernetes-master Ready,SchedulingDisabled 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master -kubernetes-minion-87j9 Ready 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 -kubernetes-minion-9vlv Ready 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv -kubernetes-minion-a12q Ready 6m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q +kubernetes-master Ready,SchedulingDisabled 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master +kubernetes-minion-87j9 Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 +kubernetes-minion-9vlv Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv +kubernetes-minion-a12q Ready 6m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q ``` ### 2つ目のゾーンにさらにノードを追加 @@ -154,16 +164,20 @@ View the nodes again; 3 more nodes should have launched and be tagged in us-central1-b: ```shell -> kubectl get nodes --show-labels +kubectl get nodes --show-labels +``` +The output is similar to this: + +```shell NAME STATUS ROLES AGE VERSION LABELS -kubernetes-master Ready,SchedulingDisabled 16m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master -kubernetes-minion-281d Ready 2m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d -kubernetes-minion-87j9 Ready 16m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 -kubernetes-minion-9vlv Ready 16m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv -kubernetes-minion-a12q Ready 17m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q -kubernetes-minion-pp2f Ready 2m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f -kubernetes-minion-wf8i Ready 2m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i +kubernetes-master Ready,SchedulingDisabled 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master +kubernetes-minion-281d Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d +kubernetes-minion-87j9 Ready 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9 +kubernetes-minion-9vlv Ready 16m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv +kubernetes-minion-a12q Ready 17m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q +kubernetes-minion-pp2f Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f +kubernetes-minion-wf8i Ready 2m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i ``` ### ボリュームのアフィニティ @@ -204,10 +218,15 @@ always created in the zone of the cluster master was addressed in 1.3+. {{< /note >}} -Now lets validate that Kubernetes automatically labeled the zone & region the PV was created in. +Now let's validate that Kubernetes automatically labeled the zone & region the PV was created in. + +```shell +kubectl get pv --show-labels +``` + +The output is similar to this: ```shell -> kubectl get pv --show-labels NAME CAPACITY ACCESSMODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE LABELS pv-gce-mj4gm 5Gi RWO Retain Bound default/claim1 manual 46s failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a ``` @@ -240,9 +259,20 @@ Note that the pod was automatically created in the same zone as the volume, as cross-zone attachments are not generally permitted by cloud providers: ```shell -> kubectl describe pod mypod | grep Node +kubectl describe pod mypod | grep Node +``` + +```shell Node: kubernetes-minion-9vlv/10.240.0.5 -> kubectl get node kubernetes-minion-9vlv --show-labels +``` + +And check node labels: + +```shell +kubectl get node kubernetes-minion-9vlv --show-labels +``` + +```shell NAME STATUS AGE VERSION LABELS kubernetes-minion-9vlv Ready 22m v1.6.0+fff5156 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv ``` @@ -279,16 +309,24 @@ find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl crea The pods should be spread across all 3 zones: ```shell -> kubectl describe pod -l app=guestbook | grep Node +kubectl describe pod -l app=guestbook | grep Node +``` + +```shell Node: kubernetes-minion-9vlv/10.240.0.5 Node: kubernetes-minion-281d/10.240.0.8 Node: kubernetes-minion-olsh/10.240.0.11 +``` - > kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels +```shell +kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels +``` + +```shell NAME STATUS ROLES AGE VERSION LABELS -kubernetes-minion-9vlv Ready 34m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv -kubernetes-minion-281d Ready 20m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d -kubernetes-minion-olsh Ready 3m v1.12.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh +kubernetes-minion-9vlv Ready 34m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv +kubernetes-minion-281d Ready 20m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d +kubernetes-minion-olsh Ready 3m v1.13.0 beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh ``` @@ -296,15 +334,42 @@ Load-balancers span all zones in a cluster; the guestbook-go example includes an example load-balanced service: ```shell -> kubectl describe service guestbook | grep LoadBalancer.Ingress +kubectl describe service guestbook | grep LoadBalancer.Ingress +``` + +The output is similar to this: + +```shell LoadBalancer Ingress: 130.211.126.21 +``` -> ip=130.211.126.21 +Set the above IP: -> curl -s http://${ip}:3000/env | grep HOSTNAME +```shell +export IP=130.211.126.21 +``` + +Explore with curl via IP: + +```shell +curl -s http://${IP}:3000/env | grep HOSTNAME +``` + +The output is similar to this: + +```shell "HOSTNAME": "guestbook-44sep", +``` -> (for i in `seq 20`; do curl -s http://${ip}:3000/env | grep HOSTNAME; done) | sort | uniq +Again, explore multiple times: + +```shell +(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done) | sort | uniq +``` + +The output is similar to this: + +```shell "HOSTNAME": "guestbook-44sep", "HOSTNAME": "guestbook-hum5n", "HOSTNAME": "guestbook-ppm40", @@ -331,3 +396,5 @@ KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c k KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh ``` + +{{% /capture %}} diff --git a/content/ja/docs/setup/on-premises-metal/krib.md b/content/ja/docs/setup/on-premises-metal/krib.md index 4a8425ead7..5d8a2ef688 100644 --- a/content/ja/docs/setup/on-premises-metal/krib.md +++ b/content/ja/docs/setup/on-premises-metal/krib.md @@ -8,7 +8,7 @@ author: Rob Hirschfeld (zehicle) This guide helps to install a Kubernetes cluster hosted on bare metal with [Digital Rebar Provision](https://github.com/digitalrebar/provision) using only its Content packages and *kubeadm*. -Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](../kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib). +Digital Rebar Provision (DRP) is an integrated Golang DHCP, bare metal provisioning (PXE/iPXE) and workflow automation platform. While [DRP can be used to invoke](https://provision.readthedocs.io/en/tip/doc/integrations/ansible.html) [kubespray](/docs/setup/custom-cloud/kubespray), it also offers a self-contained Kubernetes installation known as [KRIB (Kubernetes Rebar Integrated Bootstrap)](https://github.com/digitalrebar/provision-content/tree/master/krib). {{< note >}} KRIB is not a _stand-alone_ installer: Digital Rebar templates drive a standard *[kubeadm](/docs/admin/kubeadm/)* configuration that manages the Kubernetes installation with the [Digital Rebar cluster pattern](https://provision.readthedocs.io/en/tip/doc/arch/cluster.html#rs-cluster-pattern) to elect leaders _without external supervision_. @@ -92,4 +92,4 @@ When running the reset Workflow, be sure not to accidentally target your product ## フィードバック * Slack Channel: [#community](https://rackn.slack.com/messages/community/) -* [GitHub Issues](https://github.com/digital/provision/issues) +* [GitHub Issues](https://github.com/digitalrebar/provision/issues) diff --git a/content/ja/docs/setup/pick-right-solution.md b/content/ja/docs/setup/pick-right-solution.md index b92ddcb51a..f9399f1258 100644 --- a/content/ja/docs/setup/pick-right-solution.md +++ b/content/ja/docs/setup/pick-right-solution.md @@ -2,25 +2,36 @@ title: 正しいソリューションの選択 weight: 10 content_template: templates/concept +card: + name: setup + weight: 20 + anchors: + - anchor: "#ホスティングを使ったソリューション" + title: ホスティングを使ったソリューション + - anchor: "#すぐに利用できるクラウドを使ったソリューション" + title: すぐに利用できるクラウドを使ったソリューション + - anchor: "#すぐに利用できるオンプレミスを使ったソリューション" + title: すぐに利用できるオンプレミスを使ったソリューション + - anchor: "#カスタムソリューション" + title: カスタムソリューション + - anchor: "#ローカルマシンを使ったソリューション" + title: ローカルマシンを使ったソリューション --- {{% capture overview %}} -Kubernetes can run on various platforms: from your laptop, to VMs on a cloud provider, to a rack of -bare metal servers. The effort required to set up a cluster varies from running a single command to -crafting your own customized cluster. Use this guide to choose a solution that fits your needs. +Kubernetesは様々なプラットフォームで動作することができます: PCから、クラウドプロバイダーのVM、ベアメタルサーバーのラックまで。 +クラスターをセットアップするために必要な作業は、単一のコマンドを実行することからカスタマイズされたクラスターを作り上げるまで異なります。このガイドを使用して、ニーズに合ったソリューションを選択してください。 -If you just want to "kick the tires" on Kubernetes, use the [local Docker-based solutions](#local-machine-solutions). +Kubernetesを少し試したいだけであれば、[ローカルマシンを使ったソリューション](#ローカルマシンを使ったソリューション)を使用してください。 -When you are ready to scale up to more machines and higher availability, a [hosted solution](#hosted-solutions) is the easiest to create and maintain. +より多くのマシンと高い可用性にスケールアップする準備がある場合、[ホスティングを使ったソリューション](#ホスティングを使ったソリューション)で作成して保守するのが最も簡単です。 -[Turnkey cloud solutions](#turnkey-cloud-solutions) require only a few commands to create -and cover a wide range of cloud providers. [On-Premises turnkey cloud solutions](#on-premises-turnkey-cloud-solutions) have the simplicity of the turnkey cloud solution combined with the security of your own private network. +[すぐに利用できるクラウドを使ったソリューション](#すぐに利用できるクラウドを使ったソリューション)は様々なクラウドプロバイダーを作成してカバーするために必要なコマンドはわずかで済みます。[すぐに利用できるオンプレミスを使ったソリューション](#すぐに利用できるオンプレミスを使ったソリューション)には、プライベートネットワークのセキュリティと組み合わせたすぐに利用できるクラウドソリューションのシンプルさがあります。 -If you already have a way to configure hosting resources, use [kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster with a single command per machine. +すでにホスティングサービスを設定する方法がある場合は、[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)を使用して、マシン毎に単一のコマンドでクラスターを簡単に起動できます。 -[Custom solutions](#custom-solutions) vary from step-by-step instructions to general advice for setting up -a Kubernetes cluster from scratch. +[カスタムソリューション](#カスタムソリューション)は段階的な手順からセットアップの一般的なアドバイスまで様々あります。 {{% /capture %}} @@ -28,58 +39,73 @@ a Kubernetes cluster from scratch. ## ローカルマシンを使ったソリューション -* [Minikube](/docs/setup/minikube/) is a method for creating a local, single-node Kubernetes cluster for development and testing. Setup is completely automated and doesn't require a cloud provider account. +* [Minikube](/docs/setup/minikube/)は開発とテスト用にローカルの単一ノードのKubernetesクラスターを作成するための方法です。セットアップは完全に自動化されており、クラウドプロバイダーのアカウントは必要ありません。 -* [microk8s](https://microk8s.io/) provides a single command installation of the latest Kubernetes release on a local machine for development and testing. Setup is quick, fast (~30 sec) and supports many plugins including Istio with a single command. +* [Docker Desktop](https://www.docker.com/products/docker-desktop)は +MacまたはWindows環境に簡単にインストールできるアプリケーションで、 +単一ノードのKubernetesクラスターを使用して、 +数分でコーディングとコンテナへのデプロイを開始できます。 -* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) can use VirtualBox on your machine to deploy Kubernetes to one or more VMs for development and test scenarios. Scales to full multi-node cluster. +* [Minishift](https://docs.okd.io/latest/minishift/)は、ローカル開発およびテスト用にKubernetesエンタープライズプラットフォームのOpenShiftのコミュニティーバージョンをインストールします。Windows、MacOS、Linux用のオールインワンのVM (`minishift start`)を提供します。コンテナの起動は`oc cluster up`に基づいています (Linuxのみ)。[付属のアドオン](https://github.com/minishift/minishift-addons/tree/master/add-ons)をインストールすることもできます。 -* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers) is a Terraform/Packer/BASH based Infrastructure as Code (IaC) scripts to create a seven node (1 Boot, 1 Master, 1 Management, 1 Proxy and 3 Workers) LXD cluster on Linux Host. +* [MicroK8s](https://microk8s.io/)は、開発とテスト用にローカルマシンに最新リリースのKubernetesを単一コマンドでのインストールを可能にします。セットアップは素早く、速く(〜30秒)て、lstioを含む多くのプラグインを単一コマンドでサポートします。 -* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) is a multi-node (while minikube is single-node) Kubernetes cluster which only requires a docker daemon. It uses docker-in-docker technique to spawn the Kubernetes cluster. +* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private)は、開発とテストシナリオ用に、ご自身のマシンでVirtualBoxを使って1つ以上のVMにKubernetesをデプロイすることができます。フルマルチノードのクラスターに拡張します。 -* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/) supports a nine-instance deployment on localhost. +* [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)は、Linuxホスト上に7ノード(1ブート、1マスター、1マネジメント、1プロキシー、3ワーカー)のLXDクラスターを作成するためのTerraform/Packer/BASHベースのInfrastructure as Code（IaC）のスクリプトです。 + +* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster)は、(Minikubeが単一ノードであることに対して)マルチノードのKubernetesクラスターで、Dockerデーモンのみが必要です。Kubernetesクラスターを生成するためにdocker-in-docker技術を使います。 + +* [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)は、ローカルホスト上の9インスタンスのデプロイをサポートします。 ## ホスティングを使ったソリューション -* [AppsCode.com](https://appscode.com/products/cloud-deployment/) provides managed Kubernetes clusters for various public clouds, including AWS and Google Cloud Platform. +* [AppsCode.com](https://appscode.com/products/cloud-deployment/)は、AWSやGoogle Cloud Platformなどの様々なパブリッククラウド用のマネージドなKubernetesクラスターを提供します。 -* [APPUiO](https://appuio.ch) runs an OpenShift public cloud platform, supporting any Kubernetes workload. Additionally APPUiO offers Private Managed OpenShift Clusters, running on any public or private cloud. +* [APPUiO](https://appuio.ch)は、OpenShiftのパブリッククラウドプラットフォームを実行し、あらゆるKubernetesワークロードをサポートします。さらにAPPUiOは、パブリッククラウドまたはプライベートクラウド上で動作するPrivate Managed OpenShift Clustersを提供します。 -* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/) offers managed Kubernetes service. +* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/)は、マネージドなKubernetesサービスを提供します。 -* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/) offers managed Kubernetes clusters. +* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/)は、マネージドなKubernetesクラスターを提供します。 -* [Giant Swarm](https://giantswarm.io/product/) offers managed Kubernetes clusters in their own datacenter, on-premises, or on public clouds. +* [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform) GCP、Azure、AWS、Packet、DigitalOceanでの直感的なKubernetesクラスターのプロビジョニングと管理。シームレスなバージョンアップグレード、自動スケーリング、メトリック、ワークロードの作成など。 -* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) offers managed Kubernetes clusters. +* [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/)は、マネージドなKubernetesサービスを提供します。 -* [IBM Cloud Kubernetes Service](https://console.bluemix.net/docs/containers/container_index.html) offers managed Kubernetes clusters with isolation choice, operational tools, integrated security insight into images and containers, and integration with Watson, IoT, and data. +* [Giant Swarm](https://giantswarm.io/product/)は、独自のデータセンター、オンプレミス、またはパブリッククラウド上にマネージドなKubernetesクラスターを提供します。 -* [Kubermatic](https://www.loodse.com) provides managed Kubernetes clusters for various public clouds, including AWS and Digital Ocean, as well as on-premises with OpenStack integration. +* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/)は、マネージドなKubernetesクラスターを提供します。 -* [Kublr](https://kublr.com) offers enterprise-grade secure, scalable, highly reliable Kubernetes clusters on AWS, Azure, GCP, and on-premise. It includes out-of-the-box backup and disaster recovery, multi-cluster centralized logging and monitoring, and built-in alerting. +* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index)は、アイソレーションの選択、運用ツール、イメージとコンテナーへの統合されたセキュリティーのインサイト、およびWatson、IoT、データとの統合を備えたマネージドなKubernetesクラスターを提供します。 -* [Madcore.Ai](https://madcore.ai) is devops-focused CLI tool for deploying Kubernetes infrastructure in AWS. Master, auto-scaling group nodes with spot-instances, ingress-ssl-lego, Heapster, and Grafana. +* [Kubermatic](https://www.loodse.com)は、AWSやDigital Oceanなどの様々なパブリッククラウド用のマネージドなKubernetesクラスターを提供するだけでなく、OpenStackと統合されたオンプレミスも提供します。 -* [OpenShift Dedicated](https://www.openshift.com/dedicated/) offers managed Kubernetes clusters powered by OpenShift. +* [Kublr](https://kublr.com)は、AWS、Azure、GCP、およびオンプレミスで、エンタープライズ級の安全でスケーラブルで信頼性の高いKubernetesクラスターを提供します。すぐに使用可能なバックアップとディザスターリカバリ、集中管理されたマルチクラスターのログ記録とモニタリング、および組み込みのアラートが含まれます。 -* [OpenShift Online](https://www.openshift.com/features/) provides free hosted access for Kubernetes applications. +* [KubeSail](https://kubesail.com)は、簡単にKubernetesを試すことができる近道です。 -* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm) is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. +* [Madcore.Ai](https://madcore.ai)は、AWSにKubernetesインフラストラクチャーをデプロイするためのDevOpsにフォーカスしたCLIツールです。マスター、スポットインスタンスを使ったオートスケーリンググループのノード、ingress-ssl-lego、Heapster、およびGrafana。 -* [Platform9](https://platform9.com/products/kubernetes/) offers managed Kubernetes on-premises or on any public cloud, and provides 24/7 health monitoring and alerting. (Kube2go, a web-UI driven Kubernetes cluster deployment service Platform9 released, has been integrated to Platform9 Sandbox.) +* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)は、Kubernetesのプロビジョニング、運用、ライフサイクル管理を簡素化する、マルチクラスターで可用性の高いKubernetes管理および運用プラットフォームです。 -* [Stackpoint.io](https://stackpoint.io) provides Kubernetes infrastructure automation and management for multiple public clouds. +* [OpenShift Dedicated](https://www.openshift.com/dedicated/)は、OpenShiftを搭載したマネージドなKubernetesクラスターを提供します。 -* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offers managed Kubernetes as a service powered on our OpenStack public cloud. It includes lifecycle management, administration dashboards, monitoring, autoscaling and much more. +* [OpenShift Online](https://www.openshift.com/features/)は、Kubernetesアプリケーションに無料のホストアクセスを提供します。 -* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) is an enterprise Kubernetes-as-a-Service offering in the VMware Cloud Services portfolio that provides easy to use, secure by default, cost effective, SaaS-based Kubernetes clusters. +* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)は、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、フルマネージドかつスケーラブルで可用性の高いサービスです。 + +* [Platform9](https://platform9.com/products/kubernetes/)は、オンプレミスまたはパブリッククラウド上でマネージドなKubernetesを提供し、24時間365日のヘルスモニタリングとアラートを提供します。（Kube2goは、Web UIによって駆動されるKubernetesクラスターデプロイメントサービスであるPlatform9がリリースされ、Platform9 Sandboxに統合されました） + +* [Stackpoint.io](https://stackpoint.io)は、複数のパブリッククラウドに対してKubernetesインフラストラクチャーの自動化と管理を提供します。 + +* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)は、OpenStackのパブリッククラウドを基盤とするサービスとしてマネージドなKubernetesを提供します。ライフサイクル管理、管理ダッシュボード、モニタリング、自動スケーリングなどが含まれます。 + +* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)は、VMware Cloud ServicesポートフォリオのエンタープライズのKubernetes-as-a-Serviceであり、使いやすく、デフォルトで安全、かつ費用対効果の高いSaaSベースのKubernetesクラスターを提供します。 ## すぐに利用できるクラウドを使ったソリューション -These solutions allow you to create Kubernetes clusters on a range of Cloud IaaS providers with only a -few commands. These solutions are actively developed and have active community support. +これらのソリューションを使用すると、ほんの少しのコマンドで、様々なCloud IaaSプロバイダー上にKubernetesクラスターを作成できます。 +これらのソリューションはアクティブに開発されており、またアクティブなコミュニティー支援を受けています。 * [Agile Stacks](https://www.agilestacks.com/products/kubernetes) * [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/) @@ -88,108 +114,128 @@ few commands. These solutions are actively developed and have active community s * [Azure](/docs/setup/turnkey/azure/) * [CenturyLink Cloud](/docs/setup/turnkey/clc/) * [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](/docs/getting-started-guides/ubuntu/) +* [Containership](https://containership.io/containership-platform) +* [Docker Enterprise](https://www.docker.com/products/docker-enterprise) * [Gardener](https://gardener.cloud/) +* [Giant Swarm](https://giantswarm.io) * [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/) * [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer) * [Kontena Pharos](https://kontena.io/pharos/) * [Kubermatic](https://cloud.kubermatic.io) * [Kublr](https://kublr.com/) * [Madcore.Ai](https://madcore.ai/) +* [Nirmata](https://nirmata.com/) +* [Nutanix Karbon](https://www.nutanix.com/products/karbon/) * [Oracle Container Engine for K8s](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm) * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) -* [Giant Swarm](https://giantswarm.io) * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) * [Stackpoint.io](/docs/setup/turnkey/stackpoint/) +* [Supergiant.io](https://supergiant.io/) * [Tectonic by CoreOS](https://coreos.com/tectonic) +* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) +* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) ## すぐに利用できるオンプレミスを使ったソリューション -These solutions allow you to create Kubernetes clusters on your internal, secure, cloud network with only a -few commands. +これらのソリューションは、内部の安全なクラウドネットワーク上にKubernetesクラスターをほんのわずかのコマンドで作成することを可能にします。 * [Agile Stacks](https://www.agilestacks.com/products/kubernetes) * [APPUiO](https://appuio.ch) +* [Docker Enterprise](https://www.docker.com/products/docker-enterprise) +* [Giant Swarm](https://giantswarm.io) * [GKE On-Prem | Google Cloud](https://cloud.google.com/gke-on-prem/) * [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/) * [Kontena Pharos](https://kontena.io/pharos/) * [Kubermatic](https://www.loodse.com) -* [Kublr](https://kublr.com/) +* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution) +* [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) +* [Nirmata](https://nirmata.com/) +* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com) * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) -* [Giant Swarm](https://giantswarm.io) * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) * [SUSE CaaS Platform](https://www.suse.com/products/caas-platform) * [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/) +* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) ## カスタムソリューション -Kubernetes can run on a wide range of Cloud providers and bare-metal environments, and with many -base operating systems. +Kubernetesは、幅広いクラウドプロバイダーやベアメタル環境、 +そして多くの基本オペレーティングシステム上で実行できます。 -If you can find a guide below that matches your needs, use it. It may be a little out of date, but -it will be easier than starting from scratch. If you do want to start from scratch, either because you -have special requirements, or just because you want to understand what is underneath a Kubernetes -cluster, try the [Getting Started from Scratch](/docs/setup/release/building-from-source/) guide. - -If you are interested in supporting Kubernetes on a new platform, see -[Writing a Getting Started Guide](https://git.k8s.io/community/contributors/devel/writing-a-getting-started-guide.md). +もし以下のガイドからニーズに合ったものを見つけることができたなら、それを使ってください。 +少し古くなっているかもしれませんが最初から始めるよりも簡単です。特別な要件があるため、 +またはKubernetesクラスターの下にあるものを理解したいために最初から始める必要がある場合は、 +[ゼロからのカスタムクラスターの作成](/ja/docs/setup/scratch/)を試してください。 ### 全般 -If you already have a way to configure hosting resources, use -[kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster -with a single command per machine. +ホスティングリソースを設定する方法がすでにある場合は、 +[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)を使用して +マシン毎に単一のコマンドでクラスターを起動します。 ### クラウド -These solutions are combinations of cloud providers and operating systems not covered by the above solutions. +これらのソリューションは、上記のソリューションでカバーされていないクラウドプロバイダーとオペレーティングシステムの組み合わせです。 +* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) * [CoreOS on AWS or GCE](/docs/setup/custom-cloud/coreos/) * [Gardener](https://gardener.cloud/) -* [Kublr](https://kublr.com/) +* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) * [Kubespray](/docs/setup/custom-cloud/kubespray/) * [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke) +* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS) ### オンプレミスの仮想マシン -* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (uses Ansible, CoreOS and flannel) -* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (uses Fedora and flannel) +* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) +* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (Ansible、CoreOSとflannelを使用します) +* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (Fedoraとflannelを使用します) +* [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/) +* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) * [oVirt](/docs/setup/on-premises-vm/ovirt/) -* [Vagrant](/docs/setup/custom-cloud/coreos/) (uses CoreOS and flannel) -* [VMware](/docs/setup/custom-cloud/coreos/) (uses CoreOS and flannel) +* [Vagrant](/docs/setup/custom-cloud/coreos/) (CoreOSとflannelを使用します) +* [VMware](/docs/setup/custom-cloud/coreos/) (CoreOSとflannelを使用します) +* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS) * [VMware vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) -* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (uses Juju, Ubuntu and flannel) +* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (Juju、Ubuntuとflannelを使用します) ### ベアメタル * [CoreOS](/docs/setup/custom-cloud/coreos/) * [Digital Rebar](/docs/setup/on-premises-metal/krib/) +* [Docker Enterprise](https://www.docker.com/products/docker-enterprise) * [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/) * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) +* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) +* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS) ### 統合 -These solutions provide integration with third-party schedulers, resource managers, and/or lower level platforms. +これらのソリューションは、サードパーティー製のスケジューラー、リソースマネージャー、および/または低レベルのプラットフォームとの統合を提供します。 * [DCOS](/docs/setup/on-premises-vm/dcos/) - * Community Edition DCOS uses AWS - * Enterprise Edition DCOS supports cloud hosting, on-premises VMs, and bare metal + * Community Edition DCOSは、AWSを使用します + * Enterprise Edition DCOSは、クラウドホスティング、オンプレミスのVM、およびベアメタルをサポートします ## ソリューションの表 -Below is a table of all of the solutions listed above. +以下は上記のソリューションすべての表です。 -IaaS Provider | Config. Mgmt. | OS | Networking | Docs | Support Level +IaaS プロバイダー | 構成管理 | OS | ネットワーク| ドキュメント | サポートレベル -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------------------------- any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle)) Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial +Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial +IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) | +Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial -IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://console.bluemix.net/docs/containers/) | Commercial +IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial @@ -223,31 +269,30 @@ any | RKE | multi-support | flannel or canal any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/) Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial -IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://console.bluemix.net/docs/containers/container_index.html) | Commercial +IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar)) VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial +VMware Enterprise PKS | BOSH | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial +Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial {{< note >}} -The above table is ordered by version test/used in nodes, followed by support level. +上記の表はバージョンテスト/ノード内での使用順に並べられ、その後にサポートレベルが続きます。 {{< /note >}} ### カラムの定義 -* **IaaS Provider** is the product or organization which provides the virtual or physical machines (nodes) that Kubernetes runs on. -* **OS** is the base operating system of the nodes. -* **Config. Mgmt.** is the configuration management system that helps install and maintain Kubernetes on the - nodes. -* **Networking** is what implements the [networking model](/docs/concepts/cluster-administration/networking/). Those with networking type - _none_ may not support more than a single node, or may support multiple VM nodes in a single physical node. -* **Conformance** indicates whether a cluster created with this configuration has passed the project's conformance - tests for supporting the API and base features of Kubernetes v1.0.0. -* **Support Levels** - * **Project**: Kubernetes committers regularly use this configuration, so it usually works with the latest release - of Kubernetes. - * **Commercial**: A commercial offering with its own support arrangements. - * **Community**: Actively supported by community contributions. May not work with recent releases of Kubernetes. - * **Inactive**: Not actively maintained. Not recommended for first-time Kubernetes users, and may be removed. -* **Notes** has other relevant information, such as the version of Kubernetes used. +* **IaaSプロバイダー**は、Kubernetesが動作する仮想マシンまたは物理マシン（ノード）を提供する製品または組織です。 +* **OS**は、ノードのベースのオペレーティングシステムです。 +* **構成管理**は、ノードにKubernetesをインストール・保守するのに役立つ構成管理システムです。 +* **ネットワーク**は、[ネットワークモデル](/docs/concepts/cluster-administration/networking/)を実装したものです。ネットワークタイプが、 + _none_ のものは、複数のノードをサポートしていない場合や、単一の物理ノードで複数のVMノードをサポートしている場合があります。 +* **適合**は、この設定で作成されたクラスターが、Kubernetes v1.0.0のAPIおよび基本機能をサポートするためのプロジェクトの適合性テストに合格したかどうかを示します。 +* **サポートレベル** + * **プロジェクト**: Kubernetesのコミッターは通常この設定を使用しているため、ほとんどの場合Kubernetesの最新リリースで動作します。 + * **商用**: 独自のサポート契約がある商用製品。 + * **コミュニティー**: コミュニティーの貢献によって積極的にサポートされています。 Kubernetesの最近のリリースでは動作しない可能性があります。 + * **非アクティブ**: 積極的にメンテナンスされていません。初めてのKubernetesユーザーにはお勧めできません。削除される可能性があります。 +* **注意事項**には、使用されているKubernetesのバージョンなど、その他の関連情報があります。 diff --git a/content/ja/docs/setup/release/building-from-source.md b/content/ja/docs/setup/release/building-from-source.md index 552be912c0..e9fc081a25 100644 --- a/content/ja/docs/setup/release/building-from-source.md +++ b/content/ja/docs/setup/release/building-from-source.md @@ -1,14 +1,21 @@ --- -title: ソースからのビルド +title: リリースのビルド +content_template: templates/concept +card: + name: download + weight: 20 + title: リリースのビルド --- - -あなたはソースからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。もしあなたがKubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内の現在リリースされている既にビルドされたバージョンを使用することを推奨します。 +{{% capture overview %}} +ソースコードからリリースをビルドすることもできますし、既にビルドされたリリースをダウンロードすることも可能です。Kubernetesを開発する予定が無いのであれば、[リリースノート](/docs/setup/release/notes/)内にて既にビルドされたバージョンを使用することを推奨します。 Kubernetes のソースコードは[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)のリポジトリからダウンロードすることが可能です。 +{{% /capture %}} +{{% capture body %}} ## ソースからのビルド -もしあなたが単にソースからリリースをビルドするだけなのであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。 +単にソースからリリースをビルドするだけであれば、完全なGOの環境を準備する必要はなく、全てのビルドはDockerコンテナの中で行われます。 リリースをビルドすることは簡単です。 @@ -19,3 +26,5 @@ make release ``` リリース手段の詳細な情報はkubernetes/kubernetes内の[`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)ディレクトリを参照して下さい。 + +{{% /capture %}} diff --git a/content/ja/docs/setup/turnkey/alibaba-cloud.md b/content/ja/docs/setup/turnkey/alibaba-cloud.md index ea797c7390..58677dee9d 100644 --- a/content/ja/docs/setup/turnkey/alibaba-cloud.md +++ b/content/ja/docs/setup/turnkey/alibaba-cloud.md @@ -4,9 +4,9 @@ title: Alibaba CloudでKubernetesを動かす ## Alibaba Cloud Container Service -[Alibaba Cloud Container Service](https://www.aliyun.com/product/containerservice)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 +[Alibaba Cloud Container Service](https://www.alibabacloud.com/product/container-service)はAlibaba Cloud ECSインスタンスのクラスター上でDockerアプリケーションを起動して管理します。著名なオープンソースのコンテナオーケストレーターであるDocker SwarmおよびKubernetesをサポートしています。 -クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.aliyun.com/solution/kubernetes/)を使用します。[Kubernetes walk-through](https://help.aliyun.com/document_detail/53751.html)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 +クラスターの構築と管理を簡素化する為に、[Alibaba Cloud Container Serviceの為のKubernetesサポート](https://www.alibabacloud.com/product/kubernetes)を使用します。[Kubernetes walk-through](https://www.alibabacloud.com/help/doc-detail/86737.htm)に従ってすぐに始めることができ、中国語の[Alibaba CloudにおけるKubernetesサポートの為のチュートリアル](https://yq.aliyun.com/teams/11/type_blog-cid_200-page_1)もあります。 カスタムバイナリもしくはオープンソースKubernetesを使用する場合は、以下の手順に従って下さい。 diff --git a/content/ja/docs/setup/turnkey/azure.md b/content/ja/docs/setup/turnkey/azure.md index 6bc8a8d42e..dcf4a4ffb0 100644 --- a/content/ja/docs/setup/turnkey/azure.md +++ b/content/ja/docs/setup/turnkey/azure.md @@ -10,18 +10,18 @@ Azure Kubernetes Serviceを利用してAzure上にKubernetesクラスターを **[Microsoft Azure Kubernetes Service](https://docs.microsoft.com/ja-jp/azure/aks/intro-kubernetes)** -## デプロイのカスタマイズ: ACS-Engine +## デプロイのカスタマイズ: AKS-Engine -Azure Kubernetes Serviceのコア部分は**オープンソース**であり、コミュニティのためにGitHub上で公開され、利用およびコントリビュートすることができます: **[ACS-Engine](https://github.com/Azure/acs-engine)**. +Azure Kubernetes Serviceのコア部分は**オープンソース**であり、コミュニティのためにGitHub上で公開され、利用およびコントリビュートすることができます: **[AKS-Engine](https://github.com/Azure/aks-engine)**。レガシーな [ACS-Engine](https://github.com/Azure/acs-engine) のコードベースはAKS-engineのために廃止となりました。 -ACS-Engineは、Azure Kubernetes Serviceが公式にサポートしている機能を超えてデプロイをカスタマイズしたい場合に適した選択肢です。 +AKS-Engineは、Azure Kubernetes Serviceが公式にサポートしている機能を超えてデプロイをカスタマイズしたい場合に適した選択肢です。 既存の仮想ネットワークへのデプロイや、複数のagent poolを利用するなどのカスタマイズをすることができます。 -コミュニティによるACS-Engineへのコントリビュートが、Azure Kubernetes Serviceに組み込まれる場合もあります。 +コミュニティによるAKS-Engineへのコントリビュートが、Azure Kubernetes Serviceに組み込まれる場合もあります。 -ACS-Engineへの入力は、Azure Kubernetes Serviceを使用してクラスターを直接デプロイすることに利用されるARMテンプレートの構文に似ています。 -処理結果はAzure Resource Managerテンプレートとして出力され、ソース管理に組み込んだり、AzureにKubernetesクラスターをデプロイするために使うことができます。 +AKS-Engineへの入力は、Kubernetesクラスターを記述するapimodelのJSONファイルです。これはAzure Kubernetes Serviceを使用してクラスターを直接デプロイするために使用されるAzure Resource Manager (ARM) のテンプレート構文と似ています。 +処理結果はARMテンプレートとして出力され、ソース管理に組み込んだり、AzureにKubernetesクラスターをデプロイするために使うことができます。 -**[ACS-Engine Kubernetes Walkthrough](https://github.com/Azure/acs-engine/blob/master/docs/kubernetes.md)** を参照して、すぐに始めることができます。 +**[AKS-Engine Kubernetes Tutorial](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/README.md)** を参照して始めることができます。 ## Azure上でCoreOS Tectonicを動かす diff --git a/content/ja/docs/setup/turnkey/clc.md b/content/ja/docs/setup/turnkey/clc.md index cf28775224..d598f3bd7d 100644 --- a/content/ja/docs/setup/turnkey/clc.md +++ b/content/ja/docs/setup/turnkey/clc.md @@ -288,7 +288,7 @@ Various configuration files are written into the home directory *CLC_CLUSTER_HOM to access the cluster from machines other than where you created the cluster from. * ```config/```: Ansible variable files containing parameters describing the master and minion hosts -* ```hosts/```: hosts files listing access information for the ansible playbooks +* ```hosts/```: hosts files listing access information for the Ansible playbooks * ```kube/```: ```kubectl``` configuration files, and the basic-authentication password for admin access to the Kubernetes API * ```pki/```: public key infrastructure files enabling TLS communication in the cluster * ```ssh/```: SSH keys for root access to the hosts diff --git a/content/ja/docs/setup/turnkey/gce.md b/content/ja/docs/setup/turnkey/gce.md index 3f0b5082da..bd926dfa11 100644 --- a/content/ja/docs/setup/turnkey/gce.md +++ b/content/ja/docs/setup/turnkey/gce.md @@ -5,7 +5,7 @@ content_template: templates/task {{% capture overview %}} -The example below creates a Kubernetes cluster with 4 worker node Virtual Machines and a master Virtual Machine (i.e. 5 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient). +The example below creates a Kubernetes cluster with 3 worker node Virtual Machines and a master Virtual Machine (i.e. 4 VMs in your cluster). This cluster is set up and controlled from your workstation (or wherever you find convenient). {{% /capture %}} @@ -161,7 +161,7 @@ Likewise, the `kube-up.sh` in the same directory will bring it back up. You do n ## カスタマイズ The script above relies on Google Storage to stage the Kubernetes release. It -then will start (by default) a single master VM along with 4 worker VMs. You +then will start (by default) a single master VM along with 3 worker VMs. You can tweak some of these parameters by editing `kubernetes/cluster/gce/config-default.sh` You can view a transcript of a successful cluster creation [here](https://gist.github.com/satnam6502/fc689d1b46db9772adea). diff --git a/content/ja/docs/setup/turnkey/icp.md b/content/ja/docs/setup/turnkey/icp.md new file mode 100644 index 0000000000..79783a6364 --- /dev/null +++ b/content/ja/docs/setup/turnkey/icp.md @@ -0,0 +1,67 @@ +--- +title: IBM Cloud Privateを使ってマルチクラウドでKubernetesを動かす +--- + +IBM® Cloud Private is a turnkey cloud solution and an on-premises turnkey cloud solution. IBM Cloud Private delivers pure upstream Kubernetes with the typical management components that are required to run real enterprise workloads. These workloads include health management, log management, audit trails, and metering for tracking usage of workloads on the platform. + +IBM Cloud Private is available in a community edition and a fully supported enterprise edition. The community edition is available at no charge from [Docker Hub](https://hub.docker.com/r/ibmcom/icp-inception/). The enterprise edition supports high availability topologies and includes commercial support from IBM for Kubernetes and the IBM Cloud Private management platform. If you want to try IBM Cloud Private, you can use either the hosted trial, the tutorial, or the self-guided demo. You can also try the free community edition. For details, see [Get started with IBM Cloud Private](https://www.ibm.com/cloud/private/get-started). + +For more information, explore the following resources: + +* [IBM Cloud Private](https://www.ibm.com/cloud/private) +* [Reference architecture for IBM Cloud Private](https://github.com/ibm-cloud-architecture/refarch-privatecloud) +* [IBM Cloud Private documentation](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) + +## IBM Cloud PrivateとTerraform + +The following modules are available where you can deploy IBM Cloud Private by using Terraform: + +* AWS: [Deploy IBM Cloud Private to AWS](https://github.com/ibm-cloud-architecture/terraform-icp-aws) +* Azure: [Deploy IBM Cloud Private to Azure](https://github.com/ibm-cloud-architecture/terraform-icp-azure) +* IBM Cloud: [Deploy IBM Cloud Private cluster to IBM Cloud](https://github.com/ibm-cloud-architecture/terraform-icp-ibmcloud) +* OpenStack: [Deploy IBM Cloud Private to OpenStack](https://github.com/ibm-cloud-architecture/terraform-icp-openstack) +* Terraform module: [Deploy IBM Cloud Private on any supported infrastructure vendor](https://github.com/ibm-cloud-architecture/terraform-module-icp-deploy) +* VMware: [Deploy IBM Cloud Private to VMware](https://github.com/ibm-cloud-architecture/terraform-icp-vmware) + +## AWS上でのIBM Cloud Private + +You can deploy an IBM Cloud Private cluster on Amazon Web Services (AWS) by using either AWS CloudFormation or Terraform. + +IBM Cloud Private has a Quick Start that automatically deploys IBM Cloud Private into a new virtual private cloud (VPC) on the AWS Cloud. A regular deployment takes about 60 minutes, and a high availability (HA) deployment takes about 75 minutes to complete. The Quick Start includes AWS CloudFormation templates and a deployment guide. + +This Quick Start is for users who want to explore application modernization and want to accelerate meeting their digital transformation goals, by using IBM Cloud Private and IBM tooling. The Quick Start helps users rapidly deploy a high availability (HA), production-grade, IBM Cloud Private reference architecture on AWS. For all of the details and the deployment guide, see the [IBM Cloud Private on AWS Quick Start](https://aws.amazon.com/quickstart/architecture/ibm-cloud-private/). + +IBM Cloud Private can also run on the AWS cloud platform by using Terraform. To deploy IBM Cloud Private in an AWS EC2 environment, see [Installing IBM Cloud Private on AWS](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_aws.md). + +## Azure上でのIBM Cloud Private + +You can enable Microsoft Azure as a cloud provider for IBM Cloud Private deployment and take advantage of all the IBM Cloud Private features on the Azure public cloud. For more information, see [IBM Cloud Private on Azure](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/azure_overview.html). + +## Red Hat OpenShift上でのIBM Cloud Private + +You can deploy IBM certified software containers that are running on IBM Cloud Private onto Red Hat OpenShift. + +Integration capabilities: + +* Supports Linux® 64-bit platform in offline-only installation mode +* Single-master configuration +* Integrated IBM Cloud Private cluster management console and catalog +* Integrated core platform services, such as monitoring, metering, and logging +* IBM Cloud Private uses the OpenShift image registry + +For more information see, [IBM Cloud Private on OpenShift](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/supported_environments/openshift/overview.html). + +## VirtualBox上でのIBM Cloud Private + +To install IBM Cloud Private to a VirtualBox environment, see [Installing IBM Cloud Private on VirtualBox](https://github.com/ibm-cloud-architecture/refarch-privatecloud-virtualbox). + +## VMware上でのIBM Cloud Private + +You can install IBM Cloud Private on VMware with either Ubuntu or RHEL images. For details, see the following projects: + +* [Installing IBM Cloud Private with Ubuntu](https://github.com/ibm-cloud-architecture/refarch-privatecloud/blob/master/Installing_ICp_on_prem_ubuntu.md) +* [Installing IBM Cloud Private with Red Hat Enterprise](https://github.com/ibm-cloud-architecture/refarch-privatecloud/tree/master/icp-on-rhel) + +The IBM Cloud Private Hosted service automatically deploys IBM Cloud Private Hosted on your VMware vCenter Server instances. This service brings the power of microservices and containers to your VMware environment on IBM Cloud. With this service, you can extend the same familiar VMware and IBM Cloud Private operational model and tools from on-premises into the IBM Cloud. + +For more information, see [IBM Cloud Private Hosted service](https://cloud.ibm.com/docs/services/vmwaresolutions/vmonic?topic=vmware-solutions-prod_overview#ibm-cloud-private-hosted). diff --git a/content/ja/docs/setup/version-skew-policy.md b/content/ja/docs/setup/version-skew-policy.md new file mode 100644 index 0000000000..422e7fbc90 --- /dev/null +++ b/content/ja/docs/setup/version-skew-policy.md @@ -0,0 +1,141 @@ +--- +title: Kubernetesバージョンとバージョンスキューサポートポリシー +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} +This document describes the maximum version skew supported between various Kubernetes components. +Specific cluster deployment tools may place additional restrictions on version skew. +{{% /capture %}} + +{{% capture body %}} + +## サポートされるバージョン + +Kubernetes versions are expressed as **x.y.z**, +where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology. +For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning). + +The Kubernetes project maintains release branches for the most recent three minor releases. + +Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. +Patch releases are cut from those branches at a regular cadence, or as needed. +This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/patch-release-manager/README.md#release-timing). +The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/releases/). + +Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months. + +## サポートされるバージョンスキュー + +### kube-apiserver + +In [highly-availabile (HA) clusters](https://kubernetes.io/docs/setup/independent/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version. + +Example: + +* newest `kube-apiserver` is at **1.13** +* other `kube-apiserver` instances are supported at **1.13** and **1.12** + +### kubelet + +`kubelet` must not be newer than `kube-apiserver`, and may be up to two minor versions older. + +Example: + +* `kube-apiserver` is at **1.13** +* `kubelet` is supported at **1.13**, **1.12**, and **1.11** + +{{< note >}} +If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions. +{{}} + +Example: + +* `kube-apiserver` instances are at **1.13** and **1.12** +* `kubelet` is supported at **1.12**, and **1.11** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**) + +### kube-controller-manager、kube-scheduler、およびcloud-controller-manager + +`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades). + +Example: + +* `kube-apiserver` is at **1.13** +* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.13** and **1.12** + +{{< note >}} +If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components. +{{< /note >}} + +Example: + +* `kube-apiserver` instances are at **1.13** and **1.12** +* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance +* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.12** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**) + +### kubectl + +`kubectl` is supported within one minor version (older or newer) of `kube-apiserver`. + +Example: + +* `kube-apiserver` is at **1.13** +* `kubectl` is supported at **1.14**, **1.13**, and **1.12** + +{{< note >}} +If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions. +{{< /note >}} + +Example: + +* `kube-apiserver` instances are at **1.13** and **1.12** +* `kubectl` is supported at **1.13** and **1.12** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components) + +## サポートされるコンポーネントのアップグレード順序 + +The supported version skew between components has implications on the order in which components must be upgraded. +This section describes the order in which components must be upgraded to transition an existing cluster from version **1.n** to version **1.(n+1)**. + +### kube-apiserver + +Pre-requisites: + +* In a single-instance cluster, the existing `kube-apiserver` instance is **1.n** +* In an HA cluster, all `kube-apiserver` instances are at **1.n** or **1.(n+1)** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance) +* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **1.n** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version) +* `kubelet` instances on all nodes are at version **1.n** or **1.(n-1)** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version) +* Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them: + * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **1.(n+1)** + * The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **1.(n+1)** + +Upgrade `kube-apiserver` to **1.(n+1)** + +{{< note >}} +Project policies for [API deprecation](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) and +[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md) +require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters. +{{< /note >}} + +### kube-controller-manager、kube-scheduler、およびcloud-controller-manager + +Pre-requisites: + +* The `kube-apiserver` instances these components communicate with are at **1.(n+1)** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components) + +Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **1.(n+1)** + +### kubelet + +Pre-requisites: + +* The `kube-apiserver` instances the `kubelet` communicates with are at **1.(n+1)** + +Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **1.n** or **1.(n-1)**) + +{{< warning >}} +Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended: + +* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded +* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases +{{}} diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 102323ca44..40085fe2cb 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -8,6 +8,9 @@ menu: weight: 10 post: >

手を動かす準備はできていますか？本チュートリアルでは、Node.jsを使った簡単な"Hello World"を実行するKubernetesクラスタをビルドします。

+card: + name: tutorials + weight: 10 --- {{% capture overview %}} @@ -58,7 +61,7 @@ menu: 3. Katacoda環境のみ：ターミナルペーン上部の+ボタンをクリックしてから **Select port to view on Host 1** をクリックしてください。 -4. Katacoda環境のみ：30000を入力し、**Display Port**をクリックしてください。 +4. Katacoda環境のみ：`30000`を入力し、**Display Port**をクリックしてください。 ## Deploymentの作成 @@ -67,7 +70,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの 1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。 ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node --port=8080 + kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node ``` 2. Deploymentを確認します: @@ -116,7 +119,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの 1. `kubectl expose` コマンドを使用してPodをインターネットに公開します: ```shell - kubectl expose deployment hello-node --type=LoadBalancer + kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` `--type=LoadBalancer`フラグはServiceをクラスタ外部に公開したいことを示しています。 @@ -146,7 +149,7 @@ Kubernetesの[*Pod*](/docs/concepts/workloads/pods/pod/) は、コンテナの 4. Katacoda環境のみ：ターミナル画面上部の+ボタンをクリックして **Select port to view on Host 1** をクリックしてください。 -5. Katacoda環境のみ：8080を入力し、**Display Port**をクリックしてください。 +5. Katacoda環境のみ：`30369`(Service出力に表示されている`8080`の反対側のポートを参照)を入力し、クリックしてください。 "Hello World"メッセージが表示されるアプリケーションのブラウザウィンドウが開きます。 diff --git a/content/ja/docs/tutorials/kubernetes-basics/_index.html b/content/ja/docs/tutorials/kubernetes-basics/_index.html index 51e7da5821..654d895701 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ja/docs/tutorials/kubernetes-basics/_index.html @@ -2,6 +2,10 @@ title: Kubernetesの基本を学ぶ linkTitle: Kubernetesの基本を学ぶ weight: 10 +card: + name: tutorials + weight: 20 + title: 基本のチュートリアル --- @@ -17,7 +21,7 @@ weight: 10

Kubernetesの基本

-

このチュートリアルでは、Kubernetesクラスタオーケストレーションシステムの基本について学びます。各モジュールには、Kubernetesの主な機能と概念に関する背景情報と、インタラクティブなオンラインチュートリアルが含まれています。これらの対話型チュートリアルでは、簡単なクラスタとそのコンテナ化されたアプリケーション を自分で管理できます。

+

このチュートリアルでは、Kubernetesクラスタオーケストレーションシステムの基本について学びます。各モジュールには、Kubernetesの主な機能と概念に関する背景情報と、インタラクティブなオンラインチュートリアルが含まれています。これらの対話型チュートリアルでは、簡単なクラスタとそのコンテナ化されたアプリケーションを自分で管理できます。

この対話型のチュートリアルでは、以下のことを学ぶことができます:

  • コンテナ化されたアプリケーションをクラスタにデプロイ
    • @@ -34,7 +38,7 @@ weight: 10

    Kubernetesはどんなことができるの?

    -

    モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。

    +

    モダンなWebサービスでは、ユーザはアプリケーションが24時間365日利用可能であることを期待しており、開発者はそれらのアプリケーションの新しいバージョンを1日に数回デプロイすることを期待しています。コンテナ化は、パッケージソフトウェアがこれらの目標を達成するのを助け、アプリケーションをダウンタイムなしで簡単かつ迅速にリリース、アップデートできるようにします。Kubernetesを使用すると、コンテナ化されたアプリケーションをいつでもどこでも好きなときに実行できるようになり、それらが機能するために必要なリソースとツールを見つけやすくなります。Kubernetesは、コンテナオーケストレーションにおけるGoogleのこれまでの経験と、コミュニティから得られた最善のアイデアを組み合わせて設計された、プロダクションレディなオープンソースプラットフォームです。

    diff --git a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 715c57d1a8..eaf828e23b 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -29,7 +29,7 @@ weight: 10

    Kubernetesクラスタ

    - Kubernetesは、単一のユニットとして機能するように接続された、可用性の高いコンピュータのクラスタをまとめあげます。Kubernetesの抽象化により、コンテナ化されたアプリケーションを個々のマシンに特に結び付けることなくクラスタにデプロイできます。この新しいデプロイモデルを利用するには、アプリケーションを個々のホストから切り離す方法でアプリケーションをパッケージ化(つまり、コンテナ化)する必要があります。コンテナ化されたアプリケーションは、アプリケーションがホストに深く統合されたパッケージとして特定のマシンに直接インストールされていた従来のデプロイモデルよりも柔軟で、より迅速に利用可能です。Kubernetesはより効率的な方法で、クラスタ全体のアプリケーションコンテナの配布とスケジューリングを自動化します。Kubernetesはオープンソースのプラットフォームであり、プロダクションレディです。 + Kubernetesは、単一のユニットとして機能するように接続された、可用性の高いコンピュータのクラスタをまとめあげます。Kubernetesの抽象化により、コンテナ化されたアプリケーションを個々のマシンに特に結び付けることなくクラスタにデプロイできます。この新しいデプロイモデルを利用するには、アプリケーションを個々のホストから切り離す方法でアプリケーションをパッケージ化(つまり、コンテナ化)する必要があります。コンテナ化されたアプリケーションは、アプリケーションがホストに深く統合されたパッケージとして特定のマシンに直接インストールされていた従来のデプロイモデルよりも柔軟で、より迅速に利用可能です。Kubernetesはより効率的な方法で、クラスタ全体のアプリケーションコンテナの配布とスケジューリングを自動化します。Kubernetesはオープンソースのプラットフォームであり、プロダクションレディです。

    Kubernetesクラスタは以下の2種類のリソースで構成されています:

      @@ -72,12 +72,12 @@ weight: 10

      マスターはクラスタの管理を担当します。マスターは、アプリケーションのスケジューリング、望ましい状態の維持、アプリケーションのスケーリング、新しい更新のロールアウトなど、クラスタ内のすべての動作をまとめあげます。

      -

      Nodeは、Kubernetesクラスタのワーカーマシンとして機能するVMまたは物理マシンです。各NodeにはKubeletがあり、これはNodeを管理し、Kubernetesマスターと通信するためのエージェントです。NodeにはDockerやrktなどのコンテナ操作を処理するためのツールもあるはずです。プロダクションのトラフィックを処理するKubernetesクラスタには、最低3つのNodeが必要です。

      +

      Nodeは、Kubernetesクラスタのワーカーマシンとして機能するVMまたは物理マシンです。各NodeにはKubeletがあり、これはNodeを管理し、Kubernetesマスターと通信するためのエージェントです。NodeにはDockerやrktなどのコンテナ操作を処理するためのツールもあるはずです。プロダクションのトラフィックを処理するKubernetesクラスタには、最低3つのNodeが必要です。

      -

      マスターはクラスタを管理するために、Nodeは実行中のアプリケーションをホストするために使用されます。

      +

      マスターはクラスタを管理するために、Nodeは実行中のアプリケーションをホストするために使用されます。

      @@ -86,7 +86,7 @@ weight: 10

      Kubernetesにアプリケーションをデプロイするときは、マスターにアプリケーションコンテナを起動するように指示します。マスターはコンテナがクラスタのNodeで実行されるようにスケジュールします。Nodeは、マスターが公開しているKubernetes APIを使用してマスターと通信します。エンドユーザーは、Kubernetes APIを直接使用して対話することもできます。

      -

      Kubernetesクラスタは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるためにMinikubeを使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのNodeのみを含む単純なクラスタをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスタを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。

      +

      Kubernetesクラスタは、物理マシンまたは仮想マシンのどちらにも配置できます。Kubernetes開発を始めるためにMinikubeを使うことができます。Minikubeは、ローカルマシン上にVMを作成し、1つのNodeのみを含む単純なクラスタをデプロイする軽量なKubernetes実装です。Minikubeは、Linux、macOS、およびWindowsシステムで利用可能です。Minikube CLIは、起動、停止、ステータス、削除など、クラスタを操作するための基本的なブートストラップ操作を提供します。ただし、このチュートリアルでは、Minikubeがプリインストールされた状態で提供されているオンラインのターミナルを使用します。

      Kubernetesが何であるかがわかったので、オンラインチュートリアルに行き、最初のクラスタを動かしましょう！

      diff --git a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 37d15b551f..123d2683a2 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -31,7 +31,7 @@ weight: 10 実行中のKubernetesクラスタを入手すると、その上にコンテナ化アプリケーションをデプロイすることができます。そのためには、KubernetesのDeployment の設定を作成します。DeploymentはKubernetesにあなたのアプリケーションのインスタンスを作成し、更新する方法を指示します。Deploymentを作成すると、Kubernetesマスターは指定されたアプリケーションインスタンスをクラスタ内の個々のNodeにスケジュールします。

      -

      アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているNodeが停止、削除された場合、Deploymentコントローラーがそれを置き換えます。これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。

      +

      アプリケーションインスタンスが作成されると、Kubernetes Deploymentコントローラーは、それらのインスタンスを継続的に監視します。インスタンスをホストしているNodeが停止、削除された場合、Deploymentコントローラーはそのインスタンスをクラスター内の別のノード上のインスタンスと置き換えます。これは、マシンの故障やメンテナンスに対処するためのセルフヒーリングの仕組みを提供しています。

      オーケストレーションが入る前の世界では、インストールスクリプトを使用してアプリケーションを起動することはよくありましたが、マシン障害が発生した場合に復旧する事はできませんでした。アプリケーションのインスタンスを作成し、それらをNode間で実行し続けることで、Kubernetes Deploymentsはアプリケーションの管理に根本的に異なるアプローチを提供します。

      @@ -85,7 +85,7 @@ weight: 10
      -

      最初のDeploymentには、DockerコンテナにパッケージされたNode.jsアプリケーションを使用します。Node.jsアプリケーションを作成してDockerコンテナをデプロイするには、Hello Minikubeチュートリアルの指示に従ってください。

      +

      最初のDeploymentには、DockerコンテナにパッケージされたNode.jsアプリケーションを使用します。Node.jsアプリケーションを作成してDockerコンテナをデプロイするには、Hello Minikubeチュートリアルの指示に従ってください。

      Deploymentが何であるかがわかったので、オンラインチュートリアルに行き、最初のアプリケーションをデプロイしましょう！

      diff --git a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 4ffd40a90b..049539137f 100644 --- a/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ja/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -28,9 +28,9 @@ weight: 10

      Kubernetes Serviceの概要

      -

      Kubernetes Podの寿命は永続的ではありません。実際、Podにはライフサイクルがあります。ワーカーのNodeが停止すると、そのNodeで実行されているPodも失われます。そうなると、ReplicationControllerは、新しいPodを作成してアプリケーションを実行し続けるために、クラスタを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスタ内の各Podは、同じNode上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。

      - -

      KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML(推奨)またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、LabelSelectorによって決定されます(なぜ仕様にセレクタを含めずにServiceが必要になるのかについては下記を参照してください)。

      +

      Kubernetes Podの寿命は永続的ではありません。実際、Podにはライフサイクルがあります。ワーカーのNodeが停止すると、そのNodeで実行されているPodも失われます。そうなると、ReplicaSetは、新しいPodを作成してアプリケーションを実行し続けるために、クラスタを動的に目的の状態に戻すことができます。別の例として、3つのレプリカを持つ画像処理バックエンドを考えます。それらのレプリカは交換可能です。フロントエンドシステムはバックエンドのレプリカを気にしたり、Podが失われて再作成されたとしても配慮すべきではありません。ただし、Kubernetesクラスタ内の各Podは、同じNode上のPodであっても一意のIPアドレスを持っているため、アプリケーションが機能し続けるように、Pod間の変更を自動的に調整する方法が必要です。

      + +

      KubernetesのServiceは、Podの論理セットと、それらにアクセスするためのポリシーを定義する抽象概念です。Serviceによって、依存Pod間の疎結合が可能になります。Serviceは、すべてのKubernetesオブジェクトのように、YAML(推奨)またはJSONを使って定義されます。Serviceが対象とするPodのセットは通常、LabelSelectorによって決定されます(なぜ仕様にセレクタを含めずにServiceが必要になるのかについては下記を参照してください)。

      各Podには固有のIPアドレスがありますが、それらのIPは、Serviceなしではクラスタの外部に公開されません。Serviceによって、アプリケーションはトラフィックを受信できるようになります。ServiceSpecでtypeを指定することで、Serviceをさまざまな方法で公開することができます。

        @@ -39,7 +39,7 @@ weight: 10
      • LoadBalancer - 現在のクラウドに外部ロードバランサを作成し(サポートされている場合)、Serciceに固定の外部IPを割り当てます。これはNodePortのスーパーセットです。
      • ExternalName - 仕様のexternalNameで指定した名前のCNAMEレコードを返すことによって、任意の名前を使ってServiceを公開します。プロキシは使用されません。このタイプはv1.7以上のkube-dnsを必要とします。
      -

      さまざまな種類のServiceに関する詳細情報はUsing Source IP tutorialにあります。アプリケーションとServiceの接続も参照してください。

      +

      さまざまな種類のServiceに関する詳細情報はUsing Source IP tutorialにあります。アプリケーションとServiceの接続も参照してください。

      加えて、Serviceには、仕様にselectorを定義しないというユースケースがいくつかあります。selectorを指定せずに作成したServiceについて、対応するEndpointsオブジェクトは作成されません。これによって、ユーザーは手動でServiceを特定のエンドポイントにマッピングできます。セレクタがない可能性があるもう1つの可能性は、type：ExternalNameを厳密に使用していることです。