Skip to content

Instantly share code, notes, and snippets.

@coord-e

coord-e/ictsc-avu-1677987262.md Secret

Created March 11, 2023 05:56
Show Gist options
  • Save coord-e/230fc55f5c2e25e33156528f534e05f2 to your computer and use it in GitHub Desktop.
Save coord-e/230fc55f5c2e25e33156528f534e05f2 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
ictsc-avu-1677987262.md

お世話になっております。チーム word-unknown-tsukuba-otaku です。

原因

結論から申し上げますと、各ノードでの Ceph のための LVM の論理ボリュームが inactive になっていたことが原因で種々の問題が発生しておりました。

まず、魔王様が仰られていた「nginx が動作しない」という症状は、nginx の Pod が Unknown 状態になっており、Running ではないことが直接の原因です。

user@k8s-master:~$ kubectl get pods -l app=nginx
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-bc7c9f854-kxw4l   0/1     Unknown   0          2d17h
nginx-deployment-bc7c9f854-rqcwv   0/1     Unknown   0          2d17h

さて、Unknown 状態である理由を見ると、Pod にボリュームがアタッチできていないことがわかります。

user@k8s-master:~$ kubectl describe pod -l app=nginx
...
  Warning  FailedMount             2d16h                   kubelet                  MountVolume.MountDevice failed for volume "pvc-408ddef0-3604-4521-bb85-ad3f7eb6d250" : rpc error: code = DeadlineExceeded desc = context deadline exceeded
  Warning  FailedMount             2d16h (x4 over 2d16h)   kubelet                  Unable to attach or mount volumes: unmounted volumes=[nginx-data], unattached volumes=[nginx-data kube-api-access-hc8tq]: timed out waiting for the condition
  Warning  FailedMount             2d16h                   kubelet                  Unable to attach or mount volumes: unmounted volumes=[nginx-data], unattached volumes=[kube-api-access-hc8tq nginx-data]: timed out waiting for the condition
...

さて、該当クラスターには Rook Ceph を用いたストレージシステムが rook-ceph 名前空間に構築されており、nginx の Pod はこのストレージシステムから PVC を使ってボリュームを利用しようとするもそれが失敗していました。

user@k8s-master:~$ kubectl -n rook-ceph get cephcluster
NAME        DATADIRHOSTPATH   MONCOUNT   AGE     PHASE   MESSAGE                        HEALTH        EXTERNAL
rook-ceph   /var/lib/rook     3          2d17h   Ready   Cluster created successfully   HEALTH_WARN

HEALTH_WARN とあることからこのストレージシステムになんらかの異常があってボリュームがアタッチできていないことが予想できます。 そこで rook-ceph の Pod を見ると、rook-ceph-osd-{0,1,2} の Pod が正常に起動できていないことがわかります。

user@k8s-master:~$ kubectl get pods -n rook-ceph
...
rook-ceph-osd-0-868b447786-vwp7t                       0/1     Init:CrashLoopBackOff   7 (30s ago)   2d17h
rook-ceph-osd-1-6b59ddf599-vqlkw                       0/1     Init:CrashLoopBackOff   7 (30s ago)   2d17h
rook-ceph-osd-2-cf97ddf6f-gd2p7                        0/1     Init:CrashLoopBackOff   7 (42s ago)   2d17h
...

rook-ceph-osd-0 Deployment を例にとってログから原因を確認すると、/dev/ceph-... というパスがないことが原因のようです。なお、今回は init container でのエラーということで init container である activate のログを確認しています。

user@k8s-master:~$ kubectl -n rook-ceph logs deploy/rook-ceph-osd-0 -c activate
...
 stderr: failed to read label for /dev/ceph-2fa13f0a-1abb-4029-b99d-2f43ddb5ef89/osd-block-1ac35bdb-9d75-4cf1-b7e1-64efe618758e: (2) No such file or directory
...

さて、/dev/ceph-... のパスは、各ノードにおける LVM の論理ボリュームです。しかし、inactive (NOT available) であるためにブロックデバイスとして利用することができなくなっています。 rook-ceph-osd-0 が実行されているノードである k8s-node-2 で確認します。

user@k8s-node-2:~$ sudo apt update && sudo apt install -y lvm2  # lvdisplay 等のために必要
user@k8s-node-2:~$ sudo lvdisplay
  --- Logical volume ---
  LV Path                /dev/ceph-2fa13f0a-1abb-4029-b99d-2f43ddb5ef89/osd-block-1ac35bdb-9d75-4cf1-b7e1-64efe618758e
  LV Name                osd-block-1ac35bdb-9d75-4cf1-b7e1-64efe618758e
  VG Name                ceph-2fa13f0a-1abb-4029-b99d-2f43ddb5ef89
  LV UUID                myzDdW-mHlq-BZDR-YZdk-jo8O-kCZc-ohy0Ea
  LV Write Access        read/write
  LV Creation host, time rook-ceph-osd-prepare-k8s-node-2-svwlf, 2023-03-02 18:26:51 +0900
  LV Status              NOT available
  LV Size                <20.00 GiB
  Current LE             5119
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

user@k8s-node-2:~$ ls /dev/ceph-2fa13f0a-1abb-4029-b99d-2f43ddb5ef89/osd-block-1ac35bdb-9d75-4cf1-b7e1-64efe618758e
ls: cannot access '/dev/ceph-2fa13f0a-1abb-4029-b99d-2f43ddb5ef89/osd-block-1ac35bdb-9d75-4cf1-b7e1-64efe618758e': No such file or directory

解決

そのため、各ノードで論理ボリュームを activate した後に rook-ceph-operator を再起動することでストレージシステムを復旧することができました。 具体的には、それぞれのノードで次のコマンドを実行しました。

user@k8s-node-1:~$ sudo apt update && sudo apt install -y lvm2
user@k8s-node-1:~$ sudo lvchange -ay ceph-cbc782ab-41ec-4534-a4d2-5d52e4933387/osd-block-22ae25ff-b4d5-4562-b329-12b08a0bbfd3

user@k8s-node-2:~$ sudo apt update && sudo apt install -y lvm2
user@k8s-node-2:~$ sudo lvchange -ay ceph-2fa13f0a-1abb-4029-b99d-2f43ddb5ef89/osd-block-1ac35bdb-9d75-4cf1-b7e1-64efe618758e

user@k8s-node-3:~$ sudo apt update && sudo apt install -y lvm2
user@k8s-node-3:~$ sudo lvchange -ay ceph-99240cb9-24bf-4a88-a77b-f05521c03d55/osd-block-0f86f995-122c-424c-8e1f-7afd8b46fd22

user@k8s-master:~$ kubectl -n rook-ceph rollout restart deploy/rook-ceph-operator
deployment.apps/rook-ceph-operator restarted

程なくして、rook-ceph-osd の Pod が復旧し、Ceph のクラスタが HEALTH_OK に復旧します。

user@k8s-master:~$ kubectl -n rook-ceph get pods -l app=rook-ceph-osd
NAME                               READY   STATUS    RESTARTS      AGE
rook-ceph-osd-0-868b447786-vwp7t   1/1     Running   1 (28m ago)   2d17h
rook-ceph-osd-1-6b59ddf599-vqlkw   1/1     Running   1 (29m ago)   2d17h
rook-ceph-osd-2-cf97ddf6f-gd2p7    1/1     Running   1 (28m ago)   2d17h
user@k8s-master:~$ kubectl -n rook-ceph get cephcluster/rook-ceph
NAME        DATADIRHOSTPATH   MONCOUNT   AGE     PHASE   MESSAGE                        HEALTH      EXTERNAL
rook-ceph   /var/lib/rook     3          2d17h   Ready   Cluster created successfully   HEALTH_OK

この状態で nginx の Pod を入れ替えることで、正しくボリュームがアタッチされるようになり、nginx が復旧します。

user@k8s-master:~$ kubectl rollout restart deploy/nginx-deployment
deployment.apps/nginx-deployment restarted
user@k8s-master:~$ kubectl get pods -l app=nginx
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6c649bd7cb-hpvq2   1/1     Running   0          68s
nginx-deployment-6c649bd7cb-hrzlk   1/1     Running   0          66s

確認

nginx が正常に動作していることを確認します。

user@k8s-master:~$ curl $(kubectl get svc/nginx -o jsonpath='{.spec.externalIPs[]}')
<a>ICTSC2022</a>

魔王様が作成された求人ページにページを差し替え、正しくそれが配信されることを確認します。

user@k8s-master:~$ kubectl cp /home/user/prob/index.html  $(kubectl get pod -l "app=nginx" -o jsonpath='{.items[0].metadata.name}'):/usr/share/nginx/html/index.html
user@k8s-master:~$ curl $(kubectl get svc/nginx -o jsonpath='{.spec.externalIPs[]}')
<!DOCTYPE html>
<html lang="ja">

<head>
    <meta charset="UTF-8">
    <title>ICTSC2023 求人</title>
</head>

<body>
    <h2>運営スタッフ大募集！！！</h2>
    <h1>ICTSCはあなたの参加を待っています！</h1>

    <p>※ICTSC2023が必ず開催されるわけではございません。</br>
        運営不足やその他の原因によって開催しない可能性がございます。</br>
        また、運営方法や待遇などが変更される可能性がございます。
    </p>

    <h3>運営のやること</h3>
    <ul>
        <li>全員やること</li>
        <ul>
            <li>問題アイデアをだす</li>
            <li>問題作成</li>
            <li>ほかの人の問題レビュー</li>
        </ul>
        <li>希望者ができること</li>
        <ul>
            <li>問題インフラの作成 参考：</br>
                <a
                    href="https://blog.icttoracon.net/2021/04/26/ictsc2020-%e3%82%a4%e3%83%b3%e3%83%95%e3%83%a9%e8%a7%a3%e8%aa%ac-%e3%83%8d%e3%83%83%e3%83%88%e3%83%af%e3%83%bc%e3%82%af%e7%b7%a8/">ICTSC2020
                    インフラ（2022は物理機材はありませんでした)</a>

            </li>

            <li>問題掲示をおこなうスコアサーバーの開発：</br>
                <a href="https://github.com/ictsc/ictsc-rikka"> スコアサーバー バックエンド</a>、
                <a href="https://github.com/ictsc/ictsc-sachiko-v3"> スコアサーバー フロントエンド</a>
            </li>
            <li>監視基盤やスコアサーバーをのせるk8s基盤の開発 参考： </br>
                <a
                    href="https://blog.icttoracon.net/2021/04/25/ictsc2020-k8s%e9%81%8b%e7%94%a8%e8%a7%a3%e8%aa%ac-%e5%89%8d%e7%b7%a8%ef%bc%9a%e6%a7%8b%e7%af%89%e3%81%a8%e6%a7%8b%e6%88%90/">ICTSC2020
                    k8s運用 前編</a>、
                <a
                    href="https://blog.icttoracon.net/2021/04/25/ictsc2020-k8s%e9%81%8b%e7%94%a8%e8%a7%a3%e8%aa%ac-%e5%be%8c%e7%b7%a8%ef%bc%9a%e9%81%8b%e7%94%a8%e7%b7%a8/">ICTSC2020
                    k8s運用 後編</a>

            </li>

        </ul>
    </ul>

    <h3>2022での待遇</h3>
    <ul>
        <li>給与等なし</li>
        <li>開催場所への交通費提供</li>
        <li>開催場所での宿泊場所提供</li>
    </ul>

    <h3>参考: ICTSC2022開催までの流れ</h3>

    11月ごろキックオフ</br>
    ↓</br>
    年末までに問題アイデア</br>
    ↓</br>
    二月末まで 問題作成</br>
    ↓</br>
    二月末~三月初め ホットステージ</br>
    （開催場所に集まって問題作成やインフラ構築)</br>
    </br></br></br>

<h3>応募などは閉会式で</h3>

</body>

</html>

魔王様が作成されたこのような素晴らしい求人ページが正しく配信されるようになったことを喜ばしく思います。これで希望者が続出するに違いありません（なにしろ魔王の元で働けるのですから）。 確認のほどよろしくお願いいたします。

Raw
ictsc-cya-1677900647.md

お世話になっております。チーム word-unknown-tsukuba-otaku です。

原因

この問題では下の二つの原因でトラブルが発生していました。

  1. Fluentd の out_s3 で virtual hosted style が使われており、エラーメッセージにもあるとおり test.192.168.19.2 という無効なホスト名へのアクセスが行われていた
  2. Fluentd のプロセスのユーザー td-agent が /var/log/nginx/access.log にアクセスする権限がなかった

解決方法

そのため、次のように設定を変更し、minioへのログの転送が正しく動くことを確認しました。

  1. Fluentd の out_s3 で path style を使うようにします。これは、1で示されているように /etc/td-agent/td-agent.conf で force_path_style true を設定することで達成します。
  2. td-agent ユーザーが /var/log/nginx/access.log にアクセスできるようにします。/var/log/nginx/access.log は adm グループが所有しており、グループによる r が可能になっているため、td-agent ユーザーを adm グループに所属させることで解決します。これは sudo usermod -aG adm td-agent コマンドで達成します。

確認

まず、:80 の nginx にリクエストを飛ばします。

user@vm1:~$ curl localhost
...

/var/log/td-agent/td-agent.logにエラーが出ていないことが確認できます。

user@vm1:~$ tail /var/log/td-agent/td-agent.log
2023-03-04 12:14:09 +0900 [info]: spawn command to main:  cmdline=["/opt/td-agent/bin/ruby", "-Eascii-8bit:ascii-8bit", "/opt/td-agent/bin/fluentd", "--log", "/var/log/td-agent/td-agent.log", "--daemon", "/var/run/td-agent/td-agent.pid", "--under-supervisor"]
2023-03-04 12:14:09 +0900 [info]: init supervisor logger path=nil rotate_age=nil rotate_size=nil
2023-03-04 12:14:10 +0900 [info]: #0 init worker0 logger path=nil rotate_age=nil rotate_size=nil
2023-03-04 12:14:10 +0900 [info]: adding match pattern="nginx.**" type="s3"
2023-03-04 12:14:10 +0900 [warn]: #0 'force_path_style' parameter is deprecated: S3 will drop path style API in 2020: See https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/
2023-03-04 12:14:10 +0900 [warn]: #0 The default value of s3_object_key_format will use ${chunk_id} instead of %{index} to avoid object conflict in v2
2023-03-04 12:14:10 +0900 [info]: adding source type="tail"
2023-03-04 12:14:10 +0900 [info]: #0 starting fluentd worker pid=9823 ppid=9820 worker=0
2023-03-04 12:14:10 +0900 [info]: #0 following tail of /var/log/nginx/access.log
2023-03-04 12:14:10 +0900 [info]: #0 fluentd worker is now running worker=0

サーバーに mc コマンドをインストールしており、下のようにオブジェクトの一覧から正しく今日のアクセスの分のログが転送されていることが確認できます。

user@vm1:~$ ~/minio-binaries/mc ls vm2/test/logs/2023/03/
[2023-03-01 03:36:37 JST]   129B STANDARD 01_0.gz
[2023-03-01 03:37:43 JST]   127B STANDARD 01_1.gz
[2023-03-01 03:41:29 JST]   162B STANDARD 01_2.gz
[2023-03-01 03:45:13 JST]   168B STANDARD 01_3.gz
[2023-03-04 12:15:10 JST]   185B STANDARD 04_0.gz

以上、確認のほどよろしくお願いします。

Footnotes

  1. https://docs.fluentd.org/how-to-guides/apache-to-minio ↩

Raw
ictsc-lwg-1677898206.md

お世話になっております。チーム word-unknown-tsukuba-otaku です。 この問題では bash のワンライナーのみで多様なAAをターミナルに表示することが求められました。 下のコマンドで指定された画像と同じ結果が描画されることを確認いたしましたので、確認のほどよろしくお願いします。

1.

figlet(6) を用いて指定されたようなブロック状の AA を生成することができます。これを求められた色のブロックに sed(1) で置換し、最後に paste(1) で結合することで求められた出力を得ることができます。色のブロックは背景色を指定したスペースで実現しました。

function show() { figlet -f block $1 | sed -e "s/_|/$(tput setab $2; echo -n '  '; tput sgr0)/g" -e '1d' | head -n -2; }; paste -d '' <(show I 1) <(show C 6) <(show T 4) <(show S 3) <(show C 2)

2.

figlet(6) による AA 表示を 0.2 秒ごとに行いつつ、tput clear で端末画面をクリアすることでアニメーションを行うことができます。文字列のシフトは bash のパラメータ置換の機能を用いて実現しました。

declare -i c=0; str="Welcome to ICTSC! "; l=${#str}; while :; do s=$(( c % l )); tput clear; figlet -tf big "${str:s:l-s}${str:0:s}"; c=c+1; sleep 0.2; done

なお、競技環境では sleep(1) に浮動小数点数を指定することが可能ですので、直接 0.2 秒を sleep(1) に指定しています。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment