hitsumabushi845の日記

心理的安全性の保たれた空間に書く適当なメモ

2022年の目標

雑記

2022年、あけましておめでとうございます。新年一発目のブログは今年も2022年の目標を書いていきます。
昨年の目標とその結果については以下の通り。

hitsumabushi845.hatenablog.com

hitsumabushi845.hatenablog.com

では、スタート！

おしごと関連の目標

ここからはおしごと関連の目標を書いていく。

(継続)資格を取る

今年は以下の資格取得を目標とします。上から順に優先順位が高い。

  • Certified Kubernetes Security Specialist
    昨年 CKA/CKAD を取得し、受検資格を得たので。これは3月までには取っておきたい。
  • Google Cloud 認定 Associate Cloud Engineer
    昨年1年間、GCP を触っていたのでとりあえず Associate くらいは取ろうかなーと思っている。Udemy で問題集を購入済み（積んでいる）なので、さほどコストはかからないと思うが果たして。
  • AWS Certified Developer Associate
    昨年 SAA を取得したので、引き続き DVA が取れるといいなぁと思っている。
  • Certified OCI Architect Associate
    昨年 OCI を触っていたのと、3月末まで受検料無料キャンペーンをやっているので。正直これは気が向いたら取るくらいの感じ。

(継続)Go をちゃんとやる

昨年雰囲気程度に書けるようになった Go だが、雰囲気で進めすぎてよくわかっていないままなので、以下の本をベースに勉強していきたい。

www.oreilly.co.jp

趣味関連の目標

ここからはおしごとの関連しない個人的な目標を書いていく。

(新規)JGC 修行をする

昨年はかなり国内線の飛行機に乗った1年だった。おかげさまで JAL 関連の事柄に興味が出たので、JGC(JAL Global Club)入会資格を得るための修行をやろうとおもう。
2022年も引き続き海外には行けない気配があるので、国内を軽率に飛び回るのも最後のチャンスだと思っているし、20代限定の CLUB EST で JAL カードを作れるのもあとわずかなので。

というわけで昨年末に JAL カードを作り、準備万端。JMB ステータスはそこまで興味ないので、春夏あたりで HND-OKA 大量往復をやるつもりでいる。

(新規)英会話をちゃんとやる

英語の読み書きは学生時代の勉強や研究と会社での業務、リスニングは元々好きな洋楽や洋画を見聞きし続けていることである程度伸ばすことができている。一方でスピーキングについては機会がそこまでないので伸び悩んでいる。
先日英語で面談をする機会があり、なんとかコミュニケーションを取ることはできたものの、もう少しスムーズに口から英語を出せるようになっておきたい。

というわけで、今年中には何らかのオンライン英会話サービスに登録すると思います。Cambly とか。

おわりに

ほかにもスノーボードがもっと上手くなりたいとか、ギターがもっと上手くなりたいとか、具体的な到達点が思いつかないものもあるが、とりあえず今年はこの辺を目標に生きていこうと思います。

...その前に目の前のタスクとしてはじめての確定申告を控えているので、これを倒さないと先に進めないなあ。
今年も1年よろしくお願いします。

2021年の目標をふりかえる

雑記

2021年も1年お疲れ様でした。

hitsumabushi845.hatenablog.com

で掲げた目標について、結果を確認していきましょう。

資格をとる

今年受検したいと思っているものは以下の通り。
- CKA or CKAD
- TOEIC

今年は以下の認定資格を取得した。

今年はあまり英語を使う機会がなかったので、TOEIC の受検はとりやめた。 その代わり、業務で AWS を触る機会があったので、SAA を取得した。

おおむね目標通り。考えてみれば IT 系の資格は今年のこれらがはじめての取得。Credly にバッヂが増えていくのは気分がいいので、来年もコンスタントに資格を取っていきたい。

こまめにブログを書く

このブログでは特定の技術に関する話題以外の、技術以外の話やポエムなどを書いていきたいと思っている。
特定の技術要素については、せっかく Organization に属しているので Qiita に書くつもりでいる。 こまめにと言っても、せいぜい月2程度のペースでゆるくやっていきたい。

今年、Qiita には 16 件の記事を投稿した。 このブログには主に CKAD/CKA の学習ログを投稿しており、合算すると月2のペースはクリアできたと思う。

来年もこれくらいのペースで投稿できるとよい。

Terraform を勉強する

2021年から本業・副業ともに Terraform を扱うようなので、ゆるく勉強する。
仕事で使うのでまあ勉強できるだろうと高をくくっている。 特に到達目標はないが、仕事が回る程度に扱えればよいと思う。

中盤でのふりかえりでも述べたが、業務で扱う中でなんとなく雰囲気は掴めた気がする。
ちなみに Terraform を使った業務では GCP と OCI を主に扱っている。OCI は Resource Manager という IaC のサービスがあって、Terraform HCL をそのまま使えるので便利。

golang を勉強する

そろそろ新しい言語を勉強したい。
golang は、複数のプラットフォームに向けてコンパイルできるということで、かねてより興味は持っていたが、
Kubernetes に触れるようになったことでより勉強するモチベーションが上がっている。 とりあえず、Gopher 道場 を進めていこう。

最近は k8s のカスタムコントローラや Admission Webhook を実装しており、そのため Go に入門した感じがある。 しかし完全に雰囲気で進めてしまっているので、来年はもう少し体系的に勉強していきたい。

読みたいと思っている書籍はこれ。

www.oreilly.co.jp

おわりに & 来年へ向けて

今年掲げた目標はおおむね目標通りに推移したように思う。

今年初頭の自分をふりかえってみると、k8s マッタクワカランだったところから今は CKA/CKAD も取得して、CR や Admission Webhook もなんとなく実装できるようになった。
AWS/GCP/OCI についてもそれぞれ雰囲気程度には扱えるようになり、昨年までのオンプレおじさんから一転クラウドおじさんになった気がする。

というわけで、来年も引き続き勉強を続けていきたい。来年はもう少し本を読むようにしたいなぁ。 2022年の目標はまたお正月に書きましょう。

今年買ってよかったもの2021

雑記

今年も買ってよかったものをつらつら書いていきます。

おしごと関係

MacBook Pro 16 inch

www.apple.com

MacBook Pro をようやく買い換えました。
今まで使っていたやつは 5 年前に買った Late 2016 モデルで、あの悪名高い TouchBar が初めて搭載されたモデルです。今回ついに TouchBar が完全に廃止と相成りました。
TouchBar が廃止になったから買い換えたわけではなく、5年使ってもういい加減限界を迎えてきたので。Terraform が正常に動かないとか、カメラが急に死ぬとか、バッテリーが一瞬でなくなるとか、いろいろ問題を抱えてたわけです。

カスタマイズ内容としては RAM を 32 GB にして、ストレージを 1 TB にしました。それに Apple Care をつけるだけであっさり 40 万円になってしまうのはどういうことなんですかね。

前評判通り Apple Silicon はバッテリーの持ちが良く、ちょっと出かける程度であれば電源ケーブルを持ち歩かなくてよくなった。また発熱も少なく、バッテリー電源でゴリゴリ作業してても熱くならないのは良い。

めがね

今年はめがね沼につま先程度突っ込んだ年でした。
きっかけは春先にふらっと鯖江に行ったことで、そこの田中眼鏡 というお店でのめがね購入体験がよかった。

ここはいわゆるよくあるめがね屋さんと違って、店頭にはフレームがそこまで並んでいません。
ではどうやってめがねを選ぶのかというと、ハリーポッターのオリバンダーの店よろしく店主がフレームを見繕ってくれるのであった。お店の方に欲しいめがねの方向性を伝えると棚からどんどんフレームを出してくれます。

そこで買っためがねは下の2本。このときはせっかく鯖江に来たのでということで、珍しめのフレームが欲しいという条件で見繕ってもらった。

こうして、それまでコンタクトレンズ派だったぼくはこれをきっかけにめがね派になるのであった。

その後、その田中眼鏡さんで教えてもらった吉祥寺の opteria-Glassias でまためがねを購入した。 opteria-Glassias さんは検眼に力を入れているお店ということで、1時間以上かけて最適なレンズを決めてくれるとのことであった。 そのためここでは仕事用(PC 用)のめがねを買うこととした。

そうして買っためがねがこれ。

このめがねは 25% 緑色をいれたカラーレンズになっていて、傍から見るとほぼサングラスなのだが、これがディスプレイの光量を抑えてくれて目が楽。他にもプリズムが入っていたりと、とにかく作業していて目が疲れないようになっている。今となってはこのめがね無しで PC の画面をみるのはつらい。

PC 用めがねということで矯正視力が 0.8 程度と抑えめになっているが、屋内であればこのめがねで支障はないので自宅用めがねとして利用している。

各種 Udemy 講座

今年は資格を3つ取得できました。それぞれ CKAD, CKA, AWS SAA ですが、どれも Udemy の講座に大変お世話になりました。買ってよかった。

音楽関係

ギターのレッスン

買ったものではないけれども、お金を払ったものとして。
今年からギターを習い始めました。長らく独学で続けてきたけれど、体系的に教わりたいと思い調べたところ徒歩2分の距離にプライベートスタジオでレッスンをやっている講師の方を見つけたので。

独学では好きな曲だけを弾くといったやり方になりがちだけど、レッスンだと基礎練習をしっかりできるのでよい。また弾き方など「これで合ってるんだろうか？」となる部分をレッスンの際に訊くことが出来るのもよい。

主な教本はこれ。つらい。うまくなりたい！

www.rittor-music.co.jp

Audient iD22

allaccess.co.jp

ギターのレッスンを受けるようになり、改めておうちギター環境を整えようと購入。
周りの音楽やってる人がおすすめしてたので買った。

物理的なダイアルで音量を調整できるのもよいし、ボタンひとつでセンターの音をカットできるのもよい。
入力が2チャンネルあるので、ひとつはギター、もうひとつはマイクにしている。マイクは Web ミーティングで使用するため。

Transcribe! for Mac

www.seventhstring.com

ギターの耳コピに活躍するソフト。
指定した範囲のループや速度変化させて再生など、特定のフレーズを集中して練習や耳コピする際に重宝している。

上述した iD22 のセンターカットと組み合わせると耳コピがはかどる。

BIAS FX 2

昨年 Amplitube を買ったのだが、どうも周りを見ていると最近は BIAS を利用している人が多いらしいので。これは iD22 を買ったときに得たサウンドハウスのポイントで買ったのでほぼ無料。

プリセットがダウンロードできたり、Guitar Match で別のギターの音をエミュレートできたり、楽しい。 豊富な機能を全然使いこなせてないが、まあ人気のプリセットをダウンロードして弾くだけでも十分楽しめている。

スノーボード関連

これはまだ実際に使ってないので、別記事として後日（来年？）書く。

そのほか

Anker PowerCore Fusion 10000

Anker PowerCore Fusion 10000www.ankerjapan.com

出かけるときのモバイルバッテリー兼自宅用充電器。普段はベッドサイドの充電器として使用していて、出かけるときは引っこ抜いてそのままカバンに放り込むだけでいいのでとても楽。

普通のモバイルバッテリーだと充電を忘れたりするが、充電器兼用なので充電を忘れることがない。

『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション13・14

Kubernetes

9月は忙しくあまり進められていなかったが、引き続き『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。 今回は Section 13: Troubleshooting と Section 14: Other Topics。トラブルシューティングは試験としても 30 % のボリュームを占める部分なので丁寧に進めていきましょう。

また、これで講座としては終了で、残るは Mock Exam(模擬試験)のみ。

Section 13: Troubleshooting

  • Application Failure
  • Practice Test - Application Failure
    • Webapp Pod, Database Pod 構成における各種トラブルシューティング。
    • Webapp 側の接続先設定を直すのか、Database 側を直すのか曖昧な部分がちらほらあって手間取った
  • Control Plane Failure
  • Practice Test - Control Plane Failure
  • Worker Node Failure
    • k get nodes で status が NotReady なノードがあった場合
    • k describe node node-name で確認
    • ノード側のリソース使用率の確認: top コマンドや df コマンドで
    • kubelet の確認: service kubelet status や sudo journalctl -u kubelet
    • 証明書の確認: openssl x509 -in /var/lib/kubelet/xxx.crt -text で Issuer や有効期限を見る
  • Practice Test - Worker Node Failure
    • kubelet が停止しているケース、/var/lib/kubelet/config.yaml が誤っているケース、etc/kubernetes/kubelet.conf が誤っているケースについて
  • Network Troubleshooting
    • うーむ、CNI プラグインのインストールって問われるんだろうか

Section 14: Other Topics

これは試験に役立つ Additional なトピックについて。 jsonpath と kubectl のコマンド。

  • Pre-Requisites - JSON PATH
    • YAML, JSON PATH のトレーニングと、-ojson 時の出力を元にした所望のフィールドにアクセスする方法について。
  • Advanced Kubectl Commands
    • -o=jsonpath=~~ や -o=custom-columns=COLUMN:JSONPATH, --sort-by=JSONPATH などについて。

さあ、残すは模試のみ!

『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション10~12

Kubernetes

引き続き、『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。
今回は Section 10: Design and Install a Kubernetes Cluster と Section 11: Install "Kubernetes the kubeadm way"。

Section 10: Design and Install a Kubernetes Cluster

  • Design a Kubernetes Cluster
    • どういうクラスタを作るのか
    • 目的: 勉強用？開発用？本番用？
      • 勉強用なら minikube とか、小さめのクラスタをクラウドで作るとか
      • 開発用なら 1-Master, n-Worker
      • 本番用だと HA 構成がいるよね（multi-master nodeとか）
    • プラットフォーム: クラウド？オンプレ？
      • オンプレなら kubeadm
      • GCP なら GKE, AWS なら Kops, Azure なら AKS
    • ワークロード: どれくらいの規模のアプリケーションが動くのか？アプリケーションの内容は？CPU, メモリの利用は？トラフィックは？
  • Choosing Kubernetes Infrastructure
    • クラスタをどこにホストするか
    • 手元のマシンなら minikube とか、kubeadm とか
    • プライベートなサーバにセットアップするなら、OpenShift, VMware Cloud PKS, Vagrant とかで
    • クラウド使うなら GKE, AKS, EKS とか
  • Configure High Availability
    • Control plane が 1 台のみで構成されていると、そのマシンが壊れたときに困るので、HA 構成を取ろう
    • HA 構成の Control plane では、複数の Master Node がそれぞれ同じコンポーネントを持つ
    • API Server もそれぞれに居るため、API call を振り分けるため前段に LB を配置することが望ましい（nginx, HA proxy, etc...など）
    • Controller Manager, Scheduler も同様だが、こちらは各 Node で走っていると意図しない Pod の作成などが行われてしまうので、1 つだけ Active にし、他は Standby にする。
      • これは leader-election process によって制御される
      • kube-controller-manager/kube-scheduler の引数に --leader-elect true を指定すると、kube-controller-manager Endpoint のリース取得有無でリーダーが選出される
      • --leader-elect-lease-duration duration: リース期間
      • --leader-elect-renew-deadline duration: リース更新にかかる時間の最大値
      • --leader-elect-retry-period duration: リーダーシップの獲得を試みる間隔
      • https://speakerdeck.com/daikurosawa/leader-election-in-kubernetes-number-k8sjp
    • ETCD
      • ETCD の HA 構成は2種類ある
        • Stacked Topology: Master Node 内に ETCD を構築する
          • pros: Node が少なくすむ、管理が楽
          • cons: Node のトラブル時に etcd も影響を受ける
        • External ETCD Topology: 異なるノードに ETCD を分離して、独立に構築する
          • pros: リスクを低減する
          • cons: セットアップがつらい、Node が増える
          • kube-apiserver が見に行く etcd のエンドポイントは --etcd-servers で指定できる
  • ETCD in HA
    • ETCD について
      • 分散型KVS
      • 分散
        • クラスタ構成をとれる
        • いかなるノードへのR/Wでもクラスタ全体での一貫性が保たれる
        • leader election が行われており、Write は常に leader から全ノードに対して行われる
      • leader election - RAFT
        • etcd のリーダー選出は RAFT というアルゴリズムで行われている
        • 最初に各ノードはランダムタイマーをもっていて、最初にタイマーが終わったノードが他のノードにリーダー選出をリクエストする
        • あとは投票みたいな感じでリーダーが選ばれる
      • 書き込まれているデータは過半数優先（過半数に記録されているデータが正）
        • "過半数" なので、クラスタは3-nodes以上で構成することが望ましい（2-nodes以下だとノードが落ちたら終了する）
        • さらに 奇数-nodes が望ましい（クラスタが分断されたときにどこかは必ず生きる）
    • etcdctl
      • etcdctl put <key> <name>
      • etcdctl get <key>
  • Important Update: Kubernetes the Hard Way
    • Hard Way もやるといいよ的な話。

Section 11: Install "Kubernetes the kubeadm way"

  • Introduction to Deployment with Kubeadm
    • kubeadm での k8s クラスタ構築の概観
    • ステップ
      1. セットアップ対象のマシン/VMを用意する
      2. マシン/VM にコンテナランタイムをインストールする
      3. マシン/VM に kubeadm をインストールする
      4. Master Node を作成する
      5. Pod Network を作成する
      6. Worker Node をクラスタに参加させる
  • Deploy with Kubeadm - Provision VMs with Vagrant
  • Demo - Deployment with Kubeadm
  • Practice Test - Deploy a Kubernetes Cluster using Kubeadm
    • 手順としては以前やった通りだが、1.22 での挙動でちょっと詰まったり、Practice Test 用の環境が 1.22 に即してなかったりでいろいろ詰まった。
    • このへんの Cgroup Driver のミスマッチなど。

Section 12: End to End Tests on a Kubernetes Cluster

この範囲は CKA の範囲から外されたので講座はなし。

『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション8・9

Kubernetes

引き続き、『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。
今回は Section 8: Storage と Section 9: Networking。Storage は CKAD と同内容だと思うので、サクッと行う。

Section 8: Storage

  • Practice Test: PV & PVC
    • "Configure a volume~" という設問で、PV作るのか単にVolumeを作るのかわからず困惑したりした。
  • Storage Class
    • おっとこいつは CKAD のときはスキップしていたのだった。
    • 主に Dynamic Provisioning を利用するために使われる。Dynamic Provisioning とは、PVC を作成したときに動的に PV を作成するもの。特にクラウドなど、自由にストレージを用意できる環境で利用され、各種クラウドプロバイダ向けの provisioner が用意されている。
    • クラウドストレージはそのストレージタイプやレプリケーションの有無など、様々なタイプのストレージを構成できるため、これらを Storage Class として管理することで所望の仕様のストレージを簡便に用意できる。

Section 9: Networking

このセクションが最もボリュームが大きい。

  • Prerequisite - Switching Routing
    • スイッチとルータについて。
    • スイッチは同一ネットワーク内の通信、ルータは異なるネットワーク間の通信を担う。
    • ip link: ネットワークインターフェースの設定の確認・変更を行う
    • ip addr add x.x.x.x/x dev yyy: ネットワークインターフェースにIPアドレスを追加する
    • ip route add x.x.x.x/x via y.y.y.y: ルーティングテーブルにルートを追加する
    • 複数のネットワークインターフェースを持つホストをルータとして使用する場合、接続される端末はそのホストをゲートウェイとして設定すれば良いが、ホスト側でネットワークインターフェース間のフォワーディングを許可しなければならない。
      • /proc/sys/net/ipv4/ip_forward に 0 が設定されている場合はフォワーディングが許可されていない。1 にすると許可される。
      • この値は再起動でリセットされるため、/etc/sysctl.conf の net.ipv4.ip_forward にも同様に設定が必要。
    • ip コマンドで変更された設定も永続化するためには /etc/network/interfaces に記載が必要。
  • Prerequisite - DNS
    • DNS について。
    • /etc/hosts ファイルに名前とIPを書いたら名前解決されるけど、管理する端末が多くなったらメンテナンスできなくなるので、DNS を構成したほうがいい。
    • DNS サーバの設定は /etc/resolv.conf ファイルに行う。
    • DNS レコード
    • ping, nslookup, dig コマンド
  • Prerequisite - CoreDNS
    • Linux ホストを DNS サーバとして構成するためのもの（のひとつ）
    • 実行可能バイナリとしても、Docker コンテナとしても構成できる
    • CoreDNS は Corefile ファイルから構成を読み取る。例えば、ここに hosts /etc/hosts と書くとホストの /etc/hosts ファイルから DNS を構成できる。
  • Prerequisite - Network Namespaces
    • Docker コンテナは namespace によってホストから分離されている
      • コンテナ内からコンテナ外（ホスト）のプロセスは見えない
    • 同様に、ホストのネットワークインターフェイスは見えないので、コンテナにはバーチャルインターフェースを割り当てる
    • ip netns add <name>: ネットワークネームスペースを作る
    • ip netns exec <namespace> <command>: ネームスペース内でコマンドを実行
      • ip -n <namespace> <command> も同様
    • namespace は作るだけでは箱を切るだけなので、インターフェースなども存在しない
    • ns 間の直接接続は virtual cable(pipe) で行える
      • ip link add <veth-a> type veth peer name <veth-b>: インターフェースの作成
      • ip link set <veth-a> netns <namespace-a>: ネームスペースへの割り当て
      • ip link set <veth-b> netns <namespace-b>
      • ip -n <namespace-a> addr add x.x.x.x dev <veth-a>: IP アドレスの設定
      • ip -n <namespace-b> addr add y.y.y.y dev <veth-b>
      • ip -n <namespace-a> link set <veth-a> up: インターフェースの起動
      • ip -n <namespace-b> link set <veth-b> up
      • ip netns exec <namespace-a> ping y.y.y.y とかで確認
    • 2ネットワーク（namespace）間であればよいが、複数nsあった場合は？
      • virtual switch を作成する
        • linux bridge や open vswitch など
      • linux bridge
        • ip link add <v-net-n> type bridge: ブリッジの作成
        • ip link set dev <v-net-n> up: ブリッジの起動
        • ip link add <veth-a> type veth peer name <veth-a-bridge>: インターフェースの作成
        • ip link set <veth-a> netns red: インターフェースの割り当て
        • ip link set <veth-a-bridge> master <v-net-n>: ブリッジへの接続
        • ip -n <namespace-a> addr add x.x.x.x dev <veth-a>: IPアドレスの割り当て
        • ip -n <namespace-a> link set <veth-a> up: 起動
  • Prerequisite - Docker Networking
    • docker run --network none <image>: None network(ネットワークインターフェースをアタッチしない)
    • docker run --network host <image>: ホストのネットワークを利用する（ネットワーク的に独立しない）
    • docker run <image>: コンテナ毎にIPアドレスが払い出され、バーチャルブリッジが作成されてネットワークとして独立する（デフォルト）
    • docker network ls: でネットワークモードを確認できる。ip link するとバーチャルブリッジが見える
      • ip link でもみえる
    • コンテナが作成されるとネームスペースが作成され、ブリッジと接続される
    • ポートマッピング
      • ホスト外からコンテナが公開するポートにアクセスできない
      • docker run -p 8080:80 nginx といった形で、ホストのポートとコンテナのポートをマッピングすることでアクセスできる
  • Prerequisite - CNI
    • ここまで確認してきた、ネームスペースの作成、ブリッジの作成、virtual cable の作成・割り当て、IPアドレスの割り当て...といったプロセスは、Docker も行うが他のネットワークソリューションも同様に行う。
    • コンテナが作成された時のネットワーク接続性の確保や、コンテナが削除された時のリソース開放を担うインターフェース: CNI(Container Network Interface)
    • CNI を実装しているランタイム: rkt, kubernetes, Mesos,...
    • 3rd party プラグイン: Calico, Weave, Cilium,...
    • Docker は CNI を実装していない（CNMという別のもの）
    • k8s が Docker コンテナを立ち上げるときは、Docker 自体は --network=none で起動し、別途 CNI プラグインがネットワークの構成を担っている
  • Cluster Networking
  • Practice Test - Explore Kubernetes Environment
  • Pod Networking
    • Pod 間の通信をどうするか。複数のワーカーノードに分かれて配置される Pod は、それぞれがノードを跨いで通信できなければならない。
    • これも同様に、仮想ネットワーク同士をルートテーブルでつなげることで、仮想的なもう一段大きいネットワークを構成する
  • CNI in Kubernetes
    • k8s では、kubelet が CNI plugin を呼び出す
    • kubelet の --network-plugin, --cni-bin-dir, --cni-conf-dir で指定される
      • ps -aux | grep kubelet で確認できる
  • CNI weave
    • weave ってやつがあるやで〜程度の説明
  • Practice Test - Explore CNI Weave
    • kubelet の引数を見たりして、CNI を確認する
  • Practice Test - Deploy Network Solution
    • Weave のデプロイをする
  • IP Address Management - Weave
    • Pod に払い出す IP をどう管理するか。重複しないように払い出す必要がある
    • CNI Plugin の責務
    • CNI 組み込みの管理手法: DHCP or host-local
    • CNI の設定ファイル、ipam セクションで設定される
    • weave はデフォルトでは 10.32.0.0/12 のレンジの IP アドレスを払い出す
{
  //略
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/16",
    "routes": [
      { "dst": "0.0.0.0/0" }
    ]
  }
}
  • Service Networking
    • Service は cluster-wide に作成され、いかなるノードに作成された Pod も Service を介して Pod にアクセスできる
    • Pod では、namespace や interface を作成して IP アドレスを割り当てていたが、Service の場合はそうではなく、namespace, interface は作成されない。あくまで仮想的なもの。
    • Service が作成されると、規定の IP レンジから IP が払い出され、kube-proxy が forwarding rule を作成する
      • つまり、Service とは各ノードの kube-proxy がトラフィックを振り分ける仕組み
      • 規定の IP レンジは kube-api-server の --service-cluster-ip-range で指定されている（デフォルト: 10.0.0.0/24）
    • kube-proxy の振り分け方法は3種類: userspace, iptables(default), ipvs
    • iptables -L -t nat | grep <service-name>: iptables から service を確認
    • NodePort Service では、全ノードで同じポートからの外部アクセスを受け付ける
  • DNS in Kubernetes
    • クラスタ内のリソース(Pod や Service など)への名前解決
    • kubernetes クラスタには DNS が含まれていて、名前解決が行える
    • Service が作成されると、Service 名とその IP アドレスのレコードが登録される
      • 同一 namespace であれば、この Service には Service 名だけで名前解決が可能
      • 異なる namespace の場合は、<service name>.<namespace> で名前解決できる
      • 全ての Service は .svc サブドメイン配下に登録されるため、<service name>.<namespace>.svc でも指定でき、同様に全てのリソースは cluster.local 配下に登録されるため、<service name>.<namespace>.svc.cluster.local も有効(FQDN)
    • Pod に対するレコードは、デフォルトでは作成されない
      • 登録される場合は、IP アドレスの . を - に変えたものが名称になる(ex: 10-244-2-5, 10-244-2-5.default.pod.cluster.local)
  • CoreDNS in Kubernetes
    • kubernetes が DNS をどう実装しているか
    • v1.12 以前では kube-dns、v1.13 以降では CoreDNS が基本
    • CoreDNS は ReplicaSet として kube-system にデプロイされる
    • CoreDNS は /etc/Corefile で設定され、ConfigMap として挿入される
    • 様々なプラグインを利用でき、kubernetes plugin もある
      • pods insecure: pod の DNS レコードを作成する
    • CoreDNS が構築されると、この Pod に接続するための Service も作成され、これが Node の resolv.conf に nameserver として設定される
      • resolv.conf への設定は kubelet が行い、config.yaml の clusterDNS に設定する
.:53 {
  errors
  health
  kubernetes cluster.locacl in-addr.arpa ip6.arpa {
    pods insecure
    upstream
    fallthrough in-addr.arpa ip6.arpa
  }
  proxy . /etc/resolv.conf
  cache 30
  reload
}
  • Ingress
    • これは CKAD でやったのと同じなので Practice Test だけやって終わり
    • Ingress が GA になり微妙に API が変わっていることだけ注意しよう
      • まあ k create ingress で作ってしまっても良い
  • Ingress - Annotations and rewrite-target

長かった。あとすこしで全講座がおわる！
忘れている内容もままありそうなので、Mock Exam や Curriculum をもとに復習していこう。

『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション7

Kubernetes

引き続き、『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。 今回は Section 7: Security。扱う内容が多岐にわたり、ボリュームも大きいが、セキュリティ周りのトピックは新設された CKS に移動したため、今の CKA だとほとんど関係ない・・・？

Section 7: Security

  • Kubernetes Security Primitives
    • k8s のセキュリティの概観について。
    • ノード（ホストするマシン）はパスワード認証でなく 鍵認証であるべき
    • Authentication
      • ID/Password
      • ID/Token
      • 証明書
      • LDAP
      • Service Accounts
    • Authorization
      • RBAC
      • ABAC
      • Node
      • Webhook
    • コンポーネント間の通信は TLS 化されている
    • Network Policies
  • Authentication
    • クラスタにアクセスする人: クラスタ管理者、開発者、プログラム（bot）、エンドユーザー、etc...
    • クラスタ管理者と開発者はUser
      • kube-apiserver は API を処理する前に認証を行っている
      • 認証はパスワードファイル、トークンファイル、証明書、3rd party IDaaS
      • パスワードファイル
        • 非推奨
        • csv ファイルで管理されている
        • {password},{username},{user id},{group(optional)} 形式で記載されたファイルを kube-apiserver に読ませる
        • kube-apiserver の引数に --basic-auth-file=/path/to/users.csv と指定する
        • curl -v -k https://master-node:6443/api/v1/pods -u "user1:password123"
      • トークンファイル
        • 非推奨
        • パスワードファイルとほぼ同じ。
        • {token},{username},{user id},{group(optional)} 形式
        • --token-auth-file に指定する。
        • curl -v -k https://master-node:6443/api/v1/pods -H "Authorization: Bearer xxxx"
    • Bot user は ServiceAccount
  • TLS
    • TLS Basics
    • TLS in Kubernetes
      • k8s におけるホスト間の通信、ユーザーとkube-apiserver間の通信、そしてコンポーネント同士の通信は暗号化されている
      • これらはサーバ証明書とクライアント証明書によって成り立っている
        • kube-apiserver, etcd cluster, kubelet はサーバ証明書を持っている
        • kubectl を実行するユーザや、kube-apiserver と通信する kube-scheduler, kube-controller-manager, kube-proxy はクライアント証明書を持っている
          • kube-apiserver は etcd cluster, kubelet から見たときにクライアントなので、クライアント証明書も持つ（サーバ証明書と同一になることもある）
      • これらの証明書を発行するための認証局、ルート証明書も必要となる。
    • TLS in Kubernetes - Certificate Creation
      • 証明書を作る方法について。以下のツールがよく利用される。
        • easyrsa
        • openssl(この講座ではこちらを利用する)
        • cfssl(これは hard way で使ったな)
      • 認証局(CA)の作成
        • 認証局の秘密鍵を作成: openssl genrsa -out ca.key 2048
        • 証明書署名要求(CSR)を作成: openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
        • 証明書の発行: openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
      • クライアント証明書の作成(ex. Admin User)
        • 秘密鍵: openssl genrsa -out admin.key 2048
        • CSR: openssl req -new -key admin.key -subj "/CN=kube-admin/O=system:masters" -out admin.csr
        • 発行: openssl x509 -in admin.csr -CA ca.crt -CAkey ca.key -out admin.crt
        • CN(コモンネーム) がユーザーとして扱われ、O(組織) がグループとして扱われる。
          • 各種コンポーネントのクライアント証明書においては、CN, O は指定の値にする必要がある。
          • kubelet の場合は system:node:{nodeName}, kube-controller-manager の場合は system:kube-controller-manager...といった形に。
    • View Certificate Details
      • 証明書の場所は kubeadm で構築したクラスタの場合は static pod のマニフェストに引数として書いてある
      • *.crt ファイルの確認: openssl x509 -in /path/to/certificate.crt -text -noout
      • ログの確認
        • service log: journalctl -u xxx.service -l
        • pod log: kubectl logs xxx
        • kube-apiserver/etcd cluster が落ちている場合は Docker のログを直接: docker logs xxx
  • Certificates API
    • ユーザーのクライアント証明書を作成するためのAPIが備わっている
    • クライアント証明書を作成したいユーザは秘密鍵とCSRを作成し、CSR から CertificateSigningRequest リソースを作成する。
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: foo
spec:
  groups:
  - system:authenticated
  usages:
  - digital signature
  - key encipherment
  - server auth
  request:
    {base64 encoded csr}
  signerName: kubernetes.io/kube-apiserver-client
  • KubeConfig
    • クラスタに対してAPIを実行するとき、APIエンドポイントの情報やクライアント証明書の情報が必要となる。curl で叩くときはこれらを指定しているが、kubectl から API を実行するときは kubeconfig ファイルを利用する。
    • デフォルトでは kubectl ~/.kube/config を見に行く。
      • $KUBECONFIG を指定することで $HOME/.kube/config 以外の kubeconfig を読み取り先にできる
    • kubeconfig は Clusters, Users, Contexts からできている。
      • Clusters: クラスタのAPIエンドポイント、CA証明書の情報を持つ
      • Users: ユーザとクライアント証明書の情報を持つ
      • Contexts: Cluster と User の組み合わせ
      • kubectl が利用するコンテキストは current-context フィールドに指定される。
    • kubeconfig の確認: kubectl config view
    • current-context の変更: kubectl config use-context {context name}
  • API Groups
    • kubernetes API はいくつかのグループに分かれている
  • Authorization
    • クラスタの利用者（管理者、開発者、Botユーザー...）ごとに権限を適切に分けたい
    • 認可方式(Authorization Mode)は以下がある
      • Node Authorization
        • kubelet は Node 上のリソースを管理（どのリソースを作るか、あるリソースがどのような状態か）するため、kube-apiserver にアクセスする。
        • これらの操作は Node Authorizer によって処理される
        • kubelet に指定した証明書では、グループを system:nodes, 名称を system:node:xxx とした。これらの名称を持つユーザは Node Authorizer で認可される。
      • ABAC(Attribute Based Access Control)
        • ABAC では、JSON 形式のポリシーファイルを作成し、許可される操作をユーザ毎に定義する。
        • これはユーザが追加される毎にこのファイルを編集し、かつ kube-apiserver の再起動が必要となる。
        • 不便なので、RBAC を使う。
      • RBAC(Role Based Access Control)
        • RBAC では、ロールを定義し、ユーザにロールを割り当てる。
        • ロールではどの操作が許可されているか定義されている。
      • Webhook
        • 認可を外部に任せる場合は、こちらを利用する。
      • AlwaysAllow
      • AlwaysDeny
        • 上記は認可をせずに全て許可/拒否をするモード。
    • Authorization Mode は、kube-apiserver の引数(--authorization-mode)に指定する。
      • デフォルトは AlwaysAllow
      • カンマ区切りで複数指定することもでき、複数指定した場合は指定した順番に認可が処理される。
  • RBAC
    • ロールは Role リソースで作成する。 yaml
      • resourceName フィールドでさらに認可するリソースの名称で絞ることが可能
    • ユーザをロールに紐付けるには、RoleBinding リソースを作成する。
    • Role は namespace-wide なリソースであるため、Role が作成された namespace 内のリソースにのみ認可される。cluster-wide に認可するためには ClusterRole/ClusterRoleBinding を使用する。
    • 自分があるリソースに対する操作が可能か確認するコマンド: kubectl auth can-i {verb} {resource} [--as {user name}]
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
  resources: ["ConfigMap"]
  verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devuser-binding
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io
  • Cluster Roles and Cluster Role Bindings
    • Pod, Deployment, Job, Service, Secret, PVC... は namespace-wide。Node, PV, CSR, Namespace, そして ClusterRole, ClusterRoleBinding は cluster-wide なリソース。
    • 各リソースのスコープを確認したい場合は、kubectl api-resources --namespaced=true/false で。
    • Cluster Admin や Storage Admin のロールを作る場合は ClusterRole を作成する。
  • Images Securely
    • Pod の実行に使用される Docker イメージについて。
    • image: nginx と指定された場合、docker.io/nginx/nginx から取得される。レジストリのエンドポイントやユーザ名を明示的に指定することで異なるレジストリから取得できる。
    • プライベートレジストリの場合、ログインが必要となる。認証情報は Secret で持つことができ、kubectl create secret docker-registry xxx --docker-server=private-registry.io --docker-username=foo --docker-password=bar --docker-email=foobar@example.com といった形で作成する。
    • これを Pod の imagePullSecrets セクションに指定することで認証を行える。
  • Security Contexts
    • これは CKAD のときもやった。
    • runAsUser と capabilities について。
  • Network Policies
    • これも CKAD のときにやった。

以上、Section 7: Security。
現在の試験範囲に含まれないトピックが多かったが、いずれも重要な要素なので勉強する意味はある（と言い聞かせないと困るくらいには時間がかかったセクションであった）。