今年買ってよかったもの2021
今年も買ってよかったものをつらつら書いていきます。
おしごと関係
MacBook Pro 16 inch
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 の講座に大変お世話になりました。買ってよかった。
- Kubernetes Certified Application Developer (CKAD) with Tests
- Kubernetes Certified Administrator (CKA) with Practice Tests
- AWS のやつ(これは買ったの今年じゃないかも)
音楽関係
ギターのレッスン
買ったものではないけれども、お金を払ったものとして。
今年からギターを習い始めました。長らく独学で続けてきたけれど、体系的に教わりたいと思い調べたところ徒歩2分の距離にプライベートスタジオでレッスンをやっている講師の方を見つけたので。
独学では好きな曲だけを弾くといったやり方になりがちだけど、レッスンだと基礎練習をしっかりできるのでよい。また弾き方など「これで合ってるんだろうか?」となる部分をレッスンの際に訊くことが出来るのもよい。
主な教本はこれ。つらい。うまくなりたい!
Audient iD22
ギターのレッスンを受けるようになり、改めておうちギター環境を整えようと購入。
周りの音楽やってる人がおすすめしてたので買った。
物理的なダイアルで音量を調整できるのもよいし、ボタンひとつでセンターの音をカットできるのもよい。
入力が2チャンネルあるので、ひとつはギター、もうひとつはマイクにしている。マイクは Web ミーティングで使用するため。
Transcribe! for Mac
ギターの耳コピに活躍するソフト。
指定した範囲のループや速度変化させて再生など、特定のフレーズを集中して練習や耳コピする際に重宝している。
上述した 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
9月は忙しくあまり進められていなかったが、引き続き『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。 今回は Section 13: Troubleshooting と Section 14: Other Topics。トラブルシューティングは試験としても 30 % のボリュームを占める部分なので丁寧に進めていきましょう。
また、これで講座としては終了で、残るは Mock Exam(模擬試験)のみ。
Section 13: Troubleshooting
- Application Failure
- アプリケーションのトラシューは Service と Pod の状態を見ようね
- Service: matchLabel が正しいかとか
- Pod: Pod がクラッシュしてないかとか、k logs で見よう。restart が走ってる場合は k logs -f とか、k logs --previous とかでエラーを確認しよう。
- see also: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application-introspection/
- see also: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application/
- Practice Test - Application Failure
- Webapp Pod, Database Pod 構成における各種トラブルシューティング。
- Webapp 側の接続先設定を直すのか、Database 側を直すのか曖昧な部分がちらほらあって手間取った
- Control Plane Failure
- kubeadm でクラスタを構築した場合、Control Plane のコンポーネントは Pod で動いているので
k get po -n kube-system
で確認できる - service として動いている場合は
service kube-apiserver status
,service kubelet status
など - service のログは
k logs xxx -n kube-system
やsudo journalctl -u xxx
- see also: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-cluster/
- kubeadm でクラスタを構築した場合、Control Plane のコンポーネントは Pod で動いているので
- Practice Test - Control Plane Failure
- kube-scheduler や replicaset controller のトラブルシューティングをした
- 主に static pod のマニフェスト修正
- 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
が誤っているケースについて
- kubelet が停止しているケース、
- Network Troubleshooting
- うーむ、CNI プラグインのインストールって問われるんだろうか
Section 14: Other Topics
これは試験に役立つ Additional なトピックについて。 jsonpath と kubectl のコマンド。
- Pre-Requisites - JSON PATH
- Advanced Kubectl Commands
-o=jsonpath=~~
や-o=custom-columns=COLUMN:JSONPATH
,--sort-by=JSONPATH
などについて。
さあ、残すは模試のみ!
『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション10~12
引き続き、『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
- Choosing Kubernetes Infrastructure
- 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
で指定できる
- Stacked Topology: Master Node 内に ETCD を構築する
- ETCD の HA 構成は2種類ある
- ETCD in HA
- Important Update: Kubernetes the Hard Way
- Hard Way もやるといいよ的な話。
Section 11: Install "Kubernetes the kubeadm way"
- Introduction to Deployment with Kubeadm
- Deploy with Kubeadm - Provision VMs with Vagrant
- Demo - Deployment with Kubeadm
- やってることは以前 Qiita に書いたことと同様だった。
- 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 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
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
- Prerequisite - CoreDNS
- 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
: 起動
- virtual switch を作成する
- Docker コンテナは namespace によってホストから分離されている
- 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
- k8s のノード(master/worker)は1つ以上のネットワークインターフェイスを持ち、同じネットワークに接続されている必要がある
- いくつかのポートが開放されていなければならない
- 6443: kube-apiserver
- 10250: kubelet
- 10251: kube-scheduler
- 10252: kube-controller-manager
- 30000 - 32767: services
- 2379: etcd
- 2380: etcd client(master node/etcd cluster が冗長化されている場合)
- https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#%E5%BF%85%E9%A0%88%E3%83%9D%E3%83%BC%E3%83%88%E3%81%AE%E7%A2%BA%E8%AA%8D
- Practice Test - Explore Kubernetes Environment
- Node の IP アドレス, MAC アドレスの確認
- デフォルトゲートウェイの確認(ip route)
- 各種コンポーネントのポート確認(netstat -natulp | grep xxx)
- 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 を作成する
- 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 アドレスのレコードが登録される
- Pod に対するレコードは、デフォルトでは作成されない
- 登録される場合は、IP アドレスの
.
を-
に変えたものが名称になる(ex:10-244-2-5
,10-244-2-5.default.pod.cluster.local
)
- 登録される場合は、IP アドレスの
- 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 }
長かった。あとすこしで全講座がおわる!
忘れている内容もままありそうなので、Mock Exam や Curriculum をもとに復習していこう。
『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション7
引き続き、『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。 今回は Section 7: Security。扱う内容が多岐にわたり、ボリュームも大きいが、セキュリティ周りのトピックは新設された CKS に移動したため、今の CKA だとほとんど関係ない・・・?
Section 7: Security
- Kubernetes Security Primitives
- 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
- TLS in Kubernetes - Certificate Creation
- 証明書を作る方法について。以下のツールがよく利用される。
- easyrsa
- openssl(この講座ではこちらを利用する)
- cfssl(これは hard way で使ったな)
- 認証局(CA)の作成
- クライアント証明書の作成(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
- Certificates API
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 からできている。
- 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
- 上記は認可をせずに全て許可/拒否をするモード。
- Node Authorization
- 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}]
- ロールは Role リソースで作成する。
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。
現在の試験範囲に含まれないトピックが多かったが、いずれも重要な要素なので勉強する意味はある(と言い聞かせないと困るくらいには時間がかかったセクションであった)。
CKA Exam Curriculum v1.21 と Udemy『Kubernetes Certified Administrator (CKA) with Practice Tests』の対応
Udemy 講座『Kubernetes Certified Administrator (CKA) with Practice Tests』を利用していて、講座の構成が現在のカリキュラムに合っていない部分があったので、2021年8月現在利用されているカリキュラム、v1.21 との対応表を作成した。
参照したカリキュラムは以下。
今現在こちらの Udemy 講座を受講中のため、不足や誤りがあるかもしれないが、その場合は適宜修正する。
- 25% - Cluster Architecture, Installation & Configuration
- Manage RBAC
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296110#overview - Use Kubeadm to install a basic cluster
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/20666292#overview - Manage a HA Kubernetes cluster
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296190#overview - provision underlying infrastructure to deploy a Kubernetes cluster
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296184#overview - Perform version upgrade on a Kubernetes cluster using kubeadm
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296062#overview - Implement etcd backup and restore
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296066#overview
- Manage RBAC
- 15% - Workloads & Scheduling
- Understand deployments and how to perform rolling update & rollback
- Know how to scale applications
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296008#overview - Use ConfigMaps & Secrets to configure applications
ConfigMap: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14412322#overview
Secret: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296016#overview - Understand the primitives used to create robust, self-healing, application deployments
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296030#overview
CKAD のコースを見た方がいいかも。 - Understand how resource limits can affect pod scheduling
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14298678#overview - Awareness of manifest management and templating tools
これは Udemy 講座にはない?kustomize のことを指しているのなら↓。 https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/
- 20% - Services & Networking
- Understand host networking configuration on the cluster nodes
- Understand connectivity between Pods
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296150#overview - Understand ClusterIP, NodePort, LoadBalancer service types and endpoints
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14295512#overview - Know how to use Ingress controllers and Ingress resources
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296170#overview - Know how to configure and use CoreDNS
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296164#overview
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296166#overview - Choose an appropriate CNI
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296152#overview
- 10% - Storage
- Understand storage classes, persistent volumes
StorageClass: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/21795216#overview
PV: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296126#overview - Understand volume mode, access modes and reclaim policies
https://kubernetes.io/ja/docs/concepts/storage/persistent-volumes/#%E3%83%9C%E3%83%AA%E3%83%A5%E3%83%BC%E3%83%A0%E3%83%A2%E3%83%BC%E3%83%89 - Understand PVC primitive
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296130#overview - Know how to configure applications with persistent storage
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296132#overview
- Understand storage classes, persistent volumes
- 30% - Troubleshooting
- Evaluate cluster and node logging
- Understand how to monitor applications
- Manage container stdout & stderr logs
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14295996#overview https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296002#overview - Troubleshoot application failure
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296310#overview - Troubleshoot cluster component failure
ControlPlane: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296312#overview
WorkerNode: https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/14296314#overview - Troubleshoot networking
https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/24452872#overview
カリキュラムのほとんどをカバーできていることが確認できたため、引き続き進めていこう。
なお現在(2021/08/06)は Section 7: Security を進めている。TLS Certificates は今は範囲に含まれないっぽい。
近況(2021/07)
たまには雑記めいたものも書こうと思う。
スノーボードアイテムを一新した
なんだかんだで小学生の頃からスノーボードを続けている。続けているというのは、最低でも年に1回はゲレンデに行っているという意味だ。
続けてはいるものの、5年ほど前から諸事情でウェアやブーツを持っておらず、昨年ようやくウェアを買いそろえた。
板は知人から譲り受けた BURTON の CUSTOM X があったのだが、だいぶ古いものなのでいずれ買い換えようと思っていた。
板とウェアがあり、ブーツだけレンタルするという形を取っていたのだが、これがあまりにも面倒だった。むしろよく昨年・今年と2シーズンもそのような運用を続けたものだ。
というわけで、ブーツ・板・バインディングの3点を一新した。
ところで、"Binding" は個人的にはビンディングと読むタイプなのだが、まあバインディングの方が正しいよなあ*1。
閑話休題。ラインナップは以下の通り。
- 板: OGASAKA CT LIMITED (21-22 Model)
- バインディング: FLUX XF(21-22 Model)
- これはせっかく板を一新するので、ということでついでに。
- ブーツ: DEELUXE EMPIRE
- もともとこれを買いに行ったようなもの。
- 熱成型のブーツはいいぞ、と聞いていたため、DEELUXE か INTUITION インナーのブーツを買う予定だった。
板に関しては型落ちで安いのがあったら・・・という気持ちで買いに行ったわりに普通に新しく、しかも真剣度合いの高めなアイテムで揃えてしまったため、なんらかの結果を出したくなってきている。
数年以内にバッジテスト1級の取得を目指そうかな。
板はまだ受け取っていないので写真は後日追記する。
ギターを習い始めた
なんだかんだで高校生の頃からギターを(以下略)。
続けてはいるものの、体系的な練習をせずtab譜を見ながら好きな曲を弾いて遊んでいただけだったため、伸び悩んでいた。
バンドを組んでいるわけでもないのでそのままでもよかったのだが、最近周りでギターをはじめる人が増え、彼らの練習する姿を見ていたら上達したいという思いが強くなったので、レッスンに通うこととした。
レッスンは8月から始まる。まずは月2回のペースで受講していく。