winds.from.oz 技術メモ

Category: K3s

k3s上でxpra + OpenboxのGUI Podを動かす設計

Posted:   |   Categories: k3s   |   Tags: gui, k3s, kubernetes, openbox, xpra

k3s上でxpra + OpenboxのGUI Podを動かす設計

k3s 上で一時的な GUI desktop を動かしたい場合、xpra start-desktop と Openbox の組み合わせは小さく始めやすい。

目的は「Kubernetes 上に恒久的な VDI を作る」ではなく、検証用の軽量 desktop を 1 Pod で起動し、browser から操作できるようにすることである。

最小構成

flowchart LR
  Browser["Browser"]
  Ingress["Ingress or port-forward"]
  Service["Service :10000"]
  Pod["Pod"]
  Xpra["xpra server + HTML5 client"]
  Openbox["Openbox session"]
  Tmp["emptyDir runtime dirs"]

  Browser --> Ingress --> Service --> Pod
  Pod --> Xpra --> Openbox
  Pod --> Tmp

最初の PoC は次の範囲に絞る。

  • 1 namespace
  • 1 Deployment
  • 1 ClusterIP Service
  • HTML5 client
  • Openbox session
  • /tmp、/var/tmp、/run/user/<uid> は emptyDir
  • audio / GPU / IME は後回し

この範囲なら、resource と security の切り分けがしやすい。

Read more...

k3sで動作確認

Posted:   |   Categories: k3s   |   Tags: k3s

まずは context を確認・選択

使う設定ファイルを明示（任意）

export KUBECONFIG=$HOME/.kube/config

現在の context

kubectl config current-context

k3s-homelab に切り替え（必要なら）

kubectl config use-context k3s-homelab

今の context の中身を最小表示

kubectl config view --minify

接続テスト（API～認可まで）

1) API サーバ情報（到達 & TLS 確認）

kubectl cluster-info

2) API のヘルスチェック（livez/readyz）

kubectl get --raw /livez?verbose
kubectl get --raw /readyz?verbose

3) バージョンの握手

kubectl version --short

4) ノード一覧（RBAC も有効に確認）

kubectl get nodes -o wide

5) 権限チェック（このユーザで何ができる？）

kubectl auth can-i --list

例: すべての Pod を読める？

kubectl auth can-i get pods --all-namespaces
Read more...

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のメモ

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...

terraformでk3sのバッチ処理

Posted:   |   Categories: k3s   |   Tags: k3s

背景

自宅のk3sをterraformで管理したい。 ひとまず手軽に試せそうなバッチ処理をためした

バッチジョブの定義

main.tf で下記を定義

resource "kubernetes_job" "example" {
  metadata {
    name = "example-job"
  }
  spec {
    template {
      metadata {
        name = "example-job"
      }
      spec {
        container {
          name    = "example"
          image   = "busybox"
          command = ["sh", "-c", "echo Hello, World! && sleep 30"]
        }
        restart_policy = "Never"
      }
    }
    backoff_limit = 4
  }
}

Terraform の初期化と適用

terraform init terraform plan terraform aplly

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...