涅槃を目指す in はてな

人生に迷う様を書きます

mutter-rounded を使って Ubuntu 22 のデスクトップを透けさせる

TL;DR

  • いろんなものが透けてるデスクトップは癒やし効果がある
  • GNOME Shell拡張機能がかんたんにできそうだけど、mutter-rounded というのを使ってもできる
  • いろんなものが透けてるデスクトップは癒やし効果がある（復唱）

どうした

デスクトップを透けさせたいんです。格好いいから。厨二だから

これが我が家のUbuntuデスクトップ。VSCodeとKonsoleを開いた状態です。

透けてます。とても気分がいいですね。

ところが、Nautilus（ファイルマネージャのことです。MacでいうFinder的なもの）を開くと

なんすかこれ。全ッ然透けてない。真っ黒。政府の検閲後？

気分が悪いです。「エンジニアなので手順やログを透かしながら作業云々」とかいう大義名分以前の問題。監督、透けてるのが見たいです。

私が使ってるUbuntu 22.04LTSは、GNOME Shell拡張機能が充実してて、記事中にあるblur-my-shellなんかを使うと透明化できそうです。

ただ、私のblur-my-shellが腐ってるせいなのか、blur-my-shellの個々のアプリケーションを透過させる機能がベータ版なせいなのかは不明ですが、できたと思ったら再起動のタイミングで戻ったりして悶々とした日々を過ごしていました。

しかし昨日！mutter-rounded に出会ったことで解決したので、今回はその手順を残したいと思います。

blur-my-shellの方が確実に楽なんですが、私のようにどうも上手く透明化できないという方は試してみて下さい。

環境

  • OS:Ubuntu 22.04.1 LTS
  • GNOMEのバージョン:42.4
  • ウィンドウシステム:X11

mutter-rounded のインストール

まずはこちらを入れます。丁寧に書いてくれてるREADME通りです。

github.com

cloneして、インストール用のスクリプトを実行してパッケージを入れます。 package.shは数分かかりました。

git clone https://github.com/yilozt/mutter-rounded
cd ./mutter-rounded/ubuntu
./package.sh

sudo dpkg -i libmutter-10-0*.deb mutter-common*.deb

mutter-rounded-setting のインストール

次はmutter-rounded-settingを入れます。設定用のGUIツールです。

github.com

まず、yarnとwebpackが入ってない人はinstallしましょう

sudo apt install yarn webpack

あとは先ほどと同様に、cloneしてinstallです。

git clone https://github.com/yilozt/mutter-rounded-setting
cd ./mutter-rounded-setting
./install

これでツールのインストールは完了です。次は実際に設定してみましょう。

mutter-rounded の設定

gjsコマンドでGUIを起動させましょう

# mutter-rounded-settingディレクトリにいる前提

gjs dist/mutter_settings.js

このようなGUIが立ち上がると思います。

Blur Effectタブを開きましょう

このタブの中段にあるBlured Listに透かしたいアプリを登録していきます。

+を押して、org.gnome.Nautilusと入力しEnterを押しましょう。

そしてNautilusを立ち上げると！なんとういことでしょう！（開いてる場合は閉じて開け直して下さい）

透けてるよ兄さん！兄さん透けてるよ！

Blur sigmal（背景のボカシ具合）やBlured window opacity（透かすときの透明度）などを設定できます。

キミだけのスケスケNautilusを作ろう！

しかし、『他にも透けさせたいけどorg.gnome.Nautilusとか言う名前はどうやって調べたらいいの？』と思うでしょう。

そういうときはまず、透けさせたい物を起動させた状態で、先ほどと同じように+を押して、画像矢印の照準みたいなマークをクリックしよう

そうするとウィンドウ選択モードになり、透過させたいウィンドウをクリックすると自動的に名前が設定されるようになります。

もしくはターミナルでxprop|grep WM_CLASSと打った状態で目的のウィンドウをクリックすると名前が表示されるので、それを設定しましょう。

画像はFirefoxの「名前をつけて保存」なんかのときに出るダイアログをクリックしたときの画面。

xdg-desktop-portal-gnomeという名前が設定されたのが分かります。

設定された後にもう1回ダイアログを開き直すと、背景のGoogleロゴが透けていますね。

手順としては以上です！

こんな感じで色々なものを透明化できます。透け=癒やし

参考にしたもの

この通りです。文章ではイマイチわからんという方はこちらの動画を参考にして下さい。

www.youtube.com

最後までお読み頂き有難うございました！

RKEのデプロイに失敗したけど解決した話

TL;DR

どうした

どうしたもこうしたも、今年こそ本気出す ２０２２ - 涅槃を目指す in はてなから、半年以上経ってます。

怠惰です。七つの大罪の一つです。すいませんでした。

心を入れ替えて久しぶりに、真面目にVirtualboxで作成したVMにRKEをデプロイしようとしたらデプロイに失敗して結構困りました。

同じようなトラブルで苦しんでる方がいるかもしれないと思い今回の記事を作成しました。

やりたかったこと

Master1台、Worker3台のクラスタをVagrantで作成し、RKEをデプロイしようとしました。

バージョンは以下の通り

項目 バージョン
RKE v1.3.12
kubernetes v1.23.7-rancher1-1
Docker 20.10.17
VMのOS Ubuntu 20.04

作成したVagrantfileは以下の通り。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# 共通のプロビジョニングスクリプト
$configure_common = <<-SHELL

# swap off
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# パッケージ更新
sudo apt update
sudo apt -y upgrade


# docker install 
curl https://releases.rancher.com/install-docker/20.10.sh | sh
sudo usermod -aG docker vagrant

SHELL

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/focal64"
  config.vm.box_check_update = false
  config.vm.define "master" do |cf|
    cf.vm.hostname = "master"
    cf.vm.network "private_network", ip: "192.168.56.101"
    cf.vm.provider "virtualbox" do |vb|
      vb.cpus = 2
      vb.memory = 4096
    end
    config.vm.provision "shell", inline: $configure_common
  end

(0..2).each do |n|
    config.vm.define "worker-#{n}" do |config|
        config.vm.hostname = "worker-#{n}"
        config.vm.network "private_network", ip: "192.168.56.11#{n}"
        config.vm.provider "virtualbox" do |vb|
          vb.gui = false
          vb.cpus = 2
          vb.memory = 4096
        end
    end
        config.vm.provision "shell", inline: $configure_common
  end
end

そしてRKEをデプロイするために使用するyamlは以下の通り。

nodes:
    - address: 192.168.56.101
      user: vagrant
      role:
        - controlplane
        - etcd
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.101
    - address: 192.168.56.110
      user: vagrant
      role:
        - worker
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.110
    - address: 192.168.56.111
      user: vagrant
      role:
        - worker
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.111
    - address: 192.168.56.112
      user: vagrant
      role:
        - worker
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.112
network:
  plugin: canal
  options:
    canal_iface: enp0s8

ご存じない方のために説明すると、RKE（Rancher Kubernetes Engine）はKubernetesディストリビューションの一つです。 Kubeadmのように、簡単にKubernetesをデプロイする機能も持っています。

上記のようなyamlを作成し、操作端末からrkeコマンドのバイナリをrke upと実行させればKubernetesクラスタが出来ます！

rancher.com

起きた事象

rke upすると、こんなログが出てクラスタが作成できないようです。

ERRO[0234] Host 192.168.56.101 failed to report Ready status with error: [controlplane] Error getting node 192.168.56.101:  "192.168.56.101" not found 
INFO[0234] [controlplane] Processing controlplane hosts for upgrade 1 at a time 
INFO[0234] Processing controlplane host 192.168.56.101  
INFO[0234] [controlplane] Now checking status of node 192.168.56.101, try #1 
ERRO[0259] Failed to upgrade hosts: 192.168.56.101 with error [[controlplane] Error getting node 192.168.56.101:  "192.168.56.101" not found] 
FATA[0259] [controlPlane] Failed to upgrade Control Plane: [[[controlplane] Error getting node 192.168.56.101:  "192.168.56.101" not found]]

192.168.56.101はmaster nodeのIPアドレスで、どうもReadyにならないようだ。

RKEが作成されるとkube_config_cluster.ymlというkubectl用のconfigファイルが作成されるので、それを指定してnodeを確認。

$ kubectl --kubeconfig kube_config_cluster.yml get nodes
No resources found

ないっすよね。ですよね。困った。

おい！オレのRKE。おい！オレのRKE。 さあ、動くのかい? さあ、動かないのかい？どっちなんだい！

調べる

masterにログインしてdocker ps してみる。

vagrant@master:~$ docker ps
CONTAINER ID   IMAGE                                 COMMAND                  CREATED         STATUS         PORTS     NAMES
dcb908754bfa   rancher/hyperkube:v1.23.7-rancher1    "/opt/rke-tools/entr…"   4 minutes ago   Up 4 minutes             kube-proxy
e4db37e3c2fb   rancher/hyperkube:v1.23.7-rancher1    "/opt/rke-tools/entr…"   4 minutes ago   Up 4 minutes             kubelet
5700dbaf0cbd   rancher/hyperkube:v1.23.7-rancher1    "/opt/rke-tools/entr…"   4 minutes ago   Up 4 minutes             kube-scheduler
9ec14d8d04a2   rancher/hyperkube:v1.23.7-rancher1    "/opt/rke-tools/entr…"   4 minutes ago   Up 4 minutes             kube-controller-manager
0feac423d1a9   rancher/hyperkube:v1.23.7-rancher1    "/opt/rke-tools/entr…"   4 minutes ago   Up 4 minutes             kube-apiserver
630942af5243   rancher/rke-tools:v0.1.80             "/docker-entrypoint.…"   5 minutes ago   Up 5 minutes             etcd-rolling-snapshots
8b33f9d622fd   rancher/mirrored-coreos-etcd:v3.5.3   "/usr/local/bin/etcd…"   5 minutes ago   Up 5 minutes             etcd

kubeletやkube-apiserverのような大事なコンテナは出来てそうだ。

docker logs kubelet をしてみる

I0801 23:49:07.271980   33070 csi_plugin.go:1063] Failed to contact API server when waiting for CSINode publishing: csinodes.storage.k8s.io "192.168.56.101" is forbidden: User "system:node" cannot get resource "csinodes" in API group "storage.k8s.io" at the cluster scope
E0801 23:49:07.272971   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.373336   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.476548   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.579568   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.689541   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.789736   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.890476   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:07.991082   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:08.091294   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"
E0801 23:49:08.192441   33070 kubelet.go:2461] "Error getting node" err="node \"192.168.56.101\" not found"

nodeが見つからない。いや君あるやないかい。どういうこと？

ググったらこれですよ

github.com

hostname_override: を入れてみろと。rkeでもできるらしい

rancher.com

修正したyamlが以下です。hostname_override: masterとか入れてます。

nodes:
    - address: 192.168.56.101
      user: vagrant
      role:
        - controlplane
        - etcd
      hostname_override: master
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path:<path_to_private_key>
      internal_address: 192.168.56.101
    - address: 192.168.56.110
      user: vagrant
      role:
        - worker
      hostname_override: worker-0
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.110
    - address: 192.168.56.111
      user: vagrant
      role:
        - worker
      hostname_override: worker-1
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.111
    - address: 192.168.56.112
      user: vagrant
      role:
        - worker
      hostname_override: worker-2
      port: 22
      docker_socket: /var/run/docker.sock
      ssh_key_path: <path_to_private_key>
      internal_address: 192.168.56.112
network:
  plugin: canal
  options:
    canal_iface: enp0s8

これで一旦vagrant destroyしてからrke up したら。

$ kubectl --kubeconfig kube_config_cluster.yml get nodes
NAME       STATUS   ROLES               AGE   VERSION
master     Ready    controlplane,etcd   12m   v1.23.7
worker-0   Ready    worker              11m   v1.23.7
worker-1   Ready    worker              11m   v1.23.7
worker-2   Ready    worker              11m   v1.23.7

できてるー。Thanks GOD !

しかしどういうこと？

考察

Githubには、証明書で使われている名前とnodeの名前の不一致が原因では？と書かれていた。

Rancher Docs: Nodesには、

hostname_overrideは、Kubernetesにノードを登録する際にRKEが使用するフレンドリーな名前を提供できるようにするために使用されます。 このホスト名はルーティング可能なアドレスである必要はありませんが、有効なKubernetesリソース名である必要があります。 hostname_overrideが設定されていない場合、Kubernetesにノードを登録する際にaddressディレクティブが使用されます。

とあります。

あー、てことは

  1. IPアドレスでノードが登録される
  2. hostnameで証明書が作成される
  3. kubeletがAPI ServerにPアドレスで通信しようとしたけど、証明書のホスト名と不一致でnot found

てこと？

昔はこんなのなかったのに不思議やわ。

まあいいか、最後までお読み頂きありがとうございました！

今年こそ本気出す ２０２２

ポエム

あっという間に年が明けてしまったので、去年を振り返りつつ今年の意気込みを書きます

2021を振り返る

良かった

  • 3月に転職した会社が良い会社だった。未経験分野が多くチャレンジできそう
  • ずっとやろうと思ってたKubernetes The Hard Wayを完走できた

良くなかった

  • 自宅k8s環境が整えられなかった
  • CI/CD周りの習得が疎かだった
  • 一つのことをじっくり腰を据えてやる機会が少なかった

2022にやりたいこと

Kubernetes The Hard Way On VirtualBox 13日目

kubernetes

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの13日目。

Smoke Test

スモークテストとは、プログラムの必須機能が正常動作することを確認するためのテストです。

今回は作成したk8sクラスタの機能が正常動作することを確認します。

Data Encryption

ここでは、etcdに書き込むデータを暗号化する機能の確認をします。

まずsecretを作成します。

kubectl create secret generic kubernetes-the-hard-way \
>   --from-literal="mykey=mydata"

etcdに保存されているkubernetes-the-hard-wayシークレットの16進ダンプを出力します。

sudo ETCDCTL_API=3 etcdctl get \
>   --endpoints=https://127.0.0.1:2379 \
>   --cacert=/etc/etcd/ca.crt \
>   --cert=/etc/etcd/etcd-server.crt \
>   --key=/etc/etcd/etcd-server.key\

結果

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 6b 75 62 65 72 6e  |s/default/kubern|
00000020  65 74 65 73 2d 74 68 65  2d 68 61 72 64 2d 77 61  |etes-the-hard-wa|
00000030  79 0a 6b 38 73 3a 65 6e  63 3a 61 65 73 63 62 63  |y.k8s:enc:aescbc|
00000040  3a 76 31 3a 6b 65 79 31  3a ac 17 6e c5 3f 70 3b  |:v1:key1:..n.?p;|
00000050  0f b6 c8 07 87 3d d3 09  ef 54 18 7c ad 88 fd 15  |.....=...T.|....|
00000060  f2 9b 50 6c fa 6f 41 1c  a9 38 bc 6c 97 3b 0c 1d  |..Pl.oA..8.l.;..|
00000070  00 9a b0 f9 bc 93 7b dd  df fe fd 1b 09 88 f8 9e  |......{.........|
00000080  7a 1c 28 5b 0d 66 e9 a1  3d 31 cd 98 15 d4 94 49  |z.([.f..=1.....I|
00000090  8a 8e ea 33 c2 84 73 80  fb b1 87 e4 65 3e 16 83  |...3..s.....e>..|
000000a0  ec 69 6f 21 39 bd 69 13  86 82 1a 09 8f 1d df 09  |.io!9.i.........|
000000b0  34 c7 ba cf 7b 60 69 16  a8 85 07 e3 51 38 02 f3  |4...{`i.....Q8..|
000000c0  da cb fd d3 4c 79 30 70  d2 e2 61 96 24 96 f9 f1  |....Ly0p..a.$...|
000000d0  56 6b 46 ee 75 13 26 53  2b fa 2d c1 b9 65 15 3e  |VkF.u.&S+.-..e.>|
000000e0  b1 9c e5 48 8c 4d fc 7e  03 63 63 10 ac f9 0a 25  |...H.M.~.cc....%|
000000f0  4e 06 3d 32 10 b8 f2 49  80 9b fe 39 f9 c9 67 a5  |N.=2...I...9..g.|
00000100  a2 88 30 1d 8d 0b d6 b9  50 99 4d b6 74 c9 9f 89  |..0.....P.M.t...|
00000110  be 0c eb a1 bc d7 e5 67  70 5d f7 cc 62 4b 0d 00  |.......gp]..bK..|
00000120  9f ea 67 00 fc a2 29 ea  f3 95 d0 aa ed c1 f2 b3  |..g...).........|
00000130  e3 30 15 37 de df 77 3b  db bc 10 1a 8c 0d 27 af  |.0.7..w;......'.|
00000140  36 34 32 b4 c9 f2 a8 ad  8a 83 cb 44 39 c1 72 47  |642........D9.rG|
00000150  ce 81 6f 09 8a 8d 15 51  2d 0a                    |..o....Q-.|
0000015a

etcdキーの前にk8s：enc：aescbc：v1：key1を付ける必要があります。これは、aescbcプロバイダーがkey1暗号化キーでデータを暗号化するために使用されたことを示します。

確認が終わったら掃除しましょう。

kubectl delete secret kubernetes-the-hard-way

Deployments

ここではDeploymentの作成、管理機能を確認します。

nginxのDeploymentを作成します。

kubectl create deployment nginx --image=nginx

nginx Deploymentが作成したPodを確認します。

kubectl get pods -l app=nginx

以下のように出力されればOKです。

NAME                     READY   STATUS    RESTARTS   AGE
nginx-6799fc88d8-5z585   1/1     Running   0          43s

Services

ここではServiceの作成、管理機能を確認します。

nodeのPortを公開するnginxのサービスを作成します。

kubectl expose deploy nginx --type=NodePort --port 80
PORT_NUMBER=$(kubectl get svc -l app=nginx -o jsonpath="{.items[0].spec.ports[0].nodePort}")

curlで確認してみましょう

curl http://worker-1:$PORT_NUMBER
curl http://worker-2:$PORT_NUMBER

以下のように出力されればOKです。

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Logs

ここでは、コンテナのログを取得する機能を確認します。

まずnginxPodのフルネームを取得します。

POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath="{.items[0].metadata.name}")

logを取得します。

kubectl logs $POD_NAME

以下のように出力されます

vagrant@master-1:~$ kubectl logs $POD_NAME
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2021/12/27 23:59:44 [notice] 1#1: using the "epoll" event method
2021/12/27 23:59:44 [notice] 1#1: nginx/1.21.4
2021/12/27 23:59:44 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 
2021/12/27 23:59:44 [notice] 1#1: OS: Linux 4.15.0-163-generic
2021/12/27 23:59:44 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2021/12/27 23:59:44 [notice] 1#1: start worker processes
2021/12/27 23:59:44 [notice] 1#1: start worker process 31

Exec

ここではコンテナ内でコマンドを実行できるか確認します。

nginx コンテナでnginx -vコマンド実行し、バージョンを出力させてみます。

kubectl exec -ti $POD_NAME -- nginx -v

以下のように出力されます

vagrant@master-1:~$ kubectl exec -ti $POD_NAME -- nginx -v
nginx version: nginx/1.21.4

今回はここまで！

お読み頂き有難うございました。

Kubernetes The Hard Way On VirtualBox 12日目

kubernetes

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの12日目。

Deploying the DNS Cluster Add-on

今回は Kubernetesクラスタ内部にCoreDNSを使った名前解決の仕組みをデプロイします。DNSベースのサービスディスカバリのためです。

The DNS Cluster Add-on

corednsアドオンをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml

実行結果

vagrant@master-1:~$ kubectl apply -f https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml
serviceaccount/coredns created
configmap/coredns created
deployment.apps/coredns created
service/kube-dns created
unable to recognize "https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml": no matches for kind "ClusterRole" in version "rbac.authorization.k8s.io/v1beta1"
unable to recognize "https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1"

あー、rbac.authorization.k8s.io/v1beta1がrbac.authorization.k8s.io/v1になってる問題か！

修正したいので、

wget https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml

でcoredns.yamlを落としてきて、rbac.authorization.k8s.io/v1beta1がrbac.authorization.k8s.io/v1に置換しました。

実行結果

vagrant@master-1:~$ kubectl apply -f coredns.yaml serviceaccount/coredns unchanged
clusterrole.rbac.authorization.k8s.io/system:coredns created
clusterrolebinding.rbac.authorization.k8s.io/system:coredns created
configmap/coredns unchanged
deployment.apps/coredns unchanged
service/kube-dns unchanged

OKOK！

kube-dns デプロイメントによって作られたpodを確認できます。

kubectl get pods -l k8s-app=kube-dns -n kube-system

実行結果

vagrant@master-1:~$ kubectl get pods -l k8s-app=kube-dns -n kube-system
NAME                       READY   STATUS    RESTARTS       AGE
coredns-5cccc7b6cc-l2w6g   1/1     Running   2 (2m4s ago)   6m34s
coredns-5cccc7b6cc-nsp28   1/1     Running   2 (2m4s ago)   6m34s

Verification

busybox podを作成ます。公式だと --generator=run-pod/v1 というオプションがついてますが、kubernetes v1.18以降では不要です。

kubectl run busybox --image=busybox:1.28 --command -- sleep 3600

作成されたpodを確認

kubectl get pods -l run=busybox

実行結果

vagrant@master-1:~$ kubectl get pods -l run=busybox
NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          23s

作成したpodの名前解決が出来るか、kubernetesサービスにDNS Lookupをしてみましょう

kubectl exec -ti busybox -- nslookup kubernetes

実行結果

vagrant@master-1:~$ kubectl exec -ti busybox -- nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

出来ているようですね！

今回はここまで！ お読み頂き有難うございました！

Kubernetes The Hard Way On VirtualBox 11日目

kubernetes

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの11日目。

今日はRBACの設定です。

RBAC for Kubelet Authorization

今回はRBACの設定をして、Kubernetes API Serverが各workerノードのKubelet APIにアクセス出来るようにします。 Kubelet APIにアクセスするのは、メトリクスやログの収集やコマンドの実行に必要です。

Kubelet APIにアクセスし、Podの管理に関連する最も一般的なタスクを実行するための権限を持つsystem:kube-apiserver-to-kubelet ClusterRoleを作成します。

master-1,master-2で以下のコマンドを実行します。

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

こんなエラーが出た

error: unable to recognize "STDIN": no matches for kind "ClusterRole" in version "rbac.authorization.k8s.io/v1beta1"

ClusterRoleがない？いやドキュメントにも有るし、そんな訳ないよな。

と思いきや、Deprecated API Migration Guide | Kubernetesによると

The rbac.authorization.k8s.io/v1beta1 API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding is no longer served as of v1.22.

とあるな。ワイのバージョンは

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T18:03:20Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T17:57:25Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

1.22だからダメなんか？

Migrate manifests and API clients to use the rbac.authorization.k8s.io/v1 API version, available since v1.8.

rbac.authorization.k8s.io/v1 を使うのか。

コマンドを以下のよう修正。

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

実行結果

vagrant@master-1:~$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
> apiVersion: rbac.authorization.k8s.io/v1
> kind: ClusterRole
> metadata:
>   annotations:
>     rbac.authorization.kubernetes.io/autoupdate: "true"
>   labels:
>     kubernetes.io/bootstrapping: rbac-defaults
>   name: system:kube-apiserver-to-kubelet
> rules:
>   - apiGroups:
>       - ""
>     resources:
>       - nodes/proxy
>       - nodes/stats
>       - nodes/log
>       - nodes/spec
>       - nodes/metrics
>     verbs:
>       - "*"
> EOF
clusterrole.rbac.authorization.k8s.io/system:kube-apiserver-to-kubelet created

OKOK！

Kubernetes API Serverは、--kubelet-client-certificateフラグで定義されたクライアント証明書を使用して、system:kube-apiserverユーザーとしてKubeletに認証をかけます。

system:kube-apiserver-to-kubeletクラスターロールをsystem:kube-apiserverユーザにバインドさせます。

コレも先ほどと同様、公式はapiVersion: rbac.authorization.k8s.io/v1beta1でしたけど、apiVersion: rbac.authorization.k8s.io/v1に変えてます

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kube-apiserver
EOF

今日はここまで！ お読み頂き有難うございました！

Kubernetes The Hard Way On VirtualBox 10日目

kubernetes

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの10日目。

今日はネットワーク設定です。

Provisioning Pod Network

今回、kubernetesのネットワークはCNI weave プラグインを使います。

CNIとは何か

containernetworking/cni: Container Network Interface - networking for Linux containers

CNIは（Container Network Interface）の略で、コンテネットワークのAPIです。コンテナのネットワークをInterfaceとして切り出したので様々なベンダーやプロジェクトでプラグインが作成されています。 今回はweaveプラグインを使います。

Install CNI plugins

worker-1 と worker-2 で、プラグインをダウンロードします・

wget https://github.com/containernetworking/plugins/releases/download/v1.0.1/cni-plugins-linux-amd64-v1.0.1.tgz

/opt/cni/bin/ ディレクトリに解凍します

sudo tar -xvzf cni-plugins-linux-amd64-v1.0.1.tgz --directory /opt/cni/bin/

Deploy Weave Network

weaveをデプロイします。 master-1 で以下のコマンドを実行

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Verification

masterノードから、weave Podの起動を確認できます。

vagrant@master-1:~$ kubectl get pods -n kube-system
NAME              READY   STATUS    RESTARTS        AGE
weave-net-szm6v   2/2     Running   1 (8m28s ago)   8m39s
weave-net-wdcjr   2/2     Running   1 (8m28s ago)   8m39s

ずっと NotReady だったNodeのステータスも変わりました

vagrant@master-1:~$ kubectl get node
NAME       STATUS   ROLES    AGE   VERSION
worker-1   Ready    <none>   60d   v1.22.0
worker-2   Ready    <none>   25d   v1.22.0

今日はここまで！ お読み頂き有難うございました。