winds.from.oz 技術メモ

Tag: K8n

k3sユーザー管理メモ

Posted:   |   Categories: k3s   |   Tags: gentoo, k3s, k8n

背景

ラズパイ上でk3sでk8nを動かしている。 ユーザー管理周りを整備していきたい。ただ煩雑なので現状はk3sのサーバにログインして実行している。 おいおい設定していきたいがメモ

認証方法

Kubernetesでは、ユーザーは事前に定義された認証メカニズムを通じて認証される。 認証システムは複数ある

静的トークンファイル

APIサーバーを起動する際に–token-auth-fileフラグを使用して指定されたファイル。 このファイルはトークン、ユーザー名、UID、および所属するグループを含む。

認証 | Kubernetes

証明書認証

クライアント証明書をAPIサーバーに提示して認証。 APIサーバーは–client-ca-fileフラグで指定されたCAによって署名された証明書を受け入れる。

OpenID Connect Tokens

認証 | Kubernetes

OIDCプロバイダーを通じてトークンによる認証をサポート。

アクセスできるリソースの制限

認証後、ユーザーがクラスター内のリソースに対して実行できる操作は、認可ポリシーによって制御されます。Kubernetes には以下の認可モードがあります：

  • Node
    • Node認可は、kubeletが所有するノードリソースにのみアクセスを許可する。
  • ABAC (Attribute-Based Access Control)
    • 属性に基づくアクセス制御。ポリシーはファイルで管理。
  • RBAC (Role-Based Access Control)
    • ロールに基づくアクセス制御。最も一般的で、役割を定義してユーザーやグループに割り当てる。
  • Webhook
    • 外部のREST APIサービスに認可判断を委託。

RBACの例

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "example-user"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
Read more...

k3sトラブルシューティング

Posted:   |   Categories: k3s   |   Tags: k3s, k8n, kubectl

自宅サーバk3sのトラブルシューティング

ある程度、ルーチンワークができるようになりたい。

ノードの一覧表示

kubectl get nodes

問題が起きていたら、↓ノードの状態を確認

kubectl describe node <node-name>

ポッドの一覧表示

kubectl get pods --all-namespaces
kubectl get events --all-namespaces

問題のあるポッドのログを確認

kubectl logs --since=12h <pod-name> -n <namespace>
  • --since=<期間> で狭められる
  • –since-time オプション: 特定の日時以降のログを取得するには、–since-time オプションを使用します。
  • –tail オプション: ログの最後の数行だけを表示するには、–tail オプションを使用
  • –timestamps: ログにタイムスタンプを付けて表示するには、–timestamps オプションを使用します。これにより、ログを後でフィルタリングする際に便利です。

例えば

kubectl logs --since=10h -n kube-system local-path-provisioner-6c86858495-s6v98

もしPod内に複数のコンテナが稼働している場合、特定のコンテナのログを確認します。

kubectl logs <pod-name> -c <container-name> -n <namespace>

以前のログを確認

Podが再起動している場合、以前のログも確認する必要があります。そのためには–previousオプションを使用します。

kubectl logs <pod-name> -n <namespace> --previous

特定のコンテナの以前のログを確認する場合は次のようになります。

kubectl logs <pod-name> -c <container-name> -n <namespace> --previous

Kubernetesリソースの状態を確認する

デプロイメント、レプリカセット、サービスなど、他のKubernetesリソースの状態を確認します。

Read more...

kubectl cheatsheet

Posted:   |   Categories: cheatsheet   |   Tags: cheatsheet, k8n, nerdctl

オプション効果
kubectl get nodesノードの一覧表示
kubectl get podsポッドの一覧表示
kubectl get pods --namespace=<namespace_name>特定のネームスペースのリソースを表示
kubectl get namespacesネームスペース一覧
kubectl get jobsジョブの確認
kubectl get jobsジョブの確認
kubectl get svc -o wideサービスの一覧表示(ロードバランサーも見れる)
kubectl get deployments -n <namespace>デプロイメントの一覧表示
kubectl rollout restart <deployment> -n defaultデプロイメントの再起動
kubectl logs <pod_name>ログの確認とデバッグ
kubectl logs jobs/example-jobログ
kubectl scale deployment <deployment> --replicas=0 -n <namespace>デプロイメントのスケール
kubectl exec -it <pod_name> -- <command>ポッド内でコマンドを実行するには
kubectl apply -f <filename.yaml>リソースの作成
kubectl delete -f <filename.yaml>リソースの削除
Read more...

kubectlのメモ

Posted:   |   Categories: k3s   |   Tags: k3s, k8n

~/.kube/configファイル

~/.kube/configファイルは、kubectlや他のクライアントツールがKubernetesクラスターと通信する際に使用する設定ファイル。 このファイルは、クラスターへのアクセス方法や認証情報、接続先のサーバー、使用するデフォルトのネームスペースなどを定義できる。

目的

~/.kube/configファイルの主な目的は、複数のクラスターやユーザー、認証メカニズムを設定し、それらを簡単に切り替えることができるようにすることになる。 これにより、開発者やシステム管理者は複数のクラスターを効率的に管理することが可能になる。

具体的な設定

クラスターの設定 clusters: クラスターのエンドポイント（APIサーバーのURL）や証明書情報（CA証明書）を設定する。

certificate-authority のファイルはk3sは /var/lib/rancher/k3s/server/tls/client-ca.crt に設置してある。 このcrtファイルをどこに設置するか悩むが簡単に調べると ~/.kube 配下にパーミッション700で置くケースが多い。

clusters:
- name: development
  cluster:
    certificate-authority: /path/to/cafile
    server: https://1.2.3.4:6443
Read more...

nerdctl cheatsheet

Posted:   |   Categories: cheatsheet   |   Tags: cheatsheet, k8n, nerdctl

–address /run/k3s/containerd/containerd.sock –namespace k8s.io

サンプル

sudo nerdctl –address /run/k3s/containerd/containerd.sock –namespace k8s.io build -t cli-tool-docker:latest /mnt/nfs/home/exampleuser/workspace/git/github.com/exampleuser/cli-tool-docker/

exec

nerdctl/docs/command-reference.md at main · containerd/nerdctl

–init でコンテナ内でinit経由で起動できる

nerdctl はコンテナ内で独自の init プロセスを自動的に起動します。 この init プロセスは PID 1 として動作し、ユーザーが指定したコマンドはその子プロセスとして実行されます。 これにより、コンテナ内のプロセス管理が改善され、特にゾンビプロセスの問題が効果的に解決されます。

参考

Read more...

Gentooでkubernetesのセットアップに失敗した

Posted:   |   Categories: Gentoo   |   Tags: Gentoo, k8n

事前準備

  • 固定 IP 化
  • swap を無効化
  • docker のインストールと自動起動

cgroup で CPU とメモリーが有効になっている必要がある

Gentoo で OpenRC だと /etc/rc.conf で設定する。

Gentoo側は Cgroup v1 と v2 の設定が選べる(hybrit になるようだ)。 Kubernetes での Cgroup v2 サポートは Docker で Docker Engine 20.10 から実装された模様

2021/10/10 時点の 私の Gentoo の Docker のバージョンを確認した所、20.10.7 だった。 kubernetes は 1.22 から Cgroup v2 をサポートした模様 参考 Kubernetes 1.22 における新機能は?

なぜ失敗しているのか?

kubeletやkubeadmのコンパイルは上手くいく。そういう観点でパッケージメンテナの作業は成功している。 kubeletも起動している。kubeadm –dry-runも正常に終了する。が実際にkubeadmで構築する段階で失敗している。 ここまま検証するより、一度、正常に動作しているkubenetesと比較した方が検証が進みやすそうだったので、構築できたk3s.ioを用いて検証を続けている。

kubernetes をインストールする

gentoo は標準でパッケージが用意されていたので、それでどこまで行けるか確認してみる。

パッケージインストール

app-admin/helm がマスクされていたのでマスクを外す。

cat << EOF | sudo tee -a /etc/portage/package.accept_keywords
app-admin/helm **
EOF
cat /etc/portage/package.accept_keywords

sudo emerge --ask  --quiet --verbose --verbose-conflicts  app-admin/helm sys-cluster/kubeadm sys-cluster/kubectl sys-cluster/kubelet \
  app-emulation/flannel net-firewall/conntrack-tools sys-apps/ethtool net-firewall/ebtables net-misc/socat

kubeadm init を –dry-run で実行、エラーが起きない事を確認する

sudo kubeadm init --dry-run --pod-network-cidr=10.244.0.0/16
cgroup でエラーが起きた
CGROUPS_MEMORY: missing

memory と /proc/cgroup を確認すると memory の enabled を見ると 0 、off になっているようだ。 memory を有効にすることを考える。

Read more...

k3sでコンテナをビルドする

Posted:   |   Categories: k3s   |   Tags: buildkit, gentoo, k3s, k8n, nerdctl

背景

ラズパイ上にGenPi64をインストールし、k3sでkubernetes環境を構築した。 このラズパイでdockerイメージをビルドしたい。

私の環境でのnerdctlはbuildkitが必要だった。

buildkitのインストールとbuildkitd(デーモン)の起動

インストール

buildkitはGo言語で書かれており多数のプラットフォーム向けにパッケージが提供されている。

buildkitのプロジェクトページ( moby/buildkit: concurrent, cache-efficient, and Dockerfilcnie-agnostic builder toolkit )の「Releases」に移動し「Assets」から各プラットフォームのtarアーカイブをダウンロードする。 私のラズパイ環境の場合、buildkit-v0.12.4.linux-arm64.tar.gz を用いた。

展開するとbinディレクトリができるので中身を全て/usr/local/bin配下にコピーした。cni

buildkitd(デーモン)の起動

systemdのユニットとして起動させたいが手軽に試す場合は下記で起動する。 これでビルドが開始できる。

sudo /usr/local/bin/buildkitd &

INFO[2024-01-17T23:05:15+09:00] auto snapshotter: using overlayfs
WARN[2024-01-17T23:05:15+09:00] using host network as the default
INFO[2024-01-17T23:05:15+09:00] found worker "icepdj7khuiltkpxu75ft0k9w", labels=map[org.mobyproject.buildkit.worker.executor:oci org.mobyproject.buildkit.worker.hostname:k3s-prd-agent-a org.mobyproject.buildkit.worker.network:host org.mobyproject.buildkit.worker.oci.process-mode:sandbox org.mobyproject.buildkit.worker.selinux.enabled:false org.mobyproject.buildkit.worker.snapshotter:overlayfs], platforms=[linux/arm64 linux/arm/v7 linux/arm/v6]
WARN[2024-01-17T23:05:15+09:00] skipping containerd worker, as "/run/containerd/containerd.sock" does not exist
INFO[2024-01-17T23:05:15+09:00] found 1 workers, default="icepdj7khuiltkpxu75ft0k9w"
WARN[2024-01-17T23:05:15+09:00] currently, only the default worker can be used.
INFO[2024-01-17T23:05:15+09:00] running server on /run/buildkit/buildkitd.sock

buildkitd起動後、Dockerfileが存在するディレクトリに移動して下記のようにビルドできる。

Read more...

k3s関連のメモ

Posted:   |   Categories: k3s   |   Tags: gentoo, k3s, k8n

背景

自宅サーバでk8nを試したい。ラズパイのディストリビューションの一つ、GenPi64(Gentooのarm64環境)でkubernetesを試す。 ラズパイはメモリが少ない(2023年時点でも8GBがmax)ので、軽量なkubernetes環境であるk3sを試す。 その際の雑多なメモ。

関連メモ

インストールディレクトリ

デーモン

/usr/local/bin/k3s

server,agentのデータ

/var/lib/rancher/k3s/{agent, server}

Terraformでk3sを管理したい

Terraformインストール

このページ にまとめた

Read more...