Remove kops.md kubespray.md
Sanghyuk Lee
parent
f99f724e19
commit
c1c64ac83f
|
|
@ -1,239 +0,0 @@
|
|||
---
|
||||
title: kopsを使ったAWS上でのKubernetesのインストール
|
||||
content_type: task
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This quickstart shows you how to easily install a Kubernetes cluster on AWS.
|
||||
It uses a tool called [`kops`](https://github.com/kubernetes/kops).
|
||||
|
||||
kops is an automated provisioning system:
|
||||
|
||||
* Fully automated installation
|
||||
* Uses DNS to identify clusters
|
||||
* Self-healing: everything runs in Auto-Scaling Groups
|
||||
* Multiple OS support (Debian, Ubuntu 16.04 supported, CentOS & RHEL, Amazon Linux and CoreOS) - see the [images.md](https://github.com/kubernetes/kops/blob/master/docs/operations/images.md)
|
||||
* High-Availability support - see the [high_availability.md](https://github.com/kubernetes/kops/blob/master/docs/operations/high_availability.md)
|
||||
* Can directly provision, or generate terraform manifests - see the [terraform.md](https://github.com/kubernetes/kops/blob/master/docs/terraform.md)
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
* You must have [kubectl](/docs/tasks/tools/install-kubectl/) installed.
|
||||
|
||||
* You must [install](https://github.com/kubernetes/kops#installing) `kops` on a 64-bit (AMD64 and Intel 64) device architecture.
|
||||
|
||||
* You must have an [AWS account](https://docs.aws.amazon.com/polly/latest/dg/setting-up.html), generate [IAM keys](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys) and [configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-quick-configuration) them. The IAM user will need [adequate permissions](https://github.com/kubernetes/kops/blob/master/docs/getting_started/aws.md#setup-iam-user).
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## クラスターの作成
|
||||
|
||||
### (1/5) kopsのインストール
|
||||
|
||||
#### インストール
|
||||
|
||||
Download kops from the [releases page](https://github.com/kubernetes/kops/releases) (it is also easy to build from source):
|
||||
|
||||
{{< tabs name="kops_installation" >}}
|
||||
{{% tab name="macOS" %}}
|
||||
|
||||
Download the latest release with the command:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64
|
||||
```
|
||||
|
||||
To download a specific version, replace the following portion of the command with the specific kops version.
|
||||
|
||||
```shell
|
||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||
```
|
||||
|
||||
For example, to download kops version v1.20.0 type:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64
|
||||
```
|
||||
|
||||
Make the kops binary executable.
|
||||
|
||||
```shell
|
||||
chmod +x kops-darwin-amd64
|
||||
```
|
||||
|
||||
Move the kops binary in to your PATH.
|
||||
|
||||
```shell
|
||||
sudo mv kops-darwin-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
You can also install kops using [Homebrew](https://brew.sh/).
|
||||
|
||||
```shell
|
||||
brew update && brew install kops
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Linux" %}}
|
||||
|
||||
Download the latest release with the command:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
|
||||
```
|
||||
|
||||
To download a specific version of kops, replace the following portion of the command with the specific kops version.
|
||||
|
||||
```shell
|
||||
$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)
|
||||
```
|
||||
|
||||
For example, to download kops version v1.20.0 type:
|
||||
|
||||
```shell
|
||||
curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64
|
||||
```
|
||||
|
||||
Make the kops binary executable
|
||||
|
||||
```shell
|
||||
chmod +x kops-linux-amd64
|
||||
```
|
||||
|
||||
Move the kops binary in to your PATH.
|
||||
|
||||
```shell
|
||||
sudo mv kops-linux-amd64 /usr/local/bin/kops
|
||||
```
|
||||
|
||||
You can also install kops using [Homebrew](https://docs.brew.sh/Homebrew-on-Linux).
|
||||
|
||||
```shell
|
||||
brew update && brew install kops
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
|
||||
### (2/5) クラスター用のroute53ドメインの作成
|
||||
|
||||
kops uses DNS for discovery, both inside the cluster and outside, so that you can reach the kubernetes API server
|
||||
from clients.
|
||||
|
||||
kops has a strong opinion on the cluster name: it should be a valid DNS name. By doing so you will
|
||||
no longer get your clusters confused, you can share clusters with your colleagues unambiguously,
|
||||
and you can reach them without relying on remembering an IP address.
|
||||
|
||||
You can, and probably should, use subdomains to divide your clusters. As our example we will use
|
||||
`useast1.dev.example.com`. The API server endpoint will then be `api.useast1.dev.example.com`.
|
||||
|
||||
A Route53 hosted zone can serve subdomains. Your hosted zone could be `useast1.dev.example.com`,
|
||||
but also `dev.example.com` or even `example.com`. kops works with any of these, so typically
|
||||
you choose for organization reasons (e.g. you are allowed to create records under `dev.example.com`,
|
||||
but not under `example.com`).
|
||||
|
||||
Let's assume you're using `dev.example.com` as your hosted zone. You create that hosted zone using
|
||||
the [normal process](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html), or
|
||||
with a command such as `aws route53 create-hosted-zone --name dev.example.com --caller-reference 1`.
|
||||
|
||||
You must then set up your NS records in the parent domain, so that records in the domain will resolve. Here,
|
||||
you would create NS records in `example.com` for `dev`. If it is a root domain name you would configure the NS
|
||||
records at your domain registrar (e.g. `example.com` would need to be configured where you bought `example.com`).
|
||||
|
||||
This step is easy to mess up (it is the #1 cause of problems!) You can double-check that
|
||||
your cluster is configured correctly if you have the dig tool by running:
|
||||
|
||||
`dig NS dev.example.com`
|
||||
|
||||
You should see the 4 NS records that Route53 assigned your hosted zone.
|
||||
|
||||
### (3/5) クラスターの状態を保存するS3バケットの作成
|
||||
|
||||
kops lets you manage your clusters even after installation. To do this, it must keep track of the clusters
|
||||
that you have created, along with their configuration, the keys they are using etc. This information is stored
|
||||
in an S3 bucket. S3 permissions are used to control access to the bucket.
|
||||
|
||||
Multiple clusters can use the same S3 bucket, and you can share an S3 bucket between your colleagues that
|
||||
administer the same clusters - this is much easier than passing around kubecfg files. But anyone with access
|
||||
to the S3 bucket will have administrative access to all your clusters, so you don't want to share it beyond
|
||||
the operations team.
|
||||
|
||||
So typically you have one S3 bucket for each ops team (and often the name will correspond
|
||||
to the name of the hosted zone above!)
|
||||
|
||||
In our example, we chose `dev.example.com` as our hosted zone, so let's pick `clusters.dev.example.com` as
|
||||
the S3 bucket name.
|
||||
|
||||
* Export `AWS_PROFILE` (if you need to select a profile for the AWS CLI to work)
|
||||
|
||||
* Create the S3 bucket using `aws s3 mb s3://clusters.dev.example.com`
|
||||
|
||||
* You can `export KOPS_STATE_STORE=s3://clusters.dev.example.com` and then kops will use this location by default.
|
||||
We suggest putting this in your bash profile or similar.
|
||||
|
||||
|
||||
### (4/5) クラスター設定の構築
|
||||
|
||||
Run `kops create cluster` to create your cluster configuration:
|
||||
|
||||
`kops create cluster --zones=us-east-1c useast1.dev.example.com`
|
||||
|
||||
kops will create the configuration for your cluster. Note that it _only_ creates the configuration, it does
|
||||
not actually create the cloud resources - you'll do that in the next step with a `kops update cluster`. This
|
||||
give you an opportunity to review the configuration or change it.
|
||||
|
||||
It prints commands you can use to explore further:
|
||||
|
||||
* List your clusters with: `kops get cluster`
|
||||
* Edit this cluster with: `kops edit cluster useast1.dev.example.com`
|
||||
* Edit your node instance group: `kops edit ig --name=useast1.dev.example.com nodes`
|
||||
* Edit your master instance group: `kops edit ig --name=useast1.dev.example.com master-us-east-1c`
|
||||
|
||||
If this is your first time using kops, do spend a few minutes to try those out! An instance group is a
|
||||
set of instances, which will be registered as kubernetes nodes. On AWS this is implemented via auto-scaling-groups.
|
||||
You can have several instance groups, for example if you wanted nodes that are a mix of spot and on-demand instances, or
|
||||
GPU and non-GPU instances.
|
||||
|
||||
|
||||
### (5/5) AWSにクラスターを作成
|
||||
|
||||
Run "kops update cluster" to create your cluster in AWS:
|
||||
|
||||
`kops update cluster useast1.dev.example.com --yes`
|
||||
|
||||
That takes a few seconds to run, but then your cluster will likely take a few minutes to actually be ready.
|
||||
`kops update cluster` will be the tool you'll use whenever you change the configuration of your cluster; it
|
||||
applies the changes you have made to the configuration to your cluster - reconfiguring AWS or kubernetes as needed.
|
||||
|
||||
For example, after you `kops edit ig nodes`, then `kops update cluster --yes` to apply your configuration, and
|
||||
sometimes you will also have to `kops rolling-update cluster` to roll out the configuration immediately.
|
||||
|
||||
Without `--yes`, `kops update cluster` will show you a preview of what it is going to do. This is handy
|
||||
for production clusters!
|
||||
|
||||
### 他のアドオンの参照
|
||||
|
||||
See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to explore other add-ons, including tools for logging, monitoring, network policy, visualization, and control of your Kubernetes cluster.
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
* To delete your cluster: `kops delete cluster useast1.dev.example.com --yes`
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/ja/docs/reference/kubectl/).
|
||||
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
|
||||
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
|
||||
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
|
||||
|
||||
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
---
|
||||
title: kubesprayを使ったKubernetesのインストール
|
||||
content_type: concept
|
||||
weight: 30
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
このクイックスタートは、[Kubespray](https://github.com/kubernetes-sigs/kubespray)を使用して、GCE、Azure、OpenStack、AWS、vSphere、Equinix Metal(以前のPacket)、Oracle Cloud Infrastructure(実験的)またはベアメタルにホストされたKubernetesクラスターをインストールするためのものです。
|
||||
|
||||
Kubesprayは、汎用的なOSやKubernetesクラスターの構成管理タスクのための[Ansible](https://docs.ansible.com/)プレイブック、[インベントリー](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible/inventory.md)、プロビジョニングツール、ドメインナレッジをまとめたものです。
|
||||
|
||||
Kubesprayは次を提供します:
|
||||
|
||||
* 高可用性クラスター。
|
||||
* 構成可能(例えばネットワークプラグインの選択)。
|
||||
* 最もポピュラーなLinuxディストリビューションのサポート:
|
||||
- Flatcar Container Linux by Kinvolk
|
||||
- Debian Bullseye, Buster, Jessie, Stretch
|
||||
- Ubuntu 16.04, 18.04, 20.04, 22.04
|
||||
- CentOS/RHEL 7, 8, 9
|
||||
- Fedora 35, 36
|
||||
- Fedora CoreOS
|
||||
- openSUSE Leap 15.x/Tumbleweed
|
||||
- Oracle Linux 7, 8, 9
|
||||
- Alma Linux 8, 9
|
||||
- Rocky Linux 8, 9
|
||||
- Kylin Linux Advanced Server V10
|
||||
- Amazon Linux 2
|
||||
* 継続的インテグレーションテスト。
|
||||
|
||||
あなたのユースケースに最適なツールの選択には、[kubeadm](/docs/reference/setup-tools/kubeadm/)や[kops](/docs/setup/production-environment/tools/kops/)と[比較したドキュメント](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)を参照してください。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## クラスターの作成
|
||||
|
||||
### (1/5) 下地の要件の確認
|
||||
|
||||
次の[要件](https://github.com/kubernetes-sigs/kubespray#requirements)に従ってサーバーをプロビジョニングします:
|
||||
|
||||
* **Kubernetesの最低必要バージョンはv1.22**
|
||||
* **Ansibleのコマンドを実行するマシン上にAnsible v2.11+、Jinja 2.11+とpython-netaddrがインストールされていること**
|
||||
* ターゲットサーバーはdockerイメージをpullするために**インターネットにアクセスできる**必要があります。そうでは無い場合は追加の構成が必要です([オフライン環境](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md)を参照)
|
||||
* ターゲットのサーバーは**IPv4フォワーディング**ができるように構成されていること。
|
||||
* PodとServiceにIPv6を使用している場合は、ターゲットサーバーは**IPv6フォワーディング**ができるように構成されていること。
|
||||
* **ファイアウォールは管理されないため**、従来のように独自のルールを実装しなければなりません。デプロイ中の問題を避けるためには、ファイアウォールを無効にすべきです
|
||||
* root以外のユーザーアカウントでkubesprayを実行する場合は、ターゲットサーバー上で特権昇格の方法を正しく構成されている必要があります。そして、`ansible_become`フラグ、またはコマンドパラメーター`--become`、`-b`を指定する必要があります
|
||||
|
||||
Kubesprayは環境のプロビジョニングを支援するために次のユーティリティを提供します:
|
||||
|
||||
* 下記のクラウドプロバイダー用の[Terraform](https://www.terraform.io/)スクリプト:
|
||||
* [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws)
|
||||
* [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack)
|
||||
* [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/equinix)
|
||||
|
||||
|
||||
### (2/5) インベントリーファイルの用意
|
||||
|
||||
サーバーをプロビジョニングした後、[Ansibleのインベントリーファイル](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html)を作成します。これは手動またはダイナミックインベントリースクリプトによって行うことができます。詳細については、"[独自のインベントリーを構築する](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)"を参照してください。
|
||||
|
||||
### (3/5) クラスター作成の計画
|
||||
|
||||
Kubesprayは多くの点でデプロイメントをカスタマイズする機能を提供します:
|
||||
|
||||
* デプロイメントモードの選択: kubeadmまたはnon-kubeadm
|
||||
* CNI(ネットワーク)プラグイン
|
||||
* DNS設定
|
||||
* コントロールプレーンの選択: ネイティブ/バイナリまたはコンテナ化
|
||||
* コンポーネントバージョン
|
||||
* Calicoルートリフレクター
|
||||
* コンポーネントランタイムオプション
|
||||
* {{< glossary_tooltip term_id="docker" >}}
|
||||
* {{< glossary_tooltip term_id="containerd" >}}
|
||||
* {{< glossary_tooltip term_id="cri-o" >}}
|
||||
* 証明書の生成方法
|
||||
|
||||
Kubesprayは[variableファイル](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)によってカスタマイズできます。Kubesprayを使い始めたばかりであれば、Kubesprayのデフォルト設定を使用してクラスターをデプロイし、Kubernetesを探索することを検討してください。
|
||||
|
||||
### (4/5) クラスターのデプロイ
|
||||
|
||||
次にクラスターをデプロイします:
|
||||
|
||||
クラスターのデプロイメントには[ansible-playbook](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#starting-custom-deployment)を使用します。
|
||||
|
||||
```shell
|
||||
ansible-playbook -i your/inventory/inventory.ini cluster.yml -b -v \
|
||||
--private-key=~/.ssh/private_key
|
||||
```
|
||||
|
||||
大規模なデプロイメント(100以上のノード)では、最適な結果を得るために[個別の調整](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/large-deployments.md)が必要な場合があります。
|
||||
|
||||
### (5/5) デプロイの確認
|
||||
|
||||
Kubesprayは、[Netchecker](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/netcheck.md)によるPod間の接続とDNSの解決の検証を行う機能を提供します。Netcheckerは、netchecker-agents Podがdefault名前空間内でDNSリクエストを解決し、互いにpingを送信できることを確かめます。これらのPodは他のワークロードと同様の動作を再現し、クラスターの健全性を示す指標として機能します。
|
||||
|
||||
## クラスターの操作
|
||||
|
||||
Kubesprayはクラスターを管理する追加のプレイブックを提供します: _scale_ と _upgrade_。
|
||||
|
||||
### クラスターのスケール
|
||||
|
||||
scaleプレイブックを実行することで、クラスターにワーカーノードを追加することができます。詳細については、"[ノードの追加](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)"を参照してください。
|
||||
remove-nodeプレイブックを実行することで、クラスターからワーカーノードを削除することができます。詳細については、"[ノードの削除](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)"を参照してください。
|
||||
|
||||
### クラスターのアップグレード
|
||||
|
||||
upgrade-clusterプレイブックを実行することで、クラスターのアップグレードができます。詳細については、"[アップグレード](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/upgrades.md)"を参照してください。
|
||||
|
||||
## クリーンアップ
|
||||
|
||||
|
||||
[resetプレイブック](https://github.com/kubernetes-sigs/kubespray/blob/master/reset.yml)を使用して、ノードをリセットし、Kubesprayでインストールした全てのコンポーネントを消すことができます。
|
||||
|
||||
{{< caution >}}
|
||||
resetプレイブックを実行する際は、誤ってプロダクションのクラスターを対象にしないように気をつけること!
|
||||
{{< /caution >}}
|
||||
|
||||
## フィードバック
|
||||
|
||||
* Slackチャンネル: [#kubespray](https://kubernetes.slack.com/messages/kubespray/) ([ここ](https://slack.k8s.io/)から招待をもらうことができます)。
|
||||
* [GitHub Issues](https://github.com/kubernetes-sigs/kubespray/issues)。
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Kubesprayの[ロードマップ](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)にある作業計画を確認してください。
|
||||
* [Kubespray](https://github.com/kubernetes-sigs/kubespray)についてさらに学ぶ。
|
||||
Loading…
Reference in New Issue