新しい 翻訳記事では、新しいKubernetesディストリビューションの概要を簡単に説明します。この記事がHabrの読者にとって興味深いものになることを願っています。
数日前、友人がミランティスからのk0sと呼ばれる 新しいKubernetesディストリビューションについて教えてくれ ました。私たちは皆、K8を知っていて、大好きですよね？また、Rancher Labsによって開発され、しばらく前にCNCFに引き渡さ れた軽量のKubernetesであるK3sに も魅了され ました。新しいk0sディストリビューションを発見する時が来ました！
k0の簡単な紹介の後、次の手順に従って3つのノードのクラスターを作成します。
- 3台の仮想マシンの準備（マルチパスの実行）
- それらのそれぞれにk0をインストールする
- 単純なk0sクラスター構成ファイルのセットアップ
- クラスターの初期化
- クラスターへのアクセスの取得
- ワーカーノードの追加
- ユーザーを追加する
k0sとは何ですか？
k0sは最新のKubernetesディストリビューションです。現在のリリースは0.8.0です。2020年12月に発行され、プロジェクト全体の最初のコミットは2020年6月に行われました。
k0sは、OSに依存しない単一のバイナリとして出荷されます。したがって、これは、摩擦ゼロ/深さゼロ/コストゼロの特性（構成の容易さ/依存関係なし/無料）を備えたKubernetes分布として定義され ます。
最新のk0sリリース：
- 認定済み（インターネットセキュリティセンター認定済み）のKubernetes1.19を提供
- デフォルトのコンテナランタイムとしてcontainerdを使用します
- Intel（x86-64）およびARM（ARM64）アーキテクチャをサポート
- クラスタ内などを使用
- デフォルトでCalicoネットワークプラグインを使用します（これにより、ネットワークポリシーがアクティブ化されます）
- ポッドセキュリティポリシーアクセスコントローラーが含まれています
- CoreDNSでDNSを使用
- 経由して、クラスタの指標を提供するメトリックサーバー
- 水平ポッドオートスケール（HPA）の使用を許可します。
将来のリリースでは、次のような多くの優れた機能が提供される予定です。
- コンパクトVMランタイム（この機能のテストを本当に楽しみにしています）
- ゼロダウンタイムクラスターアップグレード
- クラスターのバックアップとリカバリ
印象的ですね。次に、k0を使用して3ノードクラスターを展開する方法を見ていきます。
仮想マシンの準備
まず、3つの仮想マシンを作成します。各仮想マシンは、クラスター内のノードになります。この記事では、すばやく簡単な方法で、優れたマルチパスツール（大好きです）を使用して、 MacOSでローカル仮想マシンを準備します。
次のコマンドは、xhyve上にUbuntuの3つのインスタンスを作成します。各仮想マシンには、5 GBのディスク、2 GBのRAM、および2つの仮想プロセッサ（vCPU）があります。
for i in 1 2 3; do multipass launch -n node$i -c 2 -m 2G done
次に、仮想マシンのリストを表示して、すべてが正常に機能していることを確認できます。
$ multipass list Name State IPv4 Image node1 Running 192.168.64.11 Ubuntu 20.04 LTS node2 Running 192.168.64.12 Ubuntu 20.04 LTS node3 Running 192.168.64.13 Ubuntu 20.04 LTS
次に、これらの各ノードにk0をインストールします。
最新のk0sリリースのインストール
k0の最新リリースは、GitHubリポジトリからダウンロードでき ます。
便利なインストールスクリプトがあります。
curl -sSLf get.k0s.sh | sudo sh
このスクリプトを使用して、すべてのノードにk0をインストールします。
for i in 1 2 3; do multipass exec node$i --bash -c "curl -sSLf get.k0s.sh | sudo sh" done
上記のスクリプトは、k0sを/ user / bin / k0にインストールします 。使用可能なすべてのコマンドを取得するには、引数なしでバイナリを実行します。
使用可能なk0sコマンド
現在のバージョンを確認できます。
$ k0s version v0.8.0
次のステップでいくつかのコマンドを使用します。
構成ファイルの作成
まず、k0sがクラスターを作成するために必要な情報を含む構成ファイルを定義する必要があります。上の ノード1、我々は実行することができ、デフォルト・コンフィギュレーションコマンドを 完全なデフォルト設定を取得します。 とりわけ、これにより、以下を決定できます。
ubuntu@node1:~$ k0s default-config
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
- 192.168.64.11
extraArgs: {}
controllerManager:
extraArgs: {}
scheduler:
extraArgs: {}
storage:
type: etcd
kine: null
etcd:
peerAddress: 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
provider: calico
calico:
mode: vxlan
vxlanPort: 4789
vxlanVNI: 4096
mtu: 1450
wireguard: false
podSecurityPolicy:
defaultPolicy: 00-k0s-privileged
workerProfiles: []
extensions: null
images:
konnectivity:
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent
version: v0.0.13
metricsserver:
image: gcr.io/k8s-staging-metrics-server/metrics-server
version: v0.3.7
kubeproxy:
image: k8s.gcr.io/kube-proxy
version: v1.19.4
coredns:
image: docker.io/coredns/coredns
version: 1.7.0
calico:
cni:
image: calico/cni
version: v3.16.2
flexvolume:
image: calico/pod2daemon-flexvol
version: v3.16.2
node:
image: calico/node
version: v3.16.2
kubecontrollers:
image: calico/kube-controllers
version: v3.16.2
repository: ""
telemetry:
interval: 10m0s
enabled: true
- APIサーバー、コントローラーマネージャー、およびスケジューラの起動オプション
- クラスタ情報（etcd）の保存に使用できるストレージ
- ネットワークプラグインとその構成（Calico）
- 管理コンポーネントを含むコンテナイメージのバージョン
- クラスターの開始時に展開するいくつかの追加の管理スキーム
この構成をファイルに保存して、ニーズに適合させることができます。ただし、この記事では、非常に単純な構成を使用して、/ etc / k0s /k0s.yamlに保存し ます。 注：node1でクラスターを初期化しているため 、このノードはAPIサーバーにサービスを提供します。このノードのIPアドレスは 、上記の構成ファイルのapi.addressおよび api.sans（サブジェクトの代替名）で使用されます。追加のマスターノードとその上にロードバランサーがある場合は、設定でapi.sansも使用します
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
各ホストとロードバランサーのIPアドレス（または対応するドメイン名）。
クラスターの初期化
まず、k0を管理するためにnode1にsystemdユニットを作成します 。
[Unit] Description="k0s server" After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/bin/k0s server -c /etc/k0s/k0s.yaml --enable-worker Restart=always
メインコマンドはここExecStartにリストされて います; 前の手順でファイルに保存した構成でk0sサーバーを起動します。また、この最初のマスターノードがワーカーとしても機能するように--enable-workerパラメーターを指定します 。
次に、このファイルを/lib/systemd/system/k0s.serviceにコピーし 、systemdを再起動して、新しく作成されたサービスを開始します。
ubuntu@node1:~$ sudo systemctl daemon-reload ubuntu@node1:~$ sudo systemctl start k0s.service
好奇心のために、k0sサーバーによって開始されたプロセスを確認できます。
ubuntu@node1:~$ sudo ps aux | awk ‘{print $11}’ | grep k0s /usr/bin/k0s /var/lib/k0s/bin/etcd /var/lib/k0s/bin/konnectivity-server /var/lib/k0s/bin/kube-controller-manager /var/lib/k0s/bin/kube-scheduler /var/lib/k0s/bin/kube-apiserver /var/lib/k0s/bin/containerd /var/lib/k0s/bin/kubelet
上記の出力から、すべての主要コンポーネント（ kube-apiserver、 kube -controller-manager、 kube-schedulerなど）と、マスターノードとワーカーノードに共通のコンポーネント（ containered、kubelet）が実行されていることが わかります。k0sは、これらすべてのコンポーネントの管理を担当します。
これで、1ノードのクラスターができました。次のステップでは、それにアクセスする方法を見ていきます。
クラスターへのアクセスの取得
まず、クラスターの作成中に生成されたkubeconfigファイルを取得する必要 があります。それが上に作成された ノード1で /var/lib/k0s/pki/admin.conf。このファイルは、ローカルマシンでkubectlを構成するために使用する必要があります 。
まず、node1からクラスターのkubeconfigを取得し ます 。
# Get kubeconfig file $ multipass exec node1 cat /var/lib/k0s/pki/admin.conf > k0s.cfg
次に、内部IPアドレスを外部IPアドレスnode1に置き換えます 。
# Replace IP address $ NODE1_IP=$(multipass info node1 | grep IP | awk '{print $2}') sed -i '' "s/localhost/$NODE1_IP/" k0s.cfg
次に、k0sAPIサーバーと通信するようにローカルkubectlクライアントを構成します。
export KUBECONFIG=$PWD/k0s.cfg
確かに、新しいクラスターに入るときに最初に実行するコマンドの1つは、使用可能なすべてのノードのリストを表示するコマンドです。試してみましょう。
$ kubectl get no NAME STATUS ROLES AGE VERSION node1 Ready <none> 78s v1.19.4
ここで驚くべきことは何もありません。結局のところ、 node1はメインであるだけでなく、startコマンドで指定した--enable-workerフラグのおかげで、最初のクラスターの作業ノードでもあります 。このフラグがないと、 node1は機能するだけで、ここのノードのリストには表示されません。
ワーカーノードの追加
node2と node3をクラスターに追加するには 、最初にnode1から接続トークンを作成する必要があります （これは、kubeadmで作成されたDocker SwarmおよびKubernetesクラスターで使用されるため、かなり一般的な手順です）。
$ TOKEN=$(k0s token create --role=worker)
上記のコマンドは、長い（非常に長い）トークンを生成します。これを使用して、node2と node3をクラスターに参加させることができます 。
ubuntu@node2:~$ k0s worker $TOKEN ubuntu@node3:~$ k0s worker $TOKEN
注：実際のクラスターでは、マスターノードの場合と同様に、systemd（または他のスーパーバイザー）を使用してワーカーノードのk0sプロセスを管理します。
ノードのリストを表示し、ノードを再度リストすることで確認できるため、3ノードクラスターが稼働しています。
$ kubectl get no NAME STATUS ROLES AGE VERSION node1 Ready <none> 30m v1.19.4 node2 Ready <none> 35s v1.19.4 node3 Ready <none> 32s v1.19.4
また、すべての名前名で実行されているポッドを確認することもでき
ます。すべての名前名でクラスターで実行されているポッドのリスト
ここで注意すべき点がいくつかあります。
- いつものように、kube -proxyポッド、ネットワークプラグインポッド（Calicoに基づく）、およびCoreDNSポッドが表示されます。
- api-server, scheduler controller-manager , , .
K0sバージョン0.8.0には、ユーザーサブコマンドが含まれてい ます。これにより、追加のユーザー/グループのkubeconfigを作成できます 。たとえば、次のコマンドは、開発という名前の架空のグループ内にある 、新しいユーザー用のdemoという名前の kubeconfigファイルを作成します 。 注： Kubernetesでは、ユーザーとグループはクラスター外の管理者によって管理されます。つまり、K8にはユーザーではないグループのリソースはありません。
$ sudo k0s user create demo --groups development > demo.kubeconfig
理解を深めるために、このkubeconfigファイルからクライアント証明書を抽出 し、base64表現からデコードします。
$ cat demo.kubeconfig | grep client-certificate-data | awk '{print $2}' | base64 --decode > demo.crt
次に、opensslコマンドを使用して 、証明書の内容を取得します。
ubuntu@node1:~$ openssl x509 -in demo.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
71:8b:a4:4d:be:76:70:8a:...:07:60:67:c1:2d:51:94
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = kubernetes-ca
Validity
Not Before: Dec 2 13:50:00 2020 GMT
Not After : Dec 2 13:50:00 2021 GMT
Subject: O = development, CN = demo
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:be:87:dd:15:46:91:98:eb:b8:38:34:77:a4:99:
da:4b:d6:ca:09:92:f3:29:28:2d:db:7a:0b:9f:91:
65:f3:11:bb:6c:88:b1:8f:46:6e:38:71:97:b7:b5:
9b:8d:32:86:1f:0b:f8:4e:57:4f:1c:5f:9f:c5:ee:
40:23:80:99:a1:77:30:a3:46:c1:5b:3e:1c:fa:5c:
- 発行者のプロパティはkubernetes-caです。これは、k0sクラスターのCAです。
- 件名はO =開発、CN =デモ; この部分は、ユーザーの名前とグループが入る場所であるため、重要です。証明書はクラスターCAによって署名されているため、api-server上のプラグインは、証明書のサブジェクトの共通名（CN）と組織（O）によってユーザー/グループを認証できます。
まず、この新しいkubeconfigファイルで定義されたコンテキストを使用するようにkubectlに指示します 。
$ export KUBECONFIG=$PWD/demo.kubeconfig
次に、ノードのリストを再度表示し、クラスターノードを列挙します。
$ kubectl get no Error from server (Forbidden): nodes is forbidden: User “demo” cannot list resource “nodes” in API group “” at the cluster scope
このエラーメッセージは予期されていました。
api-server
ユーザーが識別された場合（ユーザー要求で送信された証明書がクラスターCAによって署名された場合）でも 、ユーザーはクラスターに対してアクションを実行できません。
追加の権限は、を作成
Role/ClusterRole
してユーザーに割り当てることで簡単に追加でき ますが
RoleBinding/ClusterRoleBinding
、このタスクは読者の演習として残しておきます。
結論
k0sは間違いなく検討する価値があります。このアプローチは、単一のバイナリファイルがすべてのプロセスを管理する場合、非常に興味深いものです。
この記事ではk0の概要のみを説明しますが、私は間違いなくその開発を追跡し、この新しい有望なKubernetesディストリビューションに今後の記事を捧げます。将来の機能のいくつかは本当に有望であるように思われます、そして私はそれらをテストすることを楽しみにしています。