sysctlコマンド

参照：
https://kubernetes.io/docs/tasks/administer-cluster/sysctl-cluster/

sysctlコマンド：

カーネルを設定時に利用するコマンド

1)master/worker nodeにログインする。

2)以下のsysctlコマンドで取得可能なリスト(カーネルのパラメータ)を取得する。

sudo sysctl -a

3)以下のファイルの修正を行う。

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

対象のフォルダーからの文字検索

対象のフォルダーから検索キーワードでヒットする方法を記載します。

手順：

1)以下の方法で検索が可能になる。

find [パスを指定] -type f -print | xargs grep ‘[キーワードを記載]’

例：

find /var/log -type f -print | xargs grep 'Out of memory: Killed process'

dstatコマンド(oom予備軍の確認)

worker node側で過剰なリソース消費が発生すると
oom kilerが発生して、過剰摂取しているリソースを削除されるので確認を行ってみる。

検証：

1)oom-killerをログで確認する

ubuntuであれば、kern.log、sysylogなどで確認ができる。

2)dstatコマンドで過剰接収のリソース確認してみる。

以下の場合だとlokiが対象になっている。

k8sの調査方法(メモ)

k8sのコマンド：
公式サイトの以下のページにチート表がある。
(コマンド操作で知りたい場合は、以下を公式ページを参考にする。)
https://kubernetes.io/ja/docs/reference/kubectl/cheatsheet/

[ポートフォワーディング]

kubectl port-forward service/サービス名 ポート番号:ポート番号(固定)

[Nodeport割り当て]

1)Cluster IP ->Nodeportに変更

kubectl patch service サービス名 -p '{"spec": {"type": "NodePort"}}'

例：

kubectl patch service mysql-01 -p '{"spec": {"type": "NodePort"}}'

2)ポートを変更したい場合

kubectl patch svc サービス名 --type='json' -p='[{"op": "replace", "path": "/spec/ports/0/nodePort", "value": 30006}]'

(例)

kubectl patch svc mysql-01 --type='json' -p='[{"op": "replace", "path": "/spec/ports/0/nodePort", "value": 30006}]'

[Namaspaceでのデプロイ実施]

kubectl apply -f pod.yml --namespace=“namespace名”

[疎通確認編]

1)ポート番号の確認

sudo lsof -i -P | grep ポート番号

2)疎通確認

curl -v 0.0.0.0:32270 --output /dev/null

結果：

接続に問題ない様子

[ポート番号の解放状況確認]

netstat -anp

[root権限で動かしたい場合]

docker exec -it --privileged [コンテナ名] /bin/bash

[全POD表示コマンド]

kubectl get pods --all-namespaces -o=custom-columns=NameSpace:.metadata.namespace,NAME:.metadata.name,CONTAINERS:.status.containerStatuses[*].name

[コントロールプレーンに登録済みのマニュフェスト(yaml)の確認]

(例)

kubectl get pod inter-pod-affinity-test-78cbc5f6cf-fwtzb -o yaml

[Helm チャート(yaml形式)出力：MySQLの場合]

helm inspect values stable/mysql > mysql.yaml

ghコマンド for Raspberry pi

 参照：
https://github.com/cli/cli/blob/trunk/docs/install_linux.md#debian-ubuntu-linux-apt

手順：

curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo gpg --dearmor -o /usr/share/keyrings/githubcli-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null

sudo apt update

sudo apt install gh

1)以下、実行する

gh auth login

2)GitHub.comを選択

3)HTTPSを選択

4)Yを選択

5)Login with a web browserを選択

6)enterを押す

7)ブラウザが開けなかったので、以下のリンク先を直接選択する

8)githubに推移したら、認証コードが表示されるので、以下の画面にペーストする

9)あとは、画面にしたがって行くことで認証完了。

atopコマンド

インストール手順：

apt install atop -y

topコマンドより視覚的に良いかも

 

フォルダーを階層毎に作成する方法

一括で、フォルダの階層を作成できる方法を記載する。

例：

mkdir -p  フォルダ1/フォルダ２/フォルダ3

運用メモ

クラウドの特性を考えると、これまでのシステムアーキテクティングと異なった視点が必要となる。

それをクラウドアーキテクティング原則として整理している

日時作業：

1)cloudwatch を見て、リソースの状況を把握する

①平均値を常に把握する
②把握している、平均値の上限越えがあった場合、インスタンスサイズの検討する(スケールアップ/スケースアウト)

障害対応：

1)ローカルからどのホストのどのアプリケーション（ポート番号）への接続が行われているか確認を行う

netstat -alnA inet

netstat -n | grep 80

アクティブセッション数を確認：

watch -d -n 1 "netstat -alpn | grep -E ':(80|443) ' | awk {'print $5'} | sed -e 's/\:[^.]*$//' | sort | uniq -c"

Cloudwatch監視項目：

[EC2]

①CPU使用率

②CPUクレジット消費数・残数（t2系のインスタンスのバーストできるクレジット）

③ディスクのread・writeのI/O数、バイト数

④ネットワークのイン・アウトの使用バイト数

⑤システムチェック（AWSホスト側のネットワーク、ハード等の状態と、EC2インスタンスステータスチェック状態）

⑥ログ監視

CloudWatchの詳細：

メトリクス	内容	単位
CPUUtilization	CPU使用率	パーセント
DiskReadOps	ディスク読み取り数	数
DiskWriteOps	ディスク書き込み数	数
DiskReadBytes	ディスク読み取り量	Bytes
DiskWriteBytes	ディスク書き込み量	Bytes
NetworkIn	ネットワーク受信量	Bytes
NetworkOut	ネットワーク送信量	Bytes
StatusCheckFailed	インスタンスステータスチェックかシステムステータスチェックのどちらかが失敗した場合1になる。	0(成功) 1(失敗)
StatusCheckFailed_Instance	インスタンスステータスチェックは、個々のEC2インスタンスのソフトウェアやネットワークの状態確認。失敗した場合1になる。	0(成功) 1(失敗)
StatusCheckFailed_System	システムステータスチェックは、EC2インスタンスに必要なAWSシステムの状態確認。失敗した場合1になる。	0(成功) 1(失敗)

[ELB]

①バックエンドの正常・異常なホスト数（ヘルスチェック成功？失敗？）

②バックエンドへのリクエスト数

③バックエンドへのリクエストのレイテンシ

④ELBが返した、4XX、5XXのエラーコード数

⑤バックエンドが返した、2XX、3XX、4XX、5XX

⑥バックエンドとの接続失敗した数

⑦バックエンドへの保留中のリクエスト、キューが一杯のため拒否したリクエスト

[RDS]

①リードレプリカ利用時の、マスター側で専有しているバイナリログの容量（バイト）

②CPU使用率

③CPUクレジット消費数・残数（t2系のインスタンスのバーストできるクレジット）

④データベースへの接続数

⑤read・writeのキューの数（負荷などで、書き込み・読み込み待ちになったキュー数）

⑥利用可能なメモリ容量（EC2では取得できないがRDSでは取得可能）

⑦利用可能なストレージ容量（EC2では取得できないがRDSでは取得可能）

⑧MySQL、マルチAZ利用時のレプリケーションラグの秒数

⑨RDSのswap総容量

⑩秒間あたりの書き込み操作数、読み込み操作数

⑪１回の書き込みにかかる平均秒数、１回の読み込みにかかる平均秒数

⑫１回の書き込みにかかる平均バイト数、１回の読み込みにかかる平均バイト数

⑬受信時のネットワークトラフィック（バイト/秒）、送信時のネットワークトラフィック（バイト/秒）

CloudWatchの詳細：

メトリクス	内容	単位
BinLogDiskUsage	マスターのバイナリログのサイズ	Bytes
CPUUtilization	CPU使用率	パーセント
DatabaseConnections	DBコネクション数	数
DiskQueueDepth	ディスクI/Oキュー数	数
FreeableMemory	空きメモリ量	Bytes
FreeStorageSpace	空きディスクスペース量	Bytes
ReplicaLag	リードレプリカのタイムラグ	秒
SwapUsage	スワップ使用量	Bytes
ReadIOPS	読み込みIOPS	数/秒
WriteIOPS	書き込みIOPS	数/秒
ReadLatency	読み込みレイテンシ	秒
WriteLatency	書き込みレイテンシ	秒
ReadThroughput	読み込みスループット	bytes/秒
WriteThroughput	書き込みスループット	bytes/秒

参照先：

https://avinton.com/blog/2017/10/linux-network-troubleshooting/

ログの確認：

ネットワーク障害が発生した際に、ログに何らかの障害情報が記載されている可能性が高いと考えられます。

具体的には下記のログを確認することが有効と考えられます。

①一般的なログ。サービス起動時の出力など

1	var/log/messages

②認証、セキュリティ関連のログ 

1	/var/log/secure

③メール関連のログ 

1	/var/log/maillog

④カーネルが出力したメッセージのログ。ハードの故障の際にはこちら。 

1	/var/log/dmesg

⑤WEBサーバに関連のログ 

1	/var/log/httpd

備考：

その他Linux上のログは var/log/ 配下に出力されます。

各種 log を確認し、failなどのエラーを表す記載があるようでしたら、

付随するメッセージに従い、原因を除去します。

接続状況確認：

①netstat -ap | grep "LISTEN "

②netstat -ltupn

③netstat又は、ssコマンドで、現在開いているポートを一覧表示することができる。

オプション	説明
-l	Listenしているポートのみ表示
-t	TCPを表示
-u	UDPを表示
-n	ポートやホストを数値で表示
-p	ポートを開いているプロセスを表示（sudo）
-4	IPv4のみ
-6	IPv6のみ

80/443ポートの確認：

来れば数秒間隔で更新される（接続数を確認できる）

watch -d -n 1 "netstat -an |grep :80 |wc -l"

sudo watch -d -n 1 "netstat -plan|egrep ':(80|443) '|awk {'print $5'}|sed -e 's/\:[^.]*$//'|sort|uniq -c|sort -nk 1"

ps auxf | grep httpd