『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回のペースで受講していく。
『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション5, 6
引き続き、『Kubernetes Certified Administrator (CKA) with Practice Tests』を進めていく。 今回は Section 5: Application Lifecycle Management。
Section 5 についてはほぼ CKAD で扱った内容のようなので、Practice Test で確認しつつ軽く進めていく。
Section 5: Application Lifecycle Management
- Rolling Updates and Rollbacks
- Deployment のローリングアップデートについて。
- StrategyType に関してもすこし。RollingUpdate だと maxSurge/minSurge に基づいてアップデートされて、Recreate だと全 Pod を落として再作成。
- Commands and Arguments
- Dockerfile を併せて参照して、commands/args について。
- k run で指定する場合、
--commands
をつけるとspec.containers[].command
に、つけないとspec.containers[].args
に指定される。
- Configure Environment Variables in Applications
- Configuring ConfigMaps in Applications
- 環境変数の設定と ConfigMap からの指定(envFrom)について。
- Configure Secrets in Applications
- secret と secret からの環境変数の指定について。
- Multi-Container Pods
- elastic stack を用いて、Sidecar コンテナから elasticsearch にログを流すサンプル。
- Multi-Container Pods Design Patterns
- これは CKA の範囲じゃないよ!とのこと
- InitContainers
- Init Containers について。
- Self Healing
- ReplicaSets や Deployments はアプリケーションがクラッシュした際などに自己修復する。
- このへんは Liveness probe や Readiness probe で細かく設定できるがこれは CKAD の範囲なので関係ない。
Section 6: Cluster Maintenance
この章から CKA 特有の項目となるので、しっかり進めていく。 本章では、以下の内容を扱う。
- クラスタのアップグレード
- OS のアップグレード
- バックアップとリストア
それぞれ Practice Test とともに学習していく。
- OS Upgrades
- ノードの OS アップグレードのためには、まずノード上の Pod を退避させなければならない。
kubectl drain {node name}
- pod の evict と node を NoSchedule にする
- node のメンテナンス時に使う。
kubectl cordon {node name}
- node を NoSchedule にする(evict はしない)
kubectl uncordon {node name}
- node を NoSchedule からもどす。k drain/k cordon のあとにつかう。
- Kubernetes Software Versions
- kubernetes のバージョンについて。
- 機能は alpha -> beta -> GA となる
- Cluster Upgrade Process
- kubernetes は常に最新の3つのマイナーバージョンがサポートされる。
- アップデートは一足飛びに行わず、積み上げ型で行うことが推奨される。(1.9 から 1.11 に直接上げるのでなく、1.9 -> 1.10 -> 1.11 とアップデートすること)
- アップグレードは master node の更新 -> worker node の更新 といった順序で進む。master node の更新中はクラスタに対する操作はできないが、実行中のリソースは引き続き worker node 上で動作しているため、アプリケーションは利用可能。
- worker node のアップグレード戦略は以下の通り。
- Recreate
- 既存のノードを全消しして作り替える。
- 消えてる間はアプリケーションは利用不可(ダウンタイムが発生する)
- RollingUpdate
- node を一部ずつ更新していく。
- 既存のpodは別のnodeにevictされるのでアプリケーションは利用可能(ダウンタイムが発生しない)
- Recreate に比べ、Node を一部ずつ更新するため時間がかかる。
- Create, Move and Terminate
- まずアップグレード済みのノードを作成し、リソースをそちらに全部移動して既存のnodeを削除する。
- クラウドのようにマシンリソースを手軽に確保出来る場合に行える戦略。
- Recreate
kubeadm upgrade plan
- アップグレードの可否やアップグレード可能なバージョンの確認ができる。
kubeadm upgrade apply vx.xx.x
- controlplane のコンポーネントのアップグレードができる。
- kubelet がある場合、kubelet は更新されないので個別で apt install する必要がある。
kubeadm upgrade node
- 2つめ以降の node のアップグレードを行う。
- ref: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
- Backup and Restore Methods
- 基本的に、全てのリソースはマニフェストによって定義されるため、マニフェストファイルを GitHub などのリポジトリに保管することが推奨される。これが1つのバックアップとなる。
- もし管理されていなかったとしてもクラスタに対して
kubectl get all -A -oyaml > all-resources.yaml
などとすることで取得は可能。
- もし管理されていなかったとしてもクラスタに対して
- ETCD クラスタのバックアップ
- スナップショットの取得:
etcdctl snapshot save /path/to/snapshot.db
- スナップショットからの復元:
etcdctl snapshot restore /path/to/snapshot.db --data-dir /var/lib/etcd-from-backup
- 別の場所にリストアして、etcd の読み込み先を変更する。
- data-dir を変更しているため、
etcd.service
ファイルも修正して、systemctl daemon-reload
する。 - static pod として動いている場合は、
/etc/kubernetes/manifests/etcd.yaml
を修正する。
- スナップショットの取得:
- 基本的に、全てのリソースはマニフェストによって定義されるため、マニフェストファイルを GitHub などのリポジトリに保管することが推奨される。これが1つのバックアップとなる。
この章はこれまでに馴染みのない領域が多いので、後に改めて復習する。
『Kubernetes Certified Administrator (CKA) with Practice Tests』記録 - セクション1~4
というわけで、CKAD を取得したので引き続き CKA の取得へ向けて勉強していく。 CKAD と同様に Mumshad Mannambeth 氏の『Kubernetes Certified Administrator (CKA) with Practice Tests』を利用する。
CKAD を取得したので、今回は CKA 特有の項目について勉強を行い、時間をかけすぎてしまった CKAD よりも短期での取得を目指す。
Section 1: Introduction, Section 2: Core Concepts
これらのセクションはセクション 1 が CKA の説明、セクション 2 は CKAD と同様の内容であるので、今回はスキップ。
Section 3: Scheduling
このセクションでは、スケジューリング、つまり Pod などのリソースをどのノードにデプロイするかといった項目について説明される。 いくらかは CKAD で触れたものなので、"Practice Test を行う -> 分からなかったところがあったら説明の動画に戻る" といったステップで行う。 "分からなかったところ" の判定は "公式ドキュメントで説明されている場所が分からない", "公式ドキュメントを見ても分からない" といった場合に限定する。これは実際の試験で公式ドキュメントを参照できることから。
- nodeName
- もっともプリミティブな指定方法。ノード名を指定することで、そのノードへ Pod をスケジューリングできる。
- Labels and Selectors
- スケジューリングの観点では主に Deployments や ReplicaSets で登場する。
- Taints and Tolerations
- Taints が設定されたノードには、Tolerations が指定されていない場合はスケジューリングされない。
- Node Affinity
- label を用いて、スケジューリングするノードを指定できる
- Resource Requirements and Limits
- cpu や memory の request, limit について。
- アプリケーションが使用するメモリよりも少ない memory limit を指定すると OOMKilled が発生する。
- DaemonSets
- 各ノードに1個 Pod 配置されることが保証されるリソース。
- kube-proxy やオーバレイネットワークを提供する Pod は DaemonSet で提供される。
- ほか、Monitoring プロセスが動く Pod などに使用される。
- Static Pods
- kubelet は単体で Pod を動かすことができる(kubelet が直接管理する Pod)
/etc/kubernetes/manifests
に Pod のマニフェストファイルを配置すると、Pod が作成される。なお、このパスは kubelet の設定(起動時の--pod-manifest-path
または設定ファイルのstaticPodPath
)で変更できる。- kubelet はこのディレクトリを監視していて、ここにマニフェストが配置されれば Pod を動かすし、削除されたら Pod を削除する。
- この static pod は、主に controlplane のコンポーネントを管理するために利用される。controlplane が controlplane 自身に依存しないよう、kubelet が管理するようにする。
- Multiple Schedulers
- k8s のスケジューラは基本的に kube-scheduler が使われるが、複数のスケジューラを共存できる
- kube-scheduler を複数立てることもでき、その名前は
--scheduler-name
で変更できる - 特定のリソースにおいてスケジューラを指定する場合は、
spec.schedulerName
に指定する
Section 4: Logging and Monitoring
このセクションでは、ロギングとモニタリングについて説明される。 クラスタのコンポーネントのロギング・モニタリング、並びにアプリケーションのロギングとモニタリングについて。
- Monitor Cluster Components
- k top コマンドについて。k top コマンドはノードや Pod のリソース利用率を確認できるコマンド。
- 素の k8s では使えず、metrics-server を別途デプロイすることで利用可能となる。
- 各ノードのリソース利用率を確認する場合は
k top node
、各 Pod の場合はk top pod
。
- Managing Application Logs
- k logs コマンドについて。
- 複数のコンテナからなる Pod のログを取る場合は、コンテナの名前を指定する。
セクション4はここまで。かなり短いセクションであった。
次回は Section 5: Application Lifecycle Management に取り組む。 目次を見る感じ結構 CKAD と被っていそうなのでサクッとできるとよい。