小池友岳 tomotake-koike

Setup OKD node with NIC bonding and a fixed IP address assigned without DHCP

Prerequisite

Please refer to the following until node's live-os booting:
https://itnext.io/okd-4-5-single-node-cluster-on-windows-10-using-hyper-v-3ffb7b369245

I haven't tried, though, and I guess this method is also enable to setup bootstrap server.

Setup OKD Node

EKSでNode名からAZを行頭にくっつけるワンライナー・フィルター関数

以下をCopy&Pasteしてもらって、

az_filt () { local region_prefix="ap-northeast-" ; local region_suffix="1.compute.internal" ; local region="${region_prefix}${region_suffix}" ; local zone ; declare -A zone ; IFS=$'\n' ; for l in $(kubectl get node --show-labels | sed -E "s/^(ip(-[0-9]{1,3}){4}\.${region}).*topology.kubernetes.io\/zone=${region_prefix}(.{2})/\1 \3/" ) ; do n="$(echo $l | cut -d\  -f 1)" zone[$n]=$(echo $l | cut -d\  -f 2) ; done ; for l in $(cat - ) ; do node=$(echo $l | sed -E "s/^.*(ip(-[0-9]{1,3}){4}\.${region}).*$/\1/" ) ; [ -n "${zone["$node"]}" ] &&  echo -n ${zone["$node"]} " " || echo -n "    "  ; echo $l ; done ; }

こんな感じにパイプでつないでもらえれば、

kubectl get node | az_filt
kubectl get po -o wide | az_filt

EKSでAZに配置されたNode間で疎通確認を行う

仕組み

EKS NodeGroupの構成がわからなくてもnodeリソースからAZのラベルを抽出し、そのラベルでaffinityしたpod間で疎通確認を行う。
疎通はClusterIPとHead Lessの2つのルートを確認する。
2AZ前提で書いている。（ちょっと直せばMulti-AZも対応可能でしょう。）

準備

AZ構成をnodeから抽出する。

awscliからAWS Configをたたいてリソースタイプでリソース情報を収集する

Cloud9 IDEだと`jq`が無いのでセットアップ

（pythonは入っているのでスクリプトやってもいいのだけれど…。）

curl -o jq https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64
chmod 755 jq
jq_path=./jq

AWS Configで引っこ抜く

Multusのフィジビリティスタディ

Multusは2つ以上のCNIのNetwork InterfaceをなんとかPODへアタッチする仕組みで、肝心なところは基本的に連携するCNIに依存し、IP Address Management(IPAM)もCNIに頼る思想です。
一方で、一般的にCNIが提供されていないNodeの物理NICにつないでいくために以下のPluginが用意されており、別途CNIを用意しなくてもMultus CRDをインストールする手順を実行すると利用可能となります。このためか、一般的なMultusに関するBlog等を見るとこのPluginを見て「Multus＝2つ目のNICを使う仕組み」と強調されてる気がしますが、異なる特徴の複数CNI（SR-IOV CNIなど）を取り入れる仕組みとしての利用として考えたほうが良いかもしれません。ただ、取り込むCNI（特にIPAM）がIPAM含め対応している必要ががありそうです。（calicoはいまのところうまくいってません。）それと、K8s Serviceとの連携もいまのところ難しいです。

bridge: Creates a bridge, adds the host and the container to it.
ipvlan: Adds an ipvlan interface in the container.
loopback: Set the state of loopback interface to up.
macvlan: Creates a new MAC address, forwards all traffic to that to the container.
ptp: Creates a veth pair.

NetworkPolicy操作による挙動の違い

NetworkPolicyで疎通を止める検証をしていたところ、遮蔽した場合にエラーレスポンスのTATに差分があった。
本件、OCP ServiceMesh Training中に遭遇。

正常時についてはTATは短い

$ time curl -v http://$ERDEMO_USER-incident-service.apps.$SUBDOMAIN_BASE/incidents > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

Dload Upload Total Spent Left Speed

ETCDのVersionをDowngradeする

ETCDではdb保護のためUpgradeはサポート（世代に依る）しているが、Downgradeは対応していない。（少なくとも現状のv3.4.x以前のVersionでは）
このため一旦新しいVersionを試した後、旧Versionに戻したいと思っても、起動時に以下のClusterとのVersionの整合性とれない旨のエラーとなり起動しない。

cluster cannot be downgraded (current version: 3.4.5 is lower than determined cluster version: 3.5).

（この辺の処理でガードを掛けている。）

ETCDは新しいVersionのBinaryで起動すると自動的にClusterを新しいVersionへ移行する。（参考：Upgrade procedure）

Charmed K8s API ServerにLBを介さず接続するためのContextを追加する

CDKのJujuでK8sを構成するとkubeapi-load-balancer経由でAPI Serverに接続する構成となる。
Troubleshooting等でAPI Serverに直接Requestを投げる場合の手順を示す。

`kube-config`のバックアップ

$ cp .kube/config .kube/config-BK

現状復帰する場合はこのファイルを戻す。

	FROM nvidia/cuda:11.8.0-devel-ubuntu22.04

	USER root

	COPY ./requirements.txt /tmp
	WORKDIR /code

	RUN apt-get update && apt-get -y upgrade
	RUN apt install -y curl python3 python3-distutils
	RUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && python3 get-pip.py

	oc create configmap hc-script --from-file <( cat << EOF
	import urllib.request
	import sys

	request = urllib.request.Request("http://127.0.0.1:" + sys.argv[1] )
	try:
	with urllib.request.urlopen(request, timeout=3) as response:
	body = response.read()
	print(body)
	except Exception as e:

小池 友岳 tomotake-koike