M4 MaxのRoo Codeから自宅ラズパイk8sクラスターをMCPで「完落ち」させるまで②

 k8s(raspberry pi)のpodのログをチャットで観れるか実験してみました。

この後、エラーがログに出てないかも聞いてみました

Pod Security Admission

[用途]
ルール対象外のマニフェストをデプロイさせないための
防止策で利用するイメージになる

[検証]
以下のコマンドを投入する
kubectl label ns default pod-security.kubernetes.io/warn=baseline
[各種コマンドの意味]
1. kubectl label ns default

• 意味: default という名前空間（Namespace）に「付箋（ラベル）」を貼るという指示です。

• ポイント: 新しい設定ファイルを作るのではなく、既存の「箱（Namespace）」の属性を書き換えるだけで設定が完了するのが、最新の PSA (Pod Security Admission) の特徴です。

2. pod-security.kubernetes.io/

• 意味: これは「Podセキュリティ機能に対する設定ですよ」という接頭辞（プレフィックス）です。

• 役割: k8sには多くのラベルがありますが、この名前で始まるラベルを貼ることで、k8sのエンジンが自動的に「セキュリティのチェックを開始しなきゃ！」と判断します。

3. warn (コントロール・モード)
PSAには3つのモードがありますが、今回はその中の 警告モード を選びました。

• enforce (強制): 基準に合わないPodは起動させない。

• audit (監査): ログに記録するだけ。

• warn (警告): 今回の結果の通り、Podは起動させるが、実行者に警告を出す。

4. baseline (ポリシー・レベル)
セキュリティの「厳しさ」のレベルです。

• Privileged: 無制限。何でも許容する。

• Baseline: 今回の設定。 最小限の「危ない設定」を禁止する標準レベル。

• Restricted: 非常に厳しい。Podを動かすために、細かいセキュリティ設定が必須。

実施結果：

問題があるマニフェストをデプロイしてみる

apiVersion: v1

kind: Pod

metadata:

name: security-test-pod

spec:

hostNetwork: true # ← これが基準違反のポイント

containers:

- name: nginx

image: nginx:alpine

以下の警告表示が出ることが確認できる

k8s node version UP(1.34.1 > 1.34.2)

[マスターノードでの準備と安全確保]

1)etcdctl クライアントのインストール: (未インストールの場合は必要)

apt update

apt install etcd-client

2)etcd バックアップの取得と退避 (最重要):

ETCDCTL_API=3 etcdctl --endpoints=127.0.0.1:2379 \

    --cacert=/etc/kubernetes/pki/etcd/ca.crt \

    --cert=/etc/kubernetes/pki/apiserver-etcd-client.crt \

    --key=/etc/kubernetes/pki/apiserver-etcd-client.key \

    snapshot save /tmp/etcd_backup_$(date +%Y%m%d_%H%M%S).db

3)ファイルをクラスター外の安全な場所（ローカルPCなど）にコピーします。

環境によって、異なるので割愛します。(おそらくSCPなど待避されるのではと思いますが)

4)Pod Disruption Budget (PDB) の一時削除:

ドレインをブロックするIstioなどのPDBを削除します。

kubectl delete pdb istio-ingressgateway -n istio-system

kubectl delete pdb istiod -n istio-system

[コントロールプレーンのアップグレード]

1)kubeadm バイナリの更新:

apt-mark unhold kubeadm

apt install -y kubeadm=1.34.2-1.1

apt-mark hold kubeadm

2)コアコンポーネントの適用:

kubeadm upgrade apply v1.34.2

3)kubelet と kubectl パッケージの更新:

apt-mark unhold kubelet kubectl

apt install -y kubelet=1.34.2-1.1 kubectl=1.34.2-1.1

4)kubelet の再起動:

systemctl daemon-reload

systemctl restart kubelet

5)パッケージのホールド再設定:

apt-mark hold kubelet kubectl

[ワーカーノードのアップグレード（ノードごとに繰り返し）]

rasp-node1 と rasp-node2 で、以下の手順を1台ずつ実行します。

1)ドレイン（マスターノードで実行）:

kubectl drain <ノード名> --ignore-daemonsets --delete-emptydir-data --force

2)ノードの設定更新（ワーカーノードで実行）

対象のワーカーノードにログインし、kubeletの設定を更新します。

kubeadm upgrade node

3)kubelet サービス更新（ワーカーノードで実行）

apt-mark unhold kubelet

apt install -y kubelet=1.34.2-1.1

systemctl daemon-reload

systemctl restart kubelet

apt-mark hold kubelet

4)アンコルドン（マスターノードで実行

kubectl uncordon <ノード名>

[ 最終確認と PDB の再適用]

実行場所: マスターノード (rasp-master)

1. 全ノードバージョン確認: すべてのノードが v1.34.2 で Ready であることを確認します
   kubectl get nodes
   
   
   

istio ingress gateway(envoyアクセスログを出力してみる)

istio ingress gateway経由で、該当のPod(nginx)にアクセスが出来ているのか

把握したいので、istio ingress gateway(Envoy)に対して、出力されるログの設定を行ってみる

1)EnvoyFilterのマニフェストを作成して、デプロイを実施する

apiVersion: networking.istio.io/v1alpha3

kind: EnvoyFilter

metadata:

name: ingressgateway-access-log

namespace: istio-system

spec:

configPatches:

- applyTo: NETWORK_FILTER

match:

listener:

filterChain:

filter:

name: envoy.filters.network.http_connection_manager

patch:

operation: MERGE

value:

typed_config:

"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager

access_log:

- name: envoy.access_loggers.stdout

typed_config:

"@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog

log_format:

json_format:

START_TIME: "%START_TIME%"

METHOD: "%REQ(:METHOD)%"

PATH: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"

PROTOCOL: "%PROTOCOL%"

RESPONSE_CODE: "%RESPONSE_CODE%"

BYTES_RECEIVED: "%BYTES_RECEIVED%"

BYTES_SENT: "%BYTES_SENT%"

USER_AGENT: "%REQ(USER-AGENT)%"

UPSTREAM_HOST: "%UPSTREAM_HOST%"

UPSTREAM_CLUSTER: "%UPSTREAM_CLUSTER%"

DOWNSTREAM_LOCAL_ADDRESS: "%DOWNSTREAM_LOCAL_ADDRESS%"

DOWNSTREAM_REMOTE_ADDRESS: "%DOWNSTREAM_REMOTE_ADDRESS%"

workloadSelector:

labels:

app: istio-ingressgateway

2)istio ingress gateway(Envoy)にログインして、curlコマンドを実施
例：10.106.197.8は、istio ingress gatewayのLBのアドレスになる

3)istio ingress gateway(Envoy)のログを確認してみる
kubectl -n istio-system logs -l app=istio-ingressgateway -c istio-proxy

isito ingress gateway(Helm編)

参照先：

https://istio.io/latest/docs/setup/install/helm/

CRDのインストールが失敗した場合用：

curl -L https://istio.io/downloadIstio | sh -

cd istio-1.25.0

export PATH=$PWD/bin:$PATH

istioctl install --set profile=default -y

CRD＆istio base:

helm install istio-base istio/base -n istio-system --set defaultRevision=default --create-namespace

istiod:
helm install istiod istio/istiod -n istio-system --wait

ingressgateway:(内部用):

helm install istio-ingressgateway istio/gateway -n istio-system --wait

egressgateway:(外部用):

helm install istio-egressgateway istio/gateway -n istio-system --set gateways.istio-egressgateway.enabled=true

istio ingress gateway install(再)

参照先：
https://istio.io/latest/docs/setup/getting-started/#download 

以下、導入手順：

curl -L https://istio.io/downloadIstio | sh -

cd istio-1.25.0

export PATH=$PWD/bin:$PATH

istioctl install -set profile=default

ingress gatewayが入っていることを確認：

selecortのapp=istio-ingressgatewayまたは

istio=ingressgatewayを以下の

spec.selector:に記載すること

（今回は、app=istio-ingressgatewayにする）

ingress gatewayのマニフェストを作成：

apiVersion: networking.istio.io/v1beta1

kind: Gateway

metadata:

name: nginx-gateway

namespace: default

spec:

selector:

app: istio-ingressgateway # Istio Ingress Gateway のデフォルトラベル

servers:

- port:

number: 80

name: http

protocol: HTTP

hosts:

- "*"

---

apiVersion: networking.istio.io/v1beta1

kind: VirtualService

metadata:

name: nginx-vs

namespace: default

spec:

hosts:

- "*"

gateways:

- nginx-gateway

http:

- match:

- uri:

prefix: / # nginx.default.svc.cluster.local<----完全修飾サービス名にするアクセスできず。

route:

- destination:

host: nginx

port:

number: 80

---

# nginx Deployment と Service の作成

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx

namespace: default

spec:

replicas: 1

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:latest

ports:

- containerPort: 80

resources:

limits:

memory: "512Mi" # コンテナが使用できる最大メモリ

cpu: "500m" # コンテナが使用できる最大CPU

requests:

memory: "256Mi" # コンテナに最低限必要なメモリ

cpu: "250m" # コンテナに最低限必要なCPU

---

apiVersion: v1

kind: Service

metadata:

name: nginx

namespace: default

spec:

ports:

- port: 80

targetPort: 80

selector:

app: nginx

デバッグログを表示させるのは？（k8s）

以下のオプションでデバッグログが見れる 

kubectl -v=9 get pod -n redis

k8s便利アイテム

[コマンドでログをぱっと見たい時に便利] 

インストール方法：

brew install stern

使い方：

stern　[pod名]

[namespaceを簡単に切り替えられるコマンド] 
インストール方法：
brew install kubens
使い方：

kubens　[namespaceを記載]


[contextを簡単に切り替えられるコマンド]
インストール方法：

brew install kubectx
使い方：
kubectxと入力して、該当のcontextを選択

kubectlと入力するのが省略したい時に便利

alias k='kubectl'

ArgoCD(multi build)

nginxを2つ作成してリポジトリにpushします

 

GitHubでArgoCD用のトークンを発行します。

　　　->今回は、classicで作成しました。

ArgoCDにログインします。

Settings > Repositoriesを選択

Choose your connection method:　VIA HTTPSを選択

Type: gitを選択

Name: 名前を記載（なんでも良いです）

Project: default(適当に選択出来た物を選んだ)

Repository URL: Githubのリポジトリを記載

UserName:   githubのユーザ名

Password:    上記、githubで発行したトークンを記載

上記、記載ができたらCONNECTを押す

ApplicationからNEW APPを押す

Application Name : 分かりやすい名前に

Proiect Namel：選択出来た物を選びました。

SYNC POLICY：　Automatic

　　　      ->PRUNE RESORCES

Repository URL: 先ほどのgithubのリポジトリを選択

Revision：HEAD

Path: .  

Cluster URL: 選択出来た物を選ぶ

Namespace:  デプロイ先のNamespaceを記載

DIRECTORY RECURSE: チェックを入れる（入れないと、デプロイ出来ませんでした）

上記、記載ができたらCREATEを押す

実際にデプロイすると、以下のようになります。

ArgoCD側の様子：