Metallb

参照先：
https://metallb.universe.tf/installation/

導入方法は、ArgoCD経由でHelmを使った方法にする。(以下、導入イメージ)

 

以前に記載したconfigをデプロイすると、IPの割り当てが出来ていなく
調べていたら、L2Advertisementの記載が別途必要になったようだ。。

apiのバージョン確認：k8s

 以下のコマンドで、現在のapiのバージョンが確認できる。

コマンド： kubectl api-resources

istio1.18(helmでの導入方法)

参照先：
https://istio.io/latest/docs/setup/install/helm/

istioをhelm形式で導入を行う
(istioコマンドでの導入方法だと、管理コストが上がるためhelmでの導入に変更)

手順：
helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update

helm install https://istio-release.storage.googleapis.com/charts istio --namespace istio --create-namespace
kubectl create namespace istio-system

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

helm ls -n istio-system

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

helm ls -n istio-system
helm status istiod -n istio-system

kubectl get deployments -n istio-system --output wide

k8s install (Raspberry pi 2022版)

ソフトウェア構成

• Raspberry Pi OS 11
• Kubernetes 1.25
• コントロールプレーンノード 1台、ワーカーノード 2台構成
• コンテナランタイムにはCRI-Oを使う

k8sの推進環境にruntimeがcri-oなどの変更になっているので

改めての導入方法を以下に記載する。

◆◇手順◆◇

以下の手順で、行う。

ホスト名およびIPアドレスについては、環境に合わせること！

# IPの設定

raspi-config nonint do_hostname raspi-master

sudo raspi-config nonint do_change_timezone Asia/Tokyo

sudo raspi-config  --expand-rootfs

sudo apt-get update && sudo apt-get dist-upgrade -y

sudo apt-get update && sudo apt-get upgrade -y

cat <<EOF >> /etc/dhcpcd.conf

static ip_address=192.168.13.xx/24

static routers=192.168.13.99

static domain_name_servers=192.168.10.1 8.8.8.8

EOF

# cgroup settings

sudo sed -i 's/$/ cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory/g' /boot/cmdline.txt

# swap setting

sudo swapoff --all

sudo systemctl stop dphys-swapfile

sudo systemctl disable dphys-swapfile

systemctl status dphys-swapfile

# ip tables settings

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf

br_netfilter

EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf

net.bridge.bridge-nf-call-ip6tables = 1

net.bridge.bridge-nf-call-iptables = 1

EOF

sudo apt-get install -y iptables arptables ebtables

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy

sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

sudo update-alternatives --set arptables /usr/sbin/arptables-legacy

sudo update-alternatives --set ebtables /usr/sbin/ebtables-legacy

sudo sysctl --system

# crio(runtime for Docker) setting

cat <<EOF | sudo tee /etc/modules-load.d/crio.conf

overlay

br_netfilter

EOF

sudo modprobe overlay

sudo modprobe br_netfilter

cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf

net.bridge.bridge-nf-call-iptables  = 1

net.ipv4.ip_forward = 1

net.bridge.bridge-nf-call-ip6tables = 1

EOF

sudo sysctl --system

OS=Debian_10

CRIO_VERSION=1.23

echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /"|sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list

echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$CRIO_VERSION/$OS/ /"|sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$CRIO_VERSION.list

curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$CRIO_VERSION/$OS/Release.key | sudo apt-key add -

curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add -

sudo apt update

sudo apt update

sudo apt upgrade -y

sudo apt install cri-o cri-o-runc -y

sudo systemctl daemon-reload

sudo systemctl enable crio

sudo systemctl start crio

# k8s install

sudo apt-get update && sudo apt-get install -y apt-transport-https curl

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

EOF

sudo apt update

sudo apt install -y kubelet kubeadm kubectl

sudo apt-mark hold kubelet kubeadm kubectl

cat <<EOF | sudo tee /etc/default/kubelet

KUBELET_EXTRA_ARGS=--container-runtime-endpoint='unix:///var/run/crio/crio.sock'

EOF

systemctl daemon-reload

systemctl restart kubelet

sudo reboot

◇calico(CNIの追加)

curl https://docs.projectcalico.org/manifests/calico.yaml -O

kubectl apply -f calico.yaml

◇Prometheus&Grafana

kubectl create ns monitoring

git clone https://github.com/prometheus-operator/kube-prometheus.git

cd kube-prometheus/

kubectl create -f manifests/setup

kubectl create -f manifests/

◇Argo CD

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

k8s負荷試験(作成中)

 <攻撃ツール>
1: ボトルネックになりえないこと

以下、負荷ツールを使って調査を行う。

①Jmeter

②locust

③Gremlin

<Podレベル>
2: 想定レイテンシでレスポンスを返せること

HPAを無効(Pod単体)にして、resourceのrequestとlimitの値を増やしてどこまで要求を満たすか確認

   ->アプリケーションに問題があってレイテンシが超過する場合はアプリケーションのチューニングが必要

3: 想定スループットを満たせること

HPAを無効にしてPodを手動でスケールアウトしていき、どこまでスループットを伸ばせるかを確認。

①各PodのCPU使用率
特定のPodだけCPU使用率が偏ってる場合はルーティングポリシーの再確認

②各Podのレイテンシ
一つ前の「想定レイテンシでレスポンスを返せること」に戻って確認
攻撃側のCPU使用率
攻撃ツールのスケールアップ、スケールアウト

4: 突然のスパイクに対応できること
5: ノードレベルの障害、ダウンを想定した設定になっていること
6: 配置が想定どおりに行われていること
7: 新バージョンリリースがダウンタイム無しで可能なこと
8: 長時間運転で問題が起こり得ないこと

<クラスタレベル>
9: Podの集約度が適切であること
10: 配置するPodの特性に合わせたノードになっていること
11: 突然のスパイクに対応できること
12: クラスタの自動アップグレードの設定が適切であること
13: Preemptibleノードの運用が可能であるか

calicoインストール（再）

参照：
https://projectcalico.docs.tigera.io/getting-started/kubernetes/helm

worker nodeを新規で入れ替えたら、Master NodeからWorker Nodeに対して

Podの配布（スケジューリング）ができていないことが判明

以下の内容をみるとCNI(Calico)の問題っぽい。

<Helmでの導入>

1)レポジトリを追加する

helm repo add projectcalico https://docs.projectcalico.org/charts

2)インストールを実施

helm install calico projectcalico/tigera-operator --version v3.21.4

3)進捗状況を確認

watch kubectl get pods -n calico-system

argoCD(github:自作マニュフェスト)

 以下、自作のnginxのマニュフェストをargoCD経由でデプロイしてみる。

githubのパスを” ./ “にする。

以下、デプロイができていることが把握できる。

Network Policy

参照先：
https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/

<稼働条件>

Calico(ネットワーク用のPod)を利用していること。

Network policyについて：

Pod間のネットワークの許可及び拒否などを行えるリソース

 - Ingress         ：入力に対してのルールを決める

 - Egress          ：出力に対してのルールを決める

 - podSelector ：podSelector(特定のPodを許可

                               —>{}は、全て適応という意味 

検証：

1)Ingress/Egressの全てのトラフィックを拒否するマニュフェストを作成して検証を行う。

2)適応後、他のPodに対してcurlコマンドを実施してみたがTimeoutになる

3)上記のnetworkPolicyを削除後に、改めてcurlを実施

k8/Dockerまとめ

以下のリンク先に４つの項目を作成

シート1：k8sの各種機能
シート2：k8sのコマンド
シート3：Dockerコマンド
シート4：DockerFileの記載方法

https://docs.google.com/spreadsheets/d/e/2PACX-1vS3uLNbk4vPsRM6GhMCEI4RoB1aK0UOPWQZB3XeybA81NU4pfyIPfEWBhiVjGvv84dyqIu2H-o1HqX5/pubhtml

Node Portについて（補足）

参照：
https://kubernetes.io/ja/docs/tutorials/services/source-ip/

NodePort：

クライアントからのトラフィックをnode portサービスで受信したら

対象のClusterIPにNAT変換される仕組み。

各種Workloadsリソースについて

以下の図は、各種Workloadsの上位リソース、下位リソース関係を表す。

k8sアップグレード(for Raspberry pi)

参照：
https://v1-22.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

課題：

以下、k8sのバージョンが古い(2022/01現在)ので最新版にアップデートをしてみます。

アップグレード中での影響について：

バージョンアップ中は、稼働中のPodが停止するなどの悪影響は起きない。

マスターノード単体の場合は、更新が完了するまで、worker nodeへの出来ないことを考慮する必要がある。

手順：

コントロールプレーン x1、worker node x2の構成になので

以下の順に、アップグレードを行う。

1)コントロールプレーンのアップグレードを行う

①レポジトリの更新を行う。

apt update

②アップグレードのリストを表示する。

apt-cache madison kubeadm

③対象のバージョンにkubeadmのアップグレードを行う。

apt-mark unhold kubeadm && \

apt-get update && apt-get install -y kubeadm=1.23.1-00 && \

apt-mark hold kubeadm

④kubeadmバージョンの確認を行う

kubeadm version

⑤アップグレード方法を確認する

kubeadm upgrade plan

（以下のアップグレードの適応方法が記載されている。）

⑥アップグレードの実施を行う

kubeadm upgrade apply v1.23.1

⑦kubeadmのアップグレードが成功すると、以下の表示が出て完了となる。

⑧kubelet&kubectlのアップグレードを行う。

(公式には記載がないがworker Nodeとバージョンを揃えたいので実施)

apt-mark unhold kubelet kubectl && \

apt-get update && apt-get install -y kubelet=1.23.1-00 kubectl=1.23.1-00 && \

apt-mark hold kubelet kubectl

⑨kubeletを再起動する

sudo systemctl daemon-reload

sudo systemctl restart kubelet

2)Worker Node(1台目)のアップグレードを行う

①対象のworker nodeにスケジュールを禁止にする。

注意：コントロールプレーンで実施

kubectl drain rasp-node1.local --ignore-daemonsets

②rasp-node1.localにログインして、アップグレードを行う。

apt-mark unhold kubelet kubectl && \

apt-get update && apt-get install -y kubelet=1.23.1-00 kubectl=1.23.1-00 && \

apt-mark hold kubelet kubectl

③kubeletを再起動する

sudo systemctl daemon-reload

sudo systemctl restart kubelet

④対象のworker Nodeをオンラインの状態にする

注意：コントロールプレーンで実施

kubectl uncordon rasp-node1.local 

3)Worker Node(2台目)のアップグレードを行う

①上記のworker nodeと同様の作業を行う。

4)バージョンの確認を行う

対象のバージョン(1.23.1)になっていることが把握dけいる。

(以下のバージョンは、kubeletのバージョンを表す)

Pod Security Policies(廃止) ->PodSecurity

 参照：

https://kubernetes.io/docs/concepts/security/pod-security-admission/

https://kubernetes.io/blog/2021/12/09/pod-security-admission-beta/

https://qiita.com/uesyn/items/cf47e12fba5e5c5ea25f

機能：

クラスタ(NameSpace)の範囲でセキュリティを適応する機能として

Pod Security Policiesがあるがver 1.25で廃止されてPodSecurityに変更される

ポイント：

以下のようにNameSpaceにラベルにルールを記載することでセキュリティが追加される。

（NameSpaceのデフォの作成時点では、関連したラベルがないのでセキュティの設定はされてない）

ポリシーは、ラベルを介して名前空間に適用されます。これらのラベルは次のとおりです。

例）

pod-security.kubernetes.io/<MODE(enforce | audit | worn)>: <LEVEL(privileged | baseline | restricted)> 

pod-security.kubernetes.io/<MODE(enforce | audit | worn)>-version: <VERSION>（オプション、デフォルトは最新）

<MODE>

enforce：ポリシー違反により、Podは拒否されます。

audit     ：ポリシー違反は、監査ログに記録されたイベントへの監査注釈の追加をトリガーしますが、それ以外の場合は許可されます。

warn     ：ポリシー違反はユーザー向けの警告をトリガーしますが、それ以外の場合は許可されます。

<LEVEL>

privileged   : オープンで無制限

baseline     : 制限を最小限に抑えながら、既知の特権昇格をカバーします

restricted   : 高度に制限され、既知および未知の特権エスカレーションに対して強化されます。

検証：

公式内容を参考に、コマンドベースでの検証を行ってみる。

1)検証用のnamespaceを作成する。

kubectl create namespace pod-security-test

2)ラベリングを行う。

（以下のラベルは、Podの作成を拒否することを表している。）

kubectl label namespace pod-security-test pod-security.kubernetes.io/enforce=restricted

3)対象のNameSpaceにラベルが付与されたとを確認

4)試しに、指定したNameSpaceにデプロイを行うと。

kubectl -n  pod-security-test run test --dry-run=server --image=busybox --privileged

5)以下、メッセージが出て作成が失敗に終わります。

6)ラベルの上書きを行ってみる。

kubectl label --overwrite ns pod-security-test \

  pod-security.kubernetes.io/enforce=privileged \

  pod-security.kubernetes.io/warn=baseline \

  pod-security.kubernetes.io/audit=baseline

7)再度、デプロイを実施する。

以下、デプロイが出来てることが把握できる。

以下のようにマニュフェストの作成でも実施可能である。

カーネルのパラメータ変更(sysctls利用パターン)

sysctls：
カーネルのパラメータの変更が可能になる。

以下、例になる。

①safe（変更しても危険度が低いカーネルの値）

  ->変更可能

②Unsafe（変更しても危険度が高いカーネルの値）

  ->公式ページを見て変更方法を探ってみたがオンプレ(Raspberry pi)での実施は出来ていない。