【2019年3月版】k3s 再挑戦

ちゃんとダウンロードしました。

こちらの記事で、失敗とか言ってましたがちゃんとダウンロードできていなかっただけのようで・・・すいませんでした。

ご教示いただきました--followスイッチと、さらに今回はちゃんと進捗が見れるようにpvコマンド挟んでみました。

$ http --follow https://github.com/rancher/k3s/releases/download/v0.1.0/k3s | pv > k3s
35.9MiB 0:01:55 [ 319KiB/s] [                             <=>                                                                           ]

$ chmod +x k3s
$ ./k3s --version
k3s version dev (HEAD)

バージョン表示が、出たっ！
無事に動くバイナリであることが確認できたので /usr/binに放り込みます。

$ sudo mv ./k3s /usr/bin/

さらにもう一台、Ubuntuを用意して同様に k3s を入れておきます。

起動

準備が整ったところで masterとagentを起動します。

master_side

$ sudo k3s server &
$ sudo cat /var/lib/rancher/k3s/server/node-token

/var/lib/rancher/k3s/server/node-tokenにagentoがjoinするためのトークンが入っております。表示されたnode-tokenの中身をコピペなどしておきます。

node_side

$ sudo k3s agent --server https://192.168.1.137:6443 --token K105af73429d26c1906517b140cadf4aea038270b1763bf9c2a9009dd687f9af5b5::node:bfa6f0059fc2d630dc87593782c804a0
INFO[2019-03-05T11:26:31.071133796Z] Starting k3s agent v0.1.0 (91251aa)
INFO[2019-03-05T11:26:31.392865524Z] Logging containerd to /var/lib/rancher/k3s/agent/containerd/containerd.log
INFO[2019-03-05T11:26:31.393068725Z] Running containerd -c /var/lib/rancher/k3s/agent/etc/containerd/config.toml -a /run/k3s/containerd/containerd.sock --state /run/k3s/containerd --root /var/lib/rancher/k3s/agent/containerd
INFO[2019-03-05T11:26:31.393240126Z] Waiting for containerd startup: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /run/k3s/containerd/containerd.sock: connect: no such file or directory"
INFO[2019-03-05T11:26:32.465387983Z] Connecting to wss://192.168.1.137:6443/v1-k3s/connect
INFO[2019-03-05T11:26:32.465453883Z] Connecting to proxy                           url="wss://192.168.1.137:6443/v1-k3s/connect"
INFO[2019-03-05T11:26:32.472880223Z] Running kubelet --healthz-bind-address 127.0.0.1 --read-only-port 0 --allow-privileged=true --cluster-domain cluster.local --kubeconfig /var/lib/rancher/k3s/agent/kubeconfig.yaml --eviction-hard imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --cgroup-driver cgroupfs --root-dir /var/lib/rancher/k3s/agent/kubelet --cert-dir /var/lib/rancher/k3s/agent/kubelet/pki --seccomp-profile-root /var/lib/rancher/k3s/agent/kubelet/seccomp --cni-conf-dir /var/lib/rancher/k3s/agent/etc/cni/net.d --cni-bin-dir /var/lib/rancher/k3s/data/4df430e1473d0225734948e562863c82f20d658ed9c

おお～つながったっぽい！

親側でnodeを表示してみます。

master_side

$ sudo k3s kubectl get node
NAME               STATUS   ROLES    AGE     VERSION
k3s-node   Ready    <none>   5m50s   v1.13.3-k3s.6
ubuk3s             Ready    <none>   133m    v1.13.3-k3s.6

よっし！

Piping Serverのデプロイ

早速、例のpiping serverを起動してみます。
(Piping Serverについてはこちらをご覧ください！)

以下で使用する piping-server.yamlは前回のMiniKube で Piping-serverの記事で作成したものです。

master_side

$ k3s kubectl apply -f piping-server.yaml
deployment.extensions/piping-server created
service/piping-server-svc created

$ k3s kubectl get node
NAME               STATUS   ROLES    AGE    VERSION
kube-node          Ready    <none>   24m    v1.13.3-k3s.6
ubuk3s             Ready    <none>   152m   v1.13.3-k3s.6

$ k3s kubectl get pods
NAME                             READY   STATUS    RESTARTS   AGE
piping-server-648f9f4b9d-wz45b   1/1     Running   0          80s

$ k3s kubectl get svc
NAME                TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
kubernetes          ClusterIP   10.43.0.1      <none>        443/TCP          154m
piping-server-svc   NodePort    10.43.250.53   <none>        8080:30080/TCP   100s

ちゃんとPodとServiceは生成されているようです。

$ k3s kubectl describe pod piping-server-648f9f4b9d-wz45b
Name:               piping-server-648f9f4b9d-wz45b
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               kube-node/192.168.1.144
Start Time:         Tue, 05 Mar 2019 11:51:20 +0000
Labels:             app=piping-server
                    pod-template-hash=648f9f4b9d
Annotations:        <none>
Status:             Running
IP:                 10.42.1.2
Controlled By:      ReplicaSet/piping-server-648f9f4b9d
Containers:
  piping-server:
    Container ID:   containerd://be8e54a7b32503287a843942160c3a6eae91c8d346c27a8e1717552c8616e7bd
    Image:          nwtgck/bytenode-piping-server
    Image ID:       docker.io/nwtgck/bytenode-piping-server@sha256:82afcb913d1bf37f6fbebdd6a3d45f4bc1da4424a2905cf6f85290125b2a932a
    Port:           8080/TCP
    Host Port:      8080/TCP
    State:          Running
      Started:      Tue, 05 Mar 2019 11:51:40 +0000
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     300m
      memory:  300Mi
    Requests:
      cpu:        300m
      memory:     300Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-qrbjf (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-qrbjf:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-qrbjf
    Optional:    false
QoS Class:       Guaranteed
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age    From                       Message
  ----    ------     ----   ----                       -------
  Normal  Scheduled  3m     default-scheduler          Successfully assigned default/piping-server-648f9f4b9d-wz45b to kube-node
  Normal  Pulling    2m54s  kubelet, kube-node  pulling image "nwtgck/bytenode-piping-server"
  Normal  Pulled     2m41s  kubelet, kube-node  Successfully pulled image "nwtgck/bytenode-piping-server"
  Normal  Created    2m40s  kubelet, kube-node  Created container
  Normal  Started    2m40s  kubelet, kube-node  Started container

さっそくノード側のIPをcurlで叩いてみましょう～

$ curl http://192.168.1.144:30080/
<html>
<head>
  <title>Piping</title>
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <style>
    h3 {
      margin-top: 2em;
      margin-bottom: 0.5em;
    }
  </style>
</head>
<body>
  <h1>Piping</h1>
  Streaming Data Transfer Server over HTTP/HTTPS
  <form method="POST" id="file_form" enctype="multipart/form-data">
    <h3>Step 1: Choose a file or text</h3>

    <input type="checkbox" id="inputMode" onchange="toggleInputMode()">: <b>Text mode</b><br><br>

    <input type="file" name="input_file">
    <textarea type="text" name="input_text" placeholder="Input text" cols="30" rows="10"></textarea>
    <br>

    <h3>Step 2: Write your secret path</h3>
    (e.g. "abcd1234", "mysecret.png?n=3")<br>
    <input id="secret_path" placeholder="Secret path" size="50"><br>
    <h3>Step 3: Click the submit button</h3>
    <input type="submit">
...

Piping server 起動してるっ！
それではさっそくノード側で待ち受けておいて・・・

node_side

$ curl http://192.168.1.144:30080/hw | tail
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    12    0    12    0     0      2      0 --:--:--  0:00:04 --:--:--     2

マスター側でecho〜！

master_side

$ echo "hello world" | curl -T - http://192.168.1.144:30080/hw
[INFO] Waiting for 1 receiver(s)...
[INFO] 1 receiver(s) has/have been connected.
Start sending!
[INFO] Sending Successful!

の送信完了！
ノード側でも受信できました！

node_side

$ curl http://192.168.1.144:30080/hw | tail
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    12    0    12    0     0      2      0 --:--:--  0:00:04 --:--:--     2
hello world

出ましたっ！

k3sちゃんとKubernetesしてる！(失礼!!)

ノードの削除

$ sudo k3s kubectl delete node kube-node

本体プロセスの停止

プロセスの停止はpsでk3s-serverのプロセス、もしくはk3s-agentのPIDを確認してkillしちゃってよいのでしょうか？
今日はsudo kill -9で仕留めてしまいましたが・・・大丈夫なのかしら？

まとめ

軽量k8sの実行環境k3sは一応、基本的なコンテナのデプロイとノードIPのexposeはイケるようです。
楽しくなってきたのでちょっと重めのものを載せていきたいと思います！

本日は以上です。

2019.11.08 追記: GKE と併用する場合の注意

GKE というか gcloud cluster get-credential コマンドで ~/.kube/config が上書きされます。

k3s 動かした後で sudo k3s kubectl がめんどくさくなってくると思わず kubectl コマンド使ってしまうかもしれません。

事故防止のために /etc/rancher/k3s/k3s.yaml を ~/.kube/config に上書きしておきましょう。

$ mv ~/.kube/config ~/.kube/config.bk
$ sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
$ sudo chmod 666 ~/.kube/config

としておけば kubectl で GKE のサーバーを誤って操作してしまうことはなくなります。

GKEを操作する場合は、再度、

$ gcloud container clusters get-credentials クラスタ名 --project プロジェクト名

を行いましょう。