コレを見てくれ
TypeScriptでElement implicitly has an 'any' type because expression of type 'string'エラー
環境
- TypeScript 4
問題
例えば以下のようなサンプルコードがあったとする
function receivedStringValue() : string { return 'apple'; } const fruits = { apple: 'りんご', banana: 'バナナ', melon: 'メロン' }; const key: string = receivedStringValue(); const value = fruits[key];
が、実はコレだといかのようなエラーになる
Element implicitly has an 'any' type because expression of type 'string' can't be used to index type '{ apple: string; banana: string; melon: string; }'.
No index signature with a parameter of type 'string' was found on type '{ apple: string; banana: string; melon: string; }'.ts(7053)
fruits[key] のkeyの型がわからん、といった感じだろうか
解決方法１
明示的にinterface FruitsKey を作成する。そうすることでfruitsのキーのいずれか来るということがわかりエラーにならなくなる
-const fruits = { +interface FruitsKey { + [key: string]: any; +} + +const fruits: FruitsKey = { apple: 'りんご', banana: 'バナナ', melon: 'メロン' }; const key: string = receivedStringValue(); const value = fruits[key];
解決方法２
keyを key as keyof typeof Foo の形にする。
const fruits = {
apple: 'りんご',
banana: 'バナナ',
melon: 'メロン'
};
-const value = fruits[key];
+const value = fruits[key as keyof typeof fruits];
解決方法２のほうが簡単だが１の方がfruitのValue側の方も決めれるのでより厳密な定義ができそう？
参考リンク
Kubernetesでコントロールプレーンを増やす方法
環境
- Kubernetes 1.24
やりたいこと
kubeadmでKubernetesのクラスタを生成すると１台目のノードがマスターノードとなる。つまりcontrol-planeは１台構成
一般的には２台以上が推奨なのでもう１台増やしてみる
手順
まずはkubeadmコマンドでcontrol-plane証明書を更新する
# kubeadm init phase upload-certs --upload-certs [upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace [upload-certs] Using certificate key: 22e1b256080eb4233afb5a1f49fe5d2c85532daa114986a2a29d50e6d7806023
次にクラスタに追加する用のコマンドを生成する
# kubeadm token create --print-join-command kubeadm join control-plane.minikube.internal:8443 --token nl6a49.h007qqkw7h12lelf --discovery-token-ca-cert-hash sha256:7e0a541aa19430dfaddd77206ac1514488270cbac740c5ab0e3cf5e19e223df2
最後に新品のkubeadmインストール済みのサーバーで以下を実行 kubeadm token create で表示されたコマンドに--certificate-keyを追加するのがポイント
kubeadm join control-plane.minikube.internal:8443 --token nl6a49.h007qqkw7h12lelf --discovery-token-ca-cert-hash sha256:7e0a541aa19430dfaddd77206ac1514488270cbac740c5ab0e3cf5e19e223df2 --control-plane --certificate-key 22e1b256080eb4233afb5a1f49fe5d2c85532daa114986a2a29d50e6d7806023
参考リンク
マスターノード ＝ コントロールプレーンではない
マスターノード ≠ コントロールプレーン
Kubernetesのクラスタにおいてクラスタ管理のみに徹する役割をコントロールプレーンという。てっきり言葉遊びでマスターノードとコントロールプレーンは同じ意味だと思っていたが全く違った。
正確にはマスターノードの役割の中の１つにコントロールプレーンを含む。らしい。
コントロールプレーンの対義語は
実際のコンテナが動く役割を「データプレーン」という。
つまり図にするとこういう事
kubeadmで構築するときの１台目のノードは？
あれは当然最初コントローラーも動いているのでマスターノードである。その後ノードを追加する際にワーカーノードとするか、コントロールプレーンも含んだノード、いわゆるマスターノードにするかは任意となる。
マスターノードとワーカーノードの違いは？
どのノードにもコントロールプレーンもデータプレーンを乗せられるので、構築１台目のノードみたいにマスターノードだけどコントロールプレーンだけではなくデータプレーンも持つことはできる。
が、一般的にKubernetesのクラスタを管理するノードと実際にコンテナを動かすノードは別れていたほうが障害に強いのでマスターノードにはコントロールプレーンしか乗せなくなる。
これが最初のマスターノード = コントロールプレーンと誤解してしまったんだと思う
kubeadmについては以下の本がめっちゃ詳しかった
