0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

kubernetes the hard way on PC (6.Certificates)

Last updated at Posted at 2020-07-14

#初めに
kubernetes the hard way を PC でやってみる」の6回目、「Certificates」についてです。( 目次
ここはやればできるがわからない、という部分だと思いますので、できれば丁寧にやりたいです。

下記の一連の手順は、 cfssl を導入したノードの特定のディレクトリで実施し、
最終的に、各ノードにコピーします。

この記事では、 「Provisioning a CA and Generating TLS Certificates」 部分について記載します。

  • Certificate Authority
  • Client and Server Certificates
      - The Admin Client Certificate
      - The Kubelet Client Certificates
      - The Controller Manager Client Certificate
      - The Kube Proxy Client Certificate
      - The Scheduler Client Certificate
  • The Kubernetes API Server Certificate
  • The Service Account Key Pair
  • 証明書の配置

#Certificate Authority

kubernetes 用の認証局 (CA) を作成します。実体としては、 CA 用の秘密鍵、証明書(公開鍵を含む)を作成しています。
手順としては kubernetes the hard way と全く同じで構いません。
ca-config.json は Client Sertificate 作成の際に利用しますが、逆に言えばここでは使用しません。
-initca で CAを初期化し、 CAの秘密鍵を生成し(①)、それと CSR設定ファイルから CSR ( Certificate Signing Request ) ファイルを生成します(②)。
最終的に CSRファイルから、CAの秘密鍵を用いて署名し、CAの証明書(公開鍵を含む)を生成しています(③)。
自分で署名するから自己証明書です。

40.png

※以後、各種ファイルや証明書を生成しますが、 特定の作業ディレクトリの中で実施します。
(対象ごとにディレクトリを分ける、とかしたくなるかもしれませんが、後々の各種コンポーネントの設定を書く際にパスを変えていくのが面倒なので同じところに入れておく方が楽です)

■ ca-config.json 作成

kubernetes the hard way では、コピー&ペーストですべてできるように、 cat コマンドで内容をファイルに流し込んでいます。
ここでは、単に内容のみ記載しておきます。(作り方はご自由に)
8760h ( 24h x 365d ) の有効期限を設定するようです。

{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "kubernetes": {
        "usages": ["signing", "key encipherment", "server auth", "client auth"],
        "expiry": "8760h"
      }
    }
  }
}

■ ca-csr.config

2048bit の RSA 暗号化方式を指定しています。
kubernetes のドキュメント Authenticating を見ると、 コモンネーム(CN) がユーザーとして扱われ、組織 (O) がグループとして扱われるようです。

{
  "CN": "Kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "CA",
      "ST": "Oregon"
    }
  ]
}

■ CSR/秘密鍵/証明書の作成

cfssl gencert -initca コマンドで CSR ファイルの作成、秘密鍵の作成、証明書の作成を一度に実施してくれるようです。
cfssljson は -bare <prefix> とともに利用し、 <prefix>.csr, <prefix>.pem, <prefix>-key.pem を作成してくれます。

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert -initca ca-csr.json | cfssljson -bare ca
2020/05/08 12:29:19 [INFO] generating a new CA key and certificate from CSR
2020/05/08 12:29:19 [INFO] generate received request
2020/05/08 12:29:19 [INFO] received CSR
2020/05/08 12:29:19 [INFO] generating key: rsa-2048
2020/05/08 12:29:19 [INFO] encoded CSR
2020/05/08 12:29:19 [INFO] signed certificate with serial number 508782391863434424064735503122959853057064661568
root@k8smaster0:/data/assam/k8s/ca# ls -l
total 20
-rw-r--r-- 1 root root  232 May  8 12:28 ca-config.json
-rw-r--r-- 1 root root 1005 May  8 12:29 ca.csr
-rw-r--r-- 1 root root  211 May  8 12:28 ca-csr.json
-rw------- 1 root root 1675 May  8 12:29 ca-key.pem
-rw-r--r-- 1 root root 1318 May  8 12:29 ca.pem

きちんと 秘密鍵は権限600 になっていますね。

#Client and Server Certificates
##The Admin Client Certificate

kubernetes the hard way で利用される admin ユーザーの証明書と秘密鍵を作成します。
"O" の system:masters グループは kubernetes の RBAC (Role Based Access Control) の仕組みで定義されています。
クラスターに対するフルコントロール権限を持ったcluster-admin というロールとユーザーを結びつける ClusterRoleBinding です。
(詳細は Using RBAC Authorization 参照)
簡単に言うと、 system:masters グループに入れたユーザーはフルコントロール権限つき、という感じです。

■admin-csr.json

{
  "CN": "admin",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:masters",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

■admin ユーザーの証明書・秘密鍵生成
admin ユーザーの証明書(並びに以後出てくる各種証明書)については、CA とは異なります。(自己証明ではなく CA に署名してもらいます)

41.png

admin の秘密鍵、CSR ファイル生成後、 CA の秘密鍵 (ca-key.pem) により署名を行い、 admin ユーザー用の証明書を作成します。
そのため、 cfssl コマンドには、引数として CA の秘密鍵等の情報を指定します。

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
>   -ca=ca.pem \
>   -ca-key=ca-key.pem \
>   -config=ca-config.json \
>   -profile=kubernetes \
>   admin-csr.json | cfssljson -bare admin
2020/05/08 12:31:41 [INFO] generate received request
2020/05/08 12:31:41 [INFO] received CSR
2020/05/08 12:31:41 [INFO] generating key: rsa-2048
2020/05/08 12:31:42 [INFO] encoded CSR
2020/05/08 12:31:42 [INFO] signed certificate with serial number 694810746206388404263951481686888860247057295553
2020/05/08 12:31:42 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

web サイトには合わないよ、という警告も出ていますが、 Web サイトで利用するわけではないため問題ありません。
(host フィールドでは Webサーバー等の FQDN を指定するようです)

admin.pem が証明書(公開鍵)、 admin-key.pem が秘密鍵です。
(admin.csr は Certificate signing Request ファイルとして作成されたのち、署名されて 証明書になります)

root@k8smaster0:/data/assam/k8s/ca# ls -l
total 36
-rw-r--r-- 1 root root 1033 May  8 12:31 admin.csr
-rw-r--r-- 1 root root  231 May  8 12:30 admin-csr.json
-rw------- 1 root root 1675 May  8 12:31 admin-key.pem
-rw-r--r-- 1 root root 1428 May  8 12:31 admin.pem

さてこの admin の証明書を例にとって、 kubernetes の各種証明書がどのように利用されているのかも
おさえておければと思います。
kubernetes を利用する際に、 kubectl コマンドを使います。
kubectl コマンドを使う際、デフォルトでは ~/.kube/config ファイルを読み込んで利用しています。
その config ファイル内には以下のようなエントリーがあります。

users:
- name: admin
  user:
    client-certificate: /var/lib/kubernetes/admin.pem
    client-key: /var/lib/kubernetes/admin-key.pem

また、 後で出てきますが、kubectl コマンドを受け付ける kube-apiserver の設定として、
以下のようなエントリーがあります。

[Service]
ExecStart=/usr/local/bin/kube-apiserver \\
  …(中略)
  --client-ca-file=/var/lib/kubernetes/ca.pem

何が言いたいかというと、以下の2点です。

  • kubectl 利用時には admin 用証明書が利用される
  • API Server 側は CA の証明書(公開鍵)を持っている

API Server は、リクエストしてきたクライアントが正しい(自分と同じCAから署名された証明書を持っている)かどうかを確認し、正しくなければ拒否しなければなりません。
その仕組みを下図で説明します。

42.png

クライアント側は admin 用証明書ファイル (admin.pem) を付けてリクエストを行います。
証明書ファイルには、 証明書自体と、その hash 値を CA の秘密鍵で署名(暗号化)したデータがついています。
(よって、 CAの署名付き証明書という方が適切なのですが、まとめて証明書というため、誤解を招きやすいです)
サーバー(API Server)側では、 受け取った証明書から hash 値を計算しておきます。
また、 CA の署名(秘密鍵による暗号化)を、 CAの証明書(公開鍵)で復号します。
復号により、 admin の証明書 hash 値が得られます。
復号により得られた hash 値と、計算によって得られた hash 値が同じであれば、
同じCA により発行された証明書を持っているリクエスターだ、と認証できます。

ここまでで、証明書による認証の仕組みは理解できたつもりになって、あとは淡々と証明書を作っていきます。

The Kubelet Client Certificates

淡々と作っていく、と言いながらいきなり少し違います。
kubernetes the hard way に倣って、3台のノード用の証明書をループを使って作成します。

簡単に説明しておくと、 k8sworker0, k8sworker1, k8sworker2 というノードそれぞれについて、
ノード名-csr.json という CSR ファイルを作成する、という内容です。
system:node は kubelet で必要となるアクセス権限(Secretの読み取りや Pod などのオブジェクトのステータス書き込み)を持つ ClusterRole です。

root@k8smaster0:/data/assam/k8s/ca# for instance in k8sworker0 k8sworker1 k8sworker2
> do
> cat > ${instance}-csr.json <<EOF
> {
>   "CN": "system:node:${instance}",
>   "key": {
>     "algo": "rsa",
>     "size": 2048
>   },
>   "names": [
>     {
>       "C": "US",
>       "L": "Portland",
>       "O": "system:nodes",
>       "OU": "Kubernetes The Hard Way",
>       "ST": "Oregon"
>     }
>   ]
> }
> EOF
> done

ファイルが生成されていることを確認します。

root@k8smaster0:/data/assam/k8s/ca# ls -l
total 48
-rw-r--r-- 1 root root  246 May  8 12:44 k8sworker0-csr.json
-rw-r--r-- 1 root root  246 May  8 12:44 k8sworker1-csr.json
-rw-r--r-- 1 root root  246 May  8 12:44 k8sworker2-csr.json
...(略)

次に cfssl で証明書等を発行します。
ここでいくつか注意事項を。 cfssl のオプションで指定する -ca などで指定しているファイル類ですが
カレントディレクトリに配置されている前提です。
そのため、パスが違う場合はパス指定で記入する必要があります。
また、 -hostname で ノード名と IP アドレスを指定しています。
この部分は、 kubernetes the hard way ( Google Cloud ベース ) では、
コマンドでホスト名、Internal IP, External IP を取得して指定しています。

※kubernetes the hard way では、ループを使って 全ノード分の証明書等を一度に発行していますが、
下記の例では、手動で1つのノードについて作成していますので、
下記の例を参考にする場合、3台分実施する必要があります。 
(ノード名、IP アドレス、CSR ファイル名を修正する必要があります)

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
> -ca=ca.pem \
> -ca-key=ca-key.pem \
> -config=ca-config.json \
> -hostname=k8sworker0,192.168.199.210 \
> -profile=kubernetes \
> k8sworker0-csr.json | cfssljson -bare k8sworker0
2020/05/08 12:47:27 [INFO] generate received request
2020/05/08 12:47:27 [INFO] received CSR
2020/05/08 12:47:27 [INFO] generating key: rsa-2048
2020/05/08 12:47:28 [INFO] encoded CSR
2020/05/08 12:47:28 [INFO] signed certificate with serial number 605113571011846143545506434636078855108165530669

きちんと3台分出力できれば、以下のファイルができているはずです。
(ノード名.csr, ノード名-key.pem, ノード名.pem です)

root@k8smaster0:/data/assam/k8s/ca# ls -l k8swork*
-rw-r--r-- 1 root root 1115 May  8 12:47 k8sworker0.csr
-rw-r--r-- 1 root root  246 May  8 12:44 k8sworker0-csr.json
-rw------- 1 root root 1675 May  8 12:47 k8sworker0-key.pem
-rw-r--r-- 1 root root 1493 May  8 12:47 k8sworker0.pem
-rw-r--r-- 1 root root 1115 May  8 12:48 k8sworker1.csr
-rw-r--r-- 1 root root  246 May  8 12:44 k8sworker1-csr.json
-rw------- 1 root root 1679 May  8 12:48 k8sworker1-key.pem
-rw-r--r-- 1 root root 1493 May  8 12:48 k8sworker1.pem
-rw-r--r-- 1 root root 1115 May  8 12:49 k8sworker2.csr
-rw-r--r-- 1 root root  246 May  8 12:44 k8sworker2-csr.json
-rw------- 1 root root 1675 May  8 12:49 k8sworker2-key.pem
-rw-r--r-- 1 root root 1493 May  8 12:49 k8sworker2.pem

##The Controller Manager Client Certificate

Controller-manager の CSR設定ファイルは以下の通りです。
system:kube-controller-manager は controller-manager に必要となる ClusterRole で、
詳細は こちら を参照ください。

■kube-controller-manager-csr.json

{
  "CN": "system:kube-controller-manager",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-controller-manager",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

cfssl で証明書類を生成します。

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
>   -ca=ca.pem \
>   -ca-key=ca-key.pem \
>   -config=ca-config.json \
>   -profile=kubernetes \
>   kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager
2020/05/08 12:51:52 [INFO] generate received request
2020/05/08 12:51:52 [INFO] received CSR
2020/05/08 12:51:52 [INFO] generating key: rsa-2048
2020/05/08 12:51:53 [INFO] encoded CSR
2020/05/08 12:51:53 [INFO] signed certificate with serial number 500890241095690598286296704808963956752213606109
2020/05/08 12:51:53 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

生成されるのは以下のものです。(csr と pem)

root@k8smaster0:/data/assam/k8s/ca# ls -l kube-contr*
-rw-r--r-- 1 root root 1090 May  8 12:51 kube-controller-manager.csr
-rw-r--r-- 1 root root  272 May  8 12:51 kube-controller-manager-csr.json
-rw------- 1 root root 1679 May  8 12:51 kube-controller-manager-key.pem
-rw-r--r-- 1 root root 1484 May  8 12:51 kube-controller-manager.pem

##The Kube Proxy Client Certificate

kube-proxy の CSR設定ファイルは以下の通りです。
system:node-proxier は kube-proxy に必要となる ClusterRole です。

■kube-proxy-csr.json

{
  "CN": "system:kube-proxy",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:node-proxier",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

cfssl で証明書類を生成します。

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
>   -ca=ca.pem \
>   -ca-key=ca-key.pem \
>   -config=ca-config.json \
>   -profile=kubernetes \
>   kube-proxy-csr.json | cfssljson -bare kube-proxy
2020/05/08 12:53:33 [INFO] generate received request
2020/05/08 12:53:33 [INFO] received CSR
2020/05/08 12:53:33 [INFO] generating key: rsa-2048
2020/05/08 12:53:33 [INFO] encoded CSR
2020/05/08 12:53:33 [INFO] signed certificate with serial number 721258430720639814654172522264099837686925207884
2020/05/08 12:53:33 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

生成されるのは以下のものです。(csr と pem)

root@k8smaster0:/data/assam/k8s/ca# ls -l kube-prox*
-rw-r--r-- 1 root root 1058 May  8 12:53 kube-proxy.csr
-rw-r--r-- 1 root root  248 May  8 12:53 kube-proxy-csr.json
-rw------- 1 root root 1679 May  8 12:53 kube-proxy-key.pem
-rw-r--r-- 1 root root 1452 May  8 12:53 kube-proxy.pem

##The Scheduler Client Certificate

kube-scheduler の CSR設定ファイルは以下の通りです。
system:kube-scheduler は kube-scheduler に必要となる ClusterRole です。

■kube-proxy-csr.json

{
  "CN": "system:kube-scheduler",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-scheduler",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

cfssl で証明書類を生成します。

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
>   -ca=ca.pem \
>   -ca-key=ca-key.pem \
>   -config=ca-config.json \
>   -profile=kubernetes \
>   kube-scheduler-csr.json | cfssljson -bare kube-scheduler
2020/05/08 12:54:39 [INFO] generate received request
2020/05/08 12:54:39 [INFO] received CSR
2020/05/08 12:54:39 [INFO] generating key: rsa-2048
2020/05/08 12:54:39 [INFO] encoded CSR
2020/05/08 12:54:39 [INFO] signed certificate with serial number 544978835480516286618393252202663197369532540673
2020/05/08 12:54:39 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

生成されるのは以下のものです。(csr と pem)

root@k8smaster0:/data/assam/k8s/ca# ls -l kube-sche*
-rw-r--r-- 1 root root 1066 May  8 12:54 kube-scheduler.csr
-rw-r--r-- 1 root root  254 May  8 12:54 kube-scheduler-csr.json
-rw------- 1 root root 1679 May  8 12:54 kube-scheduler-key.pem
-rw-r--r-- 1 root root 1460 May  8 12:54 kube-scheduler.pem

#The Kubernetes API Server Certificate

API Server に関しては、 ユーザー名 (CN) kubernetes, グループ (O) kubernetes で作成します。

{
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

cfssl での証明書等の発行ですが、いくつか注意事項があります。
kubernetes the hard way では、リモートからのクライアント接続等を考慮して、
関連する IP、ホスト名を -hostname 部分に指定しています。
Google Cloud の Public IP 等はコマンドで取得していますので、今部分は今回の環境では異なります。

今回設定するのは以下の通りです。

・ClusterIP (Service)用 NW の最初のIP
設定値: 10.32.0.1
 備考 :API Server 用の Cluster IP は Cluster IP 用 NW の最初のアドレスが自動的にアサインされるため

・マスターノードのIP
 設定値: 192.168.199.200, 192.168.199.201, 192.168.199.202

・関連サーバーのIP
 設定値: 192.168.199.199,192.168.199.2
備考 : 実際には使いませんでした。。。

・ローカルホストのIP
設定値: 127.0.0.1

・マスターノードのホスト名
 設定値:k8smaster0,k8smaster1,k8smaster2

・API Server 外部IP 用 IP ラベル
 設定値: k8sapi
 備考 : 3台のマスターノード上の kube-apiserver を外部公開する際の IP ラベル。負荷分散用。
      ただし今回はそこまでたどり着かず。。。

・API Server の内部 DNS 名
 設定値: kubernetes, kubernetes.default, kubernetes.default.svc,
kubernetes.default.svc.cluster, kubernetes.svc.cluster.local

コマンド実行は以下の通り

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
> -ca=ca.pem \
> -ca-key=ca-key.pem \
> -config=ca-config.json \
> -hostname=10.32.0.1,\
> 192.168.199.200,192.168.199.201,192.168.199.202,\
> 192.168.199.199,192.168.199.2,\
> 127.0.0.1,\
> k8smaster0,k8smaster1,k8smaster2,\
> k8sapi,\
> kubernetes,\
> kubernetes.default,\
> kubernetes.default.svc,\
> kubernetes.default.svc.cluster,\
> kubernetes.svc.cluster.local \
> -profile=kubernetes \
> kubernetes-csr.json | cfssljson -bare kubernetes
2020/05/08 13:18:50 [INFO] generate received request
2020/05/08 13:18:50 [INFO] received CSR
2020/05/08 13:18:50 [INFO] generating key: rsa-2048
2020/05/08 13:18:50 [INFO] encoded CSR
2020/05/08 13:18:50 [INFO] signed certificate with serial number 503513621329247339611120279569621714243026900892

生成されるファイルは以下の通りです。

root@k8smaster0:/data/assam/k8s/ca# ls -l kubernete*
-rw-r--r-- 1 root root 1358 May  8 13:18 kubernetes.csr
-rw-r--r-- 1 root root  232 May  8 13:05 kubernetes-csr.json
-rw------- 1 root root 1679 May  8 13:18 kubernetes-key.pem
-rw-r--r-- 1 root root 1728 May  8 13:18 kubernetes.pem

#The Service Account Key Pair

kubernetes の各種コンポーネントにアクセスするのは、ユーザーだけではなくサービスもあります。
サービスで利用する証明書などをここで生成します。

■service-account-csr.json

{
  "CN": "service-accounts",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

cfssl で証明書類を生成します。

root@k8smaster0:/data/assam/k8s/ca# cfssl gencert \
>   -ca=ca.pem \
>   -ca-key=ca-key.pem \
>   -config=ca-config.json \
>   -profile=kubernetes \
>   service-account-csr.json | cfssljson -bare service-account
2020/05/08 13:20:06 [INFO] generate received request
2020/05/08 13:20:06 [INFO] received CSR
2020/05/08 13:20:06 [INFO] generating key: rsa-2048
2020/05/08 13:20:06 [INFO] encoded CSR
2020/05/08 13:20:06 [INFO] signed certificate with serial number 437010543580248016577916432123942429566987773800
2020/05/08 13:20:06 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

生成されるのは以下のものです。(csr と pem)

-rw-r--r-- 1 root root 1041 May  8 13:20 service-account.csr
-rw-r--r-- 1 root root  238 May  8 13:19 service-account-csr.json
-rw------- 1 root root 1679 May  8 13:20 service-account-key.pem
-rw-r--r-- 1 root root 1440 May  8 13:20 service-account.pem

#証明書の配置

kubernetes the hard way では、各ノードのホームディレクトリに配置するコマンドになっていますが、
誰のホームディレクトリか記載がありません。
実際には、後で各ノードで適切な場所に再配置しますので、ここでの配置先はどのディレクトリでもかまいません。

  • マスターノード
    • ca.pem
    • ca-key.pem
    • kubernetes-key.pem
    • kubernetes.pem
    • service-account-key.pem
    • service-account.pem
  • ワーカーノード
    • ca.pem
    • ノード名-key.pem
    • ノード名.pem

今回はしんどかったですね。
今回はここまでとして、次回は Generating Kubernetes Configuration Files for Authentication の部分を実施します。

5.Client Tools
目次
7.k8sconfig


0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?