2019年9月13日金曜日
k8s技術メモ
1)Config mapで使用で、各種チューニングを検討する。
2)セキュリティ調査専用のコンテナ(pod)
3)ディザスターリカバリ対策
①Heptio Ark
-クラスターやPersistentVolumeのバックアップ、リカバリが可能。
-etcdではなく Kubernetes API を使ってバックアップ/リストアを行う
-バックアップしたデータはAWS S3 などのオブジェクトストレージに保存
-PersistentVolume のバックアップにはクラウドプロバイダの API を利用
※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
■オートヒーリング機能
Podを自動的に復旧させる機能をオートヒーリング(Auto Healing)機能といいます。
k8sメリット/デメリット
◽️k8sのメリット
①ローリングアップデートによる無停止運用が可能 ->ただし、podがレプリケートしていること前提。
②容易なスケーリング
③リソースの修正 ->ローリングアプデート前提になりますが無停止でできるのが利点
④オートヒーリング機能 ->pod(コンテナ)が停止ても復旧できる機能
⑤スケジューリング機能 ->各nodeのリソース状況などに応じて、podの割り当てを行える
①ローリングアップデートによる無停止運用が可能 ->ただし、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で区切る)
過去の障害事例を見ると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 スタックを削除
取り残されたスタックがあるかもしれないので、削除を行うこと。
以下、不要な物が表示されているようなら削除を実施する。

メモ:
クラスターをEKS経由で削除した場合、上記の確認をしてみても良いかも
AWS for fargate
ECS > クラスター > クラスター作成

ネットワークのみを選択


作成中………….。

Nfginxを作成して見る。

FARGATEを選択する。

①以下の設定値の入力を行う

②リソースの値も適当に(実験なので、少なめに!)

①コンテナ名:任意の名前で
②イメージを入力:DockerHubからのタグを入力
③ポートマッピング:ポート番号を入力。

完成していることが分かる。

クラスタ > 作成した “クラスタ名”を選択する。

以下、作成を行う。

以下、設定を行う。

サブネット :指定可能なAZを選択する。
パブリックIPの割り当て:ENABLE にする。

■以下、設定は”なし”
<画像1>

次にステップを選択。
<画像1>

<画像2>

作成中の様子。

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(無料枠にしてみた。最大2台までしか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が外部公開ができてない。
実際に、以下のアドレスで疎通が失敗する。

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

解決。

helm設定
以下の表示が出る場合、大抵は、tiller serverが稼働してないのが原因
1)helm install stable/mysql

2)Helm version を行うと、Clientが稼働しているがServerが稼働してないという状態。

3)以下のコマンドでtiller serverの起動を行うこと
tiller-listen=localhost:44134-storage=secret-logtostderr

■helmコマンド一覧
コマンド
|
説明
|
helm repo list
|
リポジトリ一覧を表示する
|
helm repo add
|
リポジトリを追加する
|
helm search
|
デプロイ可能なChartを表示する
|
helm install
|
アプリケーションをインストールする(k8sクラスタにデプロイする)
|
helm list
|
インストール済みのアプリケーションを表示する
|
helm delete
|
アプリケーションをアンデプロイする
|
helm reset
|
tillerをアンデプロイする
|
登録:
投稿 (Atom)
【AI×GitOps】Docker Composeから始めるRaspberry Pi 5 Kubernetesクラスタへの自動デプロイ設計
現在構築を進めている動画管理システム開発において、いきなりKubernetes(K8s)に展開するのではなく、 Docker Composeを中間地点に挟んで段階的にK8s+Argo CD(GitOps)へ移行するアーキテクチャ設計 をまとめました。 Bionic(AIアシスタン...
-
apk add openrc --no-cache [ 以下のように使えることが把握できる ] alpinelinuxのサービスの再起動コマンド: rc-service nginx restart
-
以下のログに表示されている、" network unreachable resolving"は IPv6に関するメッセージではあるが、基本的にIPv4しか使用していないため このメッセージを消したい時の対策を以下に示す。 上記は、IPv4での名前解決...




