hitsumabushi845の日記

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

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

CKA Exam Curriculum v1.21 と Udemy『Kubernetes Certified Administrator (CKA) with Practice Tests』の対応

Kubernetes

www.udemy.com

Udemy 講座『Kubernetes Certified Administrator (CKA) with Practice Tests』を利用していて、講座の構成が現在のカリキュラムに合っていない部分があったので、2021年8月現在利用されているカリキュラム、v1.21 との対応表を作成した。
参照したカリキュラムは以下。

github.com

今現在こちらの Udemy 講座を受講中のため、不足や誤りがあるかもしれないが、その場合は適宜修正する。

カリキュラムのほとんどをカバーできていることが確認できたため、引き続き進めていこう。
なお現在(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)
    • 初めての BURTON 以外の板。
    • カービング中心で滑っているので、カービングに特化した板を、ということで相談した結果こちらとなった。
    • LIMITED とあるように、限定生産らしく7月末までの受注らしい。通常のものよりデザインが好みだったのでこちらにした。価格・機能は通常と変わらない。
  • バインディング: FLUX XF(21-22 Model)
    • これはせっかく板を一新するので、ということでついでに。
  • ブーツ: DEELUXE EMPIRE
    • もともとこれを買いに行ったようなもの。
    • 熱成型のブーツはいいぞ、と聞いていたため、DEELUXE か INTUITION インナーのブーツを買う予定だった。

板に関しては型落ちで安いのがあったら・・・という気持ちで買いに行ったわりに普通に新しく、しかも真剣度合いの高めなアイテムで揃えてしまったため、なんらかの結果を出したくなってきている。
数年以内にバッジテスト1級の取得を目指そうかな。

板はまだ受け取っていないので写真は後日追記する。

ギターを習い始めた

なんだかんだで高校生の頃からギターを（以下略）。
続けてはいるものの、体系的な練習をせずtab譜を見ながら好きな曲を弾いて遊んでいただけだったため、伸び悩んでいた。

バンドを組んでいるわけでもないのでそのままでもよかったのだが、最近周りでギターをはじめる人が増え、彼らの練習する姿を見ていたら上達したいという思いが強くなったので、レッスンに通うこととした。

レッスンは8月から始まる。まずは月2回のペースで受講していく。

*1:と思ったらドイツ語が云々とかスキーだとビンディングだとか云々出てきてめんどくさくなってきた。

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

Kubernetes

引き続き、『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 のアップグレード戦略は以下の通り。
      1. Recreate
        • 既存のノードを全消しして作り替える。
        • 消えてる間はアプリケーションは利用不可（ダウンタイムが発生する）
      2. RollingUpdate
        • node を一部ずつ更新していく。
        • 既存のpodは別のnodeにevictされるのでアプリケーションは利用可能（ダウンタイムが発生しない）
        • Recreate に比べ、Node を一部ずつ更新するため時間がかかる。
      3. Create, Move and Terminate
        • まずアップグレード済みのノードを作成し、リソースをそちらに全部移動して既存のnodeを削除する。
        • クラウドのようにマシンリソースを手軽に確保出来る場合に行える戦略。
    • 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 を修正する。

この章はこれまでに馴染みのない領域が多いので、後に改めて復習する。

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

Kubernetes

qiita.com

というわけで、CKAD を取得したので引き続き CKA の取得へ向けて勉強していく。 CKAD と同様に Mumshad Mannambeth 氏の『Kubernetes Certified Administrator (CKA) with Practice Tests』を利用する。

www.udemy.com

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 と被っていそうなのでサクッとできるとよい。