1
1

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.

EKSでKubeEdgeを構築したら失敗した

Last updated at Posted at 2020-04-06

はじめに

前記事のとおり、KubeEdgeはエッジ特有の問題をK8sを拡張する形で解決するOSSです。
ですが、K8sはクラスタのバージョンアップ運用などが重い(ライフサイクルも9ヶ月程度と短い)と言われています。KubeEdgeでエッジ運用が軽くなってもK8sの運用が重くのしかかるのは意味がないため、各クラウドベンダで提供されているマネージドK8s+KubeEdgeの組み合わせで構築できないか試してみました。結果失敗したのですが。。
ただし、構築手順としては有用だと思うので、本記事として残しておきます(次回は自前でクラスタを構築して、KubeEdgeの構築検証を行います)

なお、2020年3月中旬現在、KubeEdge 1.2.1がリリースされていますがEKSで利用する場合マイナーバージョンの表記(EKSの場合、kubectl versionするとMinor:"14+"などと返ってきます)の問題でkeadmを用いてKubeEdgeをインストールできない問題があります。
その問題が最近のIssueで取り込まれ解決されているため、KubeEdgeのバイナリの一つであるkeadmはHEADからビルドされたものを利用します。次のリリースでは直っているはず!
KubeEdge1.2.1をEKSにインストールするとどうなるかはKubeEdge1.2.1の罠をご参照ください。

実行環境

今回ためした実行環境は以下の通りです。

ローカル

  • macOS Catalina(10.15.3)
  • zhs + prezto
  • aws-cli/1.18.24 Python/3.8.2 Darwin/19.3.0 botocore/1.15.24
  • Homebrew 2.2.10

EKS

  • 1.14

KubeEdge Master Node

  • Ubuntu Server 18.04 LTS (HVM), SSD Volume Type - ami-07f4cb4629342979c (64 ビット x86)
  • t3.medium
  • kubectl 1.17.4
  • golang 1.13.8
  • keadm HEAD(506b130)
  • KubeEdge 1.2.1

KubeEdge Worker Node

本来はエッジサーバやRaspberry Piなどの機器で実行するものですが、NWのつなぎこみ等手間がかかるので今回はEC2で構築し、これをEdgeNodeとして見立てます。
EC2は以下のインスタンスを立てました。HEADを見る限り、CentOSなどへの対応が進められていますが、現状はMasterNodeもEdgeNodeもUbuntuのみ対応です。

  • Ubuntu Server 18.04 LTS (HVM), SSD Volume Type - ami-07f4cb4629342979c (64 ビット x86)
  • t3.medium

KubeEdge Master Nodeのセットアップ

早速セットアップしていきます。

諸々アップデート

おまじないですが、やっておきます。

# apt-get update
# apt-get upgrade

eksctlセットアップ

本質ではないので、ざっと書きます。
アクセスキーはeksctlでクラスタを作成したときに使ったIAM Userに紐づくものを使いました。本当は別のユーザつくるべきだけど、一旦実験のためこのまま。。。

# apt-get install python-pip
# pip install awscli

# curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
# chmod +x ./kubectl
# sudo mv ./kubectl /usr/local/bin/kubectl

##アクセスキーはeksctlでクラスタを作成したときと同じユーザのアクセスキーを使用
# aws configure
AWS Access Key ID [None]: XXXX
AWS Secret Access Key [None]: YYYY
Default region name [None]: ap-northeast-1
Default output format [None]: json

##cluster_nameは自分のクラスタ名に書き換え
# aws eks --region ap-northeast-1  update-kubeconfig --name cluster_name
Updated context arn:aws:eks:ap-northeast-1:481892925438:cluster/dev-sumih in /root/.kube/config

keadmのビルド

現時点の最新版、1.2.1を使うとkeadm initに失敗します。。
が、私が試した直前にIssueを上げられており、即コミュニティで改修されていました。ありがたやありがたや。
まだリリースはされていないので、masterブランチのHEADからkeadmをビルドします。
公式そのままなので、だーっと行きます。

golangのインストール

keadmをビルドするためにgolangをインストールします。
インストールにはgoenvを利用し、インストール手順に従ってインストールしていきます。

##goenvのチェックアウト
# git clone https://github.com/syndbg/goenv.git ~/.goenv

##パスの追加。
##Ubuntuはbash_profile読まないのでbashrcへパスを通す
# echo 'export GOENV_ROOT="$HOME/.goenv"' >> ~/.bashrc
# echo 'export PATH="$GOENV_ROOT/bin:$PATH"' >> ~/.bashrc
# echo 'eval "$(goenv init -)"' >> ~/.bashrc

##ターミナルの再起動

##golang 1.13系の最新版(執筆時点)の1.13.8をインストール
# goenv install  1.13.8
Downloading go1.13.8.linux-amd64.tar.gz...
-> https://dl.google.com/go/go1.13.8.linux-amd64.tar.gz
Installing Go Linux 64bit 1.13.8...
Installed Go Linux 64bit 1.13.8 to /root/.goenv/versions/1.13.8
# goenv global 1.13.8

##go versionを実行してインストールしたバージョンが表示されれば完了
# go version
go version go1.13.8 linux/amd64

ビルド

##リポジトリのクローン。ブランチはHEADを使いたいため、Masterでよい
# git clone https://github.com/kubeedge/kubeedge.git $GOPATH/src/github.com/kubeedge/kubeedge

##ビルドの実行
# cd $GOPATH/src/github.com/kubeedge/kubeedge
# make all WHAT=keadm
# #エラーが出なければOK

##以下のパスにkeadmのバイナリが作成されていれば完了
# cd _output/local/bin/
# ls -l
total 37064
-rwxr-xr-x 1 root root 37952949 Mar 19 14:10 keadm

MasterNodeにKubeEdgeをインストール

ビルドしたkeadmを実行します。最後にCloudCore startedと出たら完了です。

##Masterで実行
##cloudcoreのバイナリダウンロードや証明書類の発行、デフォルトのコンフィグ作成などが行われる
# ./keadm init
Kubernetes version verification passed, KubeEdge installation will start...
~中略~
--2020-03-19 14:52:32--  https://github.com/kubeedge/kubeedge/releases/download/v1.2.1/kubeedge-v1.2.1-linux-amd64.tar.gz
Resolving github.com (github.com)... 52.69.186.44
Connecting to github.com (github.com)|52.69.186.44|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/150713223/aeeaee80-5b1e-11ea-990d-8a2b0361c493?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200319%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200319T145233Z&X-Amz-Expires=300&X-Amz-Signature=ca92d5ae66968f8dc1f0954279cf19e057f7ec954242bf608778764d79280f5b&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dkubeedge-v1.2.1-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream [following]
--2020-03-19 14:52:33--  https://github-production-release-asset-2e65be.s3.amazonaws.com/150713223/aeeaee80-5b1e-11ea-990d-8a2b0361c493?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200319%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200319T145233Z&X-Amz-Expires=300&X-Amz-Signature=ca92d5ae66968f8dc1f0954279cf19e057f7ec954242bf608778764d79280f5b&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dkubeedge-v1.2.1-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream
Resolving github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)... 52.216.107.20
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (github-production-release-asset-2e65be.s3.amazonaws.com)|52.216.107.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 81671481 (78M) [application/octet-stream]
Saving to: ‘kubeedge-v1.2.1-linux-amd64.tar.gz’

kubeedge-v1.2.1-lin 100%[===================>]  77.89M  9.22MB/s    in 9.9s    

2020-03-19 14:52:43 (7.89 MB/s) - ‘kubeedge-v1.2.1-linux-amd64.tar.gz’ saved [81671481/81671481]

Converted links in 0 files in 0 seconds.
kubeedge-v1.2.1-linux-amd64.tar.gz checksum: 
checksum_kubeedge-v1.2.1-linux-amd64.tar.gz.txt content: 
kubeedge-v1.2.1-linux-amd64/
kubeedge-v1.2.1-linux-amd64/edge/
kubeedge-v1.2.1-linux-amd64/edge/edgecore
kubeedge-v1.2.1-linux-amd64/cloud/
kubeedge-v1.2.1-linux-amd64/cloud/csidriver/
kubeedge-v1.2.1-linux-amd64/cloud/csidriver/csidriver
kubeedge-v1.2.1-linux-amd64/cloud/admission/
kubeedge-v1.2.1-linux-amd64/cloud/admission/admission
kubeedge-v1.2.1-linux-amd64/cloud/cloudcore/
kubeedge-v1.2.1-linux-amd64/cloud/cloudcore/cloudcore
kubeedge-v1.2.1-linux-amd64/version
+ readonly caPath=/etc/kubeedge/ca
+ caPath=/etc/kubeedge/ca
+ readonly caSubject=/C=CN/ST=Zhejiang/L=Hangzhou/O=KubeEdge/CN=kubeedge.io
+ caSubject=/C=CN/ST=Zhejiang/L=Hangzhou/O=KubeEdge/CN=kubeedge.io
+ readonly certPath=/etc/kubeedge/certs
+ certPath=/etc/kubeedge/certs
+ readonly subject=/C=CN/ST=Zhejiang/L=Hangzhou/O=KubeEdge/CN=kubeedge.io
+ subject=/C=CN/ST=Zhejiang/L=Hangzhou/O=KubeEdge/CN=kubeedge.io
+ genCertAndKey edge
+ ensureFolder
+ '[' '!' -d /etc/kubeedge/ca ']'
+ mkdir -p /etc/kubeedge/ca
+ '[' '!' -d /etc/kubeedge/certs ']'
+ mkdir -p /etc/kubeedge/certs
+ ensureCA
+ '[' '!' -e /etc/kubeedge/ca/rootCA.key ']'
+ genCA
+ openssl genrsa -des3 -out /etc/kubeedge/ca/rootCA.key -passout pass:kubeedge.io 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
...................................................................................................++++
...................................................................................................................................................................................++++
e is 65537 (0x010001)
+ openssl req -x509 -new -nodes -key /etc/kubeedge/ca/rootCA.key -sha256 -days 3650 -subj /C=CN/ST=Zhejiang/L=Hangzhou/O=KubeEdge/CN=kubeedge.io -passin pass:kubeedge.io -out /etc/kubeedge/ca/rootCA.crt
Can't load /root/.rnd into RNG
140296422785472:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
+ local name=edge
+ openssl genrsa -out /etc/kubeedge/certs/edge.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
....+++++
...................................................................................+++++
e is 65537 (0x010001)
+ openssl req -new -key /etc/kubeedge/certs/edge.key -subj /C=CN/ST=Zhejiang/L=Hangzhou/O=KubeEdge/CN=kubeedge.io -out /etc/kubeedge/certs/edge.csr
Can't load /root/.rnd into RNG
140176909926848:error:2406F079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:88:Filename=/root/.rnd
+ openssl x509 -req -in /etc/kubeedge/certs/edge.csr -CA /etc/kubeedge/ca/rootCA.crt -CAkey /etc/kubeedge/ca/rootCA.key -CAcreateserial -passin pass:kubeedge.io -out /etc/kubeedge/certs/edge.crt -days 365 -sha256
Signature ok
subject=C = CN, ST = Zhejiang, L = Hangzhou, O = KubeEdge, CN = kubeedge.io
Getting CA Private Key

Certificates got generated at: /etc/kubeedge/ ca and /etc/kubeedge/ certs
certs/
certs/edge.csr
certs/edge.crt
certs/edge.key

Certificates got tared at: /etc/kubeedge/ path, Please copy it to desired edge node (at /etc/kubeedge/ path)

KubeEdge cloudcore is running, For logs visit:  /var/log/kubeedge/cloudcore.log
CloudCore started

KubeEdge Worker Nodeのセットアップ

諸々アップデート

おまじないですが、やっておきます。

# apt-get update
# apt-get upgrade

Dockerのインストール

公式ドキュメントをみてインストールします。

# apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -

##x86_64/amd64はコレ
##arm等の場合は公式を見てリポジトリのURLを判断すること
# add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

# apt-get update
# apt-get install docker-ce docker-ce-cli containerd.io

KubeEdgeのインストール

MasterNodeの/etc/kubeedge/配下のファイル郡をWorkerNodeの/etc/kubeedge配下へコピーします。
また、先程ビルドしたkeadmも同様に自分のホームディレクトリや/usr/local/binなどにコピーします。

クラスターへのJoin

以下のコマンドを実行すれば、EdgeNodeのバイナリ郡がダウンロードされ、MasterNodeを経由してK8sにWorkerNodeとして登録されるはずです!

~# ./keadm join --cloudcore-ipport=192.168.10.195:10000 
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libev4 libwebsockets8
The following NEW packages will be installed:
  libev4 libwebsockets8 mosquitto
0 upgraded, 3 newly installed, 0 to remove and 3 not upgraded.
Need to get 214 kB of archives.
After this operation, 584 kB of additional disk space will be used.
Get:1 http://ap-northeast-1.ec2.archive.ubuntu.com/ubuntu bionic/universe amd64 libev4 amd64 1:4.22-1 [26.3 kB]
Get:2 http://ap-northeast-1.ec2.archive.ubuntu.com/ubuntu bionic/universe amd64 libwebsockets8 amd64 2.0.3-3build1 [71.8 kB]
Get:3 http://ap-northeast-1.ec2.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 mosquitto amd64 1.4.15-2ubuntu0.18.04.3 [116 kB]
Fetched 214 kB in 1s (155 kB/s)
Selecting previously unselected package libev4.
(Reading database ... 56588 files and directories currently installed.)
Preparing to unpack .../libev4_1%3a4.22-1_amd64.deb ...
Unpacking libev4 (1:4.22-1) ...
Selecting previously unselected package libwebsockets8:amd64.
Preparing to unpack .../libwebsockets8_2.0.3-3build1_amd64.deb ...
Unpacking libwebsockets8:amd64 (2.0.3-3build1) ...
Selecting previously unselected package mosquitto.
Preparing to unpack .../mosquitto_1.4.15-2ubuntu0.18.04.3_amd64.deb ...
Unpacking mosquitto (1.4.15-2ubuntu0.18.04.3) ...
Setting up libev4 (1:4.22-1) ...
Setting up libwebsockets8:amd64 (2.0.3-3build1) ...
Setting up mosquitto (1.4.15-2ubuntu0.18.04.3) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for systemd (237-3ubuntu10.39) ...

MQTT is installed in this host
Expected or Default KubeEdge version 1.2.1 is already downloaded
kubeedge-v1.2.1-linux-amd64/
kubeedge-v1.2.1-linux-amd64/edge/
kubeedge-v1.2.1-linux-amd64/edge/edgecore
kubeedge-v1.2.1-linux-amd64/cloud/
kubeedge-v1.2.1-linux-amd64/cloud/csidriver/
kubeedge-v1.2.1-linux-amd64/cloud/csidriver/csidriver
kubeedge-v1.2.1-linux-amd64/cloud/admission/
kubeedge-v1.2.1-linux-amd64/cloud/admission/admission
kubeedge-v1.2.1-linux-amd64/cloud/cloudcore/
kubeedge-v1.2.1-linux-amd64/cloud/cloudcore/cloudcore
kubeedge-v1.2.1-linux-amd64/version

KubeEdge edgecore is running, For logs visit:  /var/log/kubeedge/edgecore.log
root@ip-192-168-10-205:~# 

見た目はうまくいっているように見えます!

クラスターにJoinしたノードの確認

kubectlを実行できる環境から、ノードが登録されているか確認してみます。

# kubectl get node
NAME                                                STATUS     ROLES    AGE     VERSION

なにも。。。でない。。。

このあと、WorkerNodeを再Join(keadm resetをしたあとにkeadm join ~)を試してみたり、再Joinした直後にkubectl get nodeを連打してみたら、わかったことがありました。
Join直後は、一瞬ノードのステータスがUnknownで登録されるのです。そして、数秒後にノードが削除されるのです。

# kubectl get node
NAME                                                STATUS     ROLES    AGE     VERSION
ip-192-168-10-205                                   Unknown    edge     1s      v1.17.1-kubeedge-v1.2.1

EKSが悪さしている気がしたのでCloudWatchLogsに出力していたAPI Serverのログを確認したところ、ビンゴでした。
うん、Invalid format for AWS instance ()とか怒られてますね。


I0323 09:44:25.534757 1 node_lifecycle_controller.go:1039] Controller detected that all Nodes are not-Ready. Entering master disruption mode.
E0323 09:44:27.116520 1 node_lifecycle_controller.go:154] error checking if node ip-192-168-10-205 is shutdown: Invalid format for AWS instance ()
I0323 09:44:27.255006 1 node_lifecycle_controller.go:180] deleting node since it is no longer present in cloud provider: ip-192-168-10-205

該当ソースを読みすすめると、クラウドコントローラーマネージャーでエラーが出ているようです。
ドキュメントを読みすすめると、クラウドベンダが提供するマネージドK8sはこれを作りこんで、EC2といったコンピュートリソースのライフサイクル管理やIAM等の認証情報の管理をしているようです。
これに対応できないKubeEdgeがWorkerNodeを登録しようとしたことで、クラウドコントローラーマネージャーが正常ではないWorkerNodeと判断しWorkerNodeを削除したようです。
とういことは、EKSに限らずGKEやAKSといったマネージドK8sでもKubeEdgeを利用できない可能性が高いです。要するに詰みました。。。

諦めずに解決方法を探してみる

諦めずになにかワークアラウンドでもないか探してみます。
GitHubのIssueになにかないか。。。→ない!
じゃあSlackは。。。→私がつまずいた問題のIssueを開いた主がいらっしゃるじゃないですか!しかも同じところでハマってるw

ということでコンタクトを取ってみると、彼がAWSのサポートに聞いてくれるそうです。(私もビジネスサポート契約していますがちょうど問い合わせができない環境にいたので助かりました。。。)
ということでサポートからの返答結果は以下です↓

I see that you are trying to add Raspberry Pi device as a worker node (using kubeedge) in existing EKS cluster. On doing so, worker node is stuck in NotReady status.
I have reviewed the below error which suggest that kubelet was not running on the node (i.e. edge node).
I0323 09:44:25.523382 1 node_lifecycle_controller.go:958] Condition MemoryPressure of node ip-192-168-10-205 was never updated by kubelet
E0323 09:44:27.116520 1 node_lifecycle_controller.go:154] error checking if node ip-192-168-10-205 is shutdown: Invalid format for AWS instance ()
The worker nodes in a Kubernetes cluster runs kubelet component, which is responsible for registering the node to the cluster and communication with the control plane. 
If kubelet is not responding/updating health status, then Cloud-controller considers the node as NotReady. Based on that, actual issue lies on the worker node side as kubelet on them is not running correctly.
Further to that, 
- EKS uses IAM for authentication (IAM role should be attached to worker node) and worker node should use bootstrap script [1] in order to join to the cluster.
- EKS supports EKS optimized AMIs [2] as worker nodes (which are packaged with kubelet and all the required configuration).
- You can add additional linux based worker node (with EKS optimized AMI) using following document [3].
- In this case, worker nodes (edge) are not standard EKS AMI, they might not be using same kubelet configurations and IAM authentication.
Based on above, I suspect that you can not use those devices as EKS worker nodes. I would suggest to confirm from the community on kubeedge for kubelet behavior and worker node registration to Cloud Provider (like EKS, As EKS nodes have specific requirement).
I found one similar issue in kubeedge github repo [4], which talks about same NotReady status. If EKS is not fit for the usecase, I would suggest creating a Kubernetes cluster with kubeadm tool.
Please note that providing support on 3rd party products (i.e. kubeedge), Custom AMI and Kubernetes cluster creation(on EC2)/configuration is outside the scope of AWS Support.

要するに、

  • EKSはEKSに最適化されたAMI(マネージドノードとして起動可能なAmazonLinux2や、EKS最適化されたUbuntuAMIですね)しか使えない
  • WoerkerのJoinには上記のAMIからBootstrapスクリプトを実行する必要がある
  • またJoinの際にはEKSのWorkerNode要件に準拠したIAMロールが必要

ということで、KubeEdgeはつかえないよーとのことでした。。
ここまで回答を得られたら、もう諦めるしかない。。。ということで、次回はK8sクラスタを作るところからはじめ、まずはKubeEdgeを動かし旨味はなになのか、を考えるところをやってみます。
K8s運用辛い説の話は別途考えます。(シンプルにK8sを最小限にしたK3sとかのほうがいいのかも?)

まとめ

EKSにKubeEdge1.2.1の構築を行ってみました。
その結果、keadmのバグ及びEKS等マネージドK8sの仕様上マネージドK8s上でKubeEdgeは構築できないことがわかりました。
KubeEdge自体はCNCFのサンドボックスプロジェクトとして非常に将来性があり、有用なプロダクトとして考えられるため、引き続き深堀りしていきたいと思います。
次回は自分でK8sを構築し、その上にKubeEdgeをインストールしてみます。

次回KubeEdgeを構築する(再)を書きました。

おまけ

KubeEdge1.2.1の罠

おまけとしてKubeEdgeの罠を載せておきます。
事象が発生するのは、1.2.1以前のKubeEdgeをWorkerNodeで動かすタイミングです。

Master NodeへのKubeEdge 1.2.1のインストール

keadm initをすれば、Master Nodeへのインストールは完了するはずですが、
Your minor version of K8s is lower than 11, please reinstall newer versionとでます。

# ./keadm init
Error: Your minor version of K8s is lower than 11, please reinstall newer version
Usage:
  keadm init [flags]

Examples:

keadm init

- This command will download and install the default version of KubeEdge cloud component

keadm init --kubeedge-version=1.2.0  --kube-config=/root/.kube/config

  - kube-config is the absolute path of kubeconfig which used to secure connectivity between cloudcore and kube-apiserver


Flags:
  -h, --help                      help for init
      --kube-config string        Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config")
      --kubeedge-version string   Use this key to download and use the required KubeEdge version
      --master string             Use this key to set K8s master address, eg: http://127.0.0.1:8080

error: Your minor version of K8s is lower than 11, please reinstall newer version
root@ip-192-168-10-195:~/keadm-v1.2.1-linux-amd64/keadm# 

EKSで用いているバージョンは1.14ですが、kubectl versionで確認してみるとマイナーバージョンを14+としているじゃないですか。。
ソース見てみると、数値以外が入ることを想定していないため、バージョン比較がうまくいかずコケている感じでした。
現状は[このIssue] (https://github.com/kubeedge/kubeedge/issues/1546)で修正されているため、HEADから`keadm`をビルドすればこの問題は解決しています。

# kubectl version                                                                                                                                                                                       Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T23:41:24Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.9-eks-502bfb", GitCommit:"502bfb383169b124d87848f89e17a04b9fc1f6f0", GitTreeState:"clean", BuildDate:"2020-02-07T01:31:02Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
1
1
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
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?