RBACの付与(EKS)

参照：https://blog.denet.co.jp/adcale2024_eks-cluster-console-permission-error-solution/

以下、表示がないので権限の追記を行ってみる

その１

その２

結果：

実験終了：

Node削除の検証

1)作成ずみのnodeを止めて見る。

2)しばらくすると、新規でnode の作成が始まる。

k8s技術メモ

1)Config mapで使用で、各種チューニングを検討する。

https://qiita.com/petitviolet/items/ee4b1bdba2670a1d6a12

2)セキュリティ調査専用のコンテナ(pod)

https://qiita.com/oke-py/items/58ba2747b9ed387817b3

3)ディザスターリカバリ対策

①Heptio Ark

   -クラスターやPersistentVolumeのバックアップ、リカバリが可能。

   -etcdではなく Kubernetes API を使ってバックアップ/リストアを行う

   -バックアップしたデータはAWS S3 などのオブジェクトストレージに保存

   -PersistentVolume のバックアップにはクラウドプロバイダの API を利用

https://www.wantedly.com/companies/wantedly/post_articles/135823

※Heptio と Microsoft が関わっており将来性も期待できる。

■master/node の概要図

■Master/Nodeについて

1. Master

Kubernetesクラスタ内のコンテナを操作するためのサーバです。kubectlコマンドを使ってクラスタを構成したりリソースを操作したりする際は、マスターサーバがコマンドからのリクエストを受け取って処理を行います。複数台からなるKubernetesクラスタ内のノードのリソース使用状況を確認して、コンテナを起動するノードを自動的に選択します。Kubernetesがオーケストレーションツールと呼ばれるのも、このマスターサーバが複数台からなる分散したノードをまとめて管理することで、あたかも1台のサーバであるかのようにふるまいます。 　

■kube-apiserver

Kubernetesのリソース情報を管理するためのフロントエンドのREST APIです。各コンポーネントからリソースの情報を受け取りetcd上に格納します。他のコンポーネントはこのetcdの情報にkube-apiserverを介してアクセスします。このkube-apiserverにアクセスするには、GUIツールやkubebtlコマンドを使います。また、アプリケーション内からkube-apiserverを呼び出すことも可能です。kube-apiserverは認証／認可の機能も持っています。

■kube-scheduler

kube-schedulerはPodをどのNodeで動かすかを制御するコンポーネントです。kube-schedulerは、ノードに割り当てられていないPodに対して、Kubernetesクラスタの状態を確認し、空きスペースを持つNodeを探してPodを実行させるスケジューリングを行います。

■kube-controller-manager

kube-controller-managerはKubernetesクラスタの状態を常に監視するコンポーネントです。定義ファイルで指定したものと実際のNodeやコンテナで動作している状態をまとめて管理します。

2. Node

実際にDockerコンテナを動作させPodを稼働させるサーバです。AKSでは仮想マシン(VM)で構成され、通常は複数用意して、クラスタを構成します。ノードの管理は、マスターサーバが行います。何台ノードを用意するかは、システムの規模や負荷によって異なりますが台数が増えると可用性が向上します。なお、kubeproxyというコンポーネントも動作しますが、説明は別ブログで。

■kubelet

kubeletは、Podの定義ファイルに従ってコンテナを実行したり、ストレージをマウントしたりするエージェント機能を持ちます。またKubeletは、Nodeのステータスを定期的に監視する機能を持ちステータスが変わるとAPIServerに通知します。

3. etcd

Kubernetesクラスタの構成を保持する分散KVSです。Key-Value型でデータを管理します。どのようなPodをどう配置するかなどの情報を持ち、APIServerから参照されます。

■オートヒーリング機能

Podを自動的に復旧させる機能をオートヒーリング(Auto Healing)機能といいます。

k8sメリット/デメリット

◽️k8sのメリット

①ローリングアップデートによる無停止運用が可能 ->ただし、podがレプリケートしていること前提。

②容易なスケーリング

③リソースの修正 ->ローリングアプデート前提になりますが無停止でできるのが利点

④オートヒーリング機能 ->pod(コンテナ)が停止ても復旧できる機能

⑤スケジューリング機能   ->各nodeのリソース状況などに応じて、podの割り当てを行える

◽️k8sのデメリット(障害事例)

過去の障害事例を見るとnode故障関連が多いようです。
①nodeの障害   ->nodeがNotReadyになった場合、再作成を行う必要がある。(基本的に、複数のnodeが稼働前提になるので、運用状問題ないと思われる。)　　　
参考：https://unicorn.limited/jp/item/808

②node障害後のpodの移動 ->1つのpodのみで、node故障が発生して、他のnodeに移動しない現象ありMaster側で、各nodeにpodの再割り当て（スケジューリング）をするところ正確にできてない現象。


解決案：deschedulerというのスケジューリングの偏りを検知して、再スケジュールしてくれる機能
参照：http://bbrfkr.hatenablog.jp/entry/2019/04/12/153509

③バージョンアップにあるk8sの不具合発生など   ->過去に不具合の事例が出ているようですが検証後導入するか　　事前に悪評があれば様子見で対処できるか思います。

④クラスタが丸ごと故障した場合   ->node及びpodが使用不可※ただし、外ずけにしたディスクについては生きているので、保存データの担保できると思う。

⑤ヒューマンエラー(Spotifyでの事例)例：クラスタ及びnodeの削除参考：https://www.itmedia.co.jp/news/articles/1907/08/news074.html

退避：バックアップ/ディザスターリカバリーのテストなどを行う。
上記を含め、コード化による作業が全般になるのでヒューマンエラー比率が上がるのは確か。

対策①：クラスタ障害時に、非k8sのインスタンスへの切り替えを検討。対策②：リージョン間でクラスタリングを作成して、冗長化を行う。 

メモ：①本番・ステージング・開発で環境を分ける。②nodeについては、本番用node/ステージング＆開発node(内部で、NameSpaceで区切る)

EKSクラスターだけを削除してしまったときの対処法

AWS CloudFormation スタックを削除

取り残されたスタックがあるかもしれないので、削除を行うこと。

https://console.aws.amazon.com/cloudformation

以下、不要な物が表示されているようなら削除を実施する。

メモ：

クラスターをEKS経由で削除した場合、上記の確認をしてみても良いかも

AWS EKSの使い方

1)今回、kubernetes 1.13をダウンロードする。curl-okubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/darwin/amd64/kubectl
ダウンロード中

2)オプションだけど、チェックサムもやっておくcurl-okubectl.sha256 https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/darwin/amd64/kubectl.sha256

3)チェックサムの確認


4)権限付与も行っておくchmod +x ./kubectl


5)バイナリーをpathフォルダにコピーしておくmkdir-p$HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

6)シェルを開いたときに設定されるように、シェルの初期化ファイルに $HOME/bin パスを追加echo'exportPATH=$HOME/bin:$PATH' >> ~/.bash_profile

7)以下のコマンドが表示されていること


■eksctlインストール
1)home osのインストールを行う。/usr/bin/ruby-e"$(curl-fsSLhttps://raw.githubusercontent.com/Homebrew/install/master/install)"



2)Weaveworks Homebrew tap をインストールします。brew tap weaveworks/tap


3)eksctlをインストールする。brew install weaveworks/tap/eksctl


4)コマンドの導入が完了したので、k8sの作成を行ってみる。 ->t2.micro（無料枠にしてみた。最大２台までしかnode作成不可らしい）
eksctl create cluster \--name prod\                      <———重複してないこと！！--version 1.13\--nodegroup-name standard-workers\--node-type t3.micro\--nodes 3\--nodes-min 1\--nodes-max 4\--node-ami auto


クラスタ作成中（完成まで時間がかかる。）クラスターのプロビジョニングには通常、10 ~ 15 分かかるとのこと。。。


ということで、完成した。


コマンドで確認してみる。

Amazon EKS for nginx

1)作成した、nignxが外部公開ができてない。

実際に、以下のアドレスで疎通が失敗する。

http://a8bf4949dd04f11e9ac830ebf092f042-109072427.ap-northeast-1.elb.amazonaws.com:8080

原因：

ロードバランス側のセキュリティグループに該当のポートを開けることで解決

解決。