hitsumabushi845の日記

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

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

半年経ったので2021年の目標をふりかえる

雑記

2021年も半分がすぎたので、https://hitsumabushi845.hatenablog.com/entry/2021/01/02/092252 で掲げた目標について、現状を確認して下半期の動き方を考える。

資格をとる

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

CKAD は先日取得した。学習ログはこのブログに、受検ログは Qiita に投稿した。
考えてみると IT 系の資格を取ったのはこれがはじめてであった。試験自体久しぶりなのでかなり緊張した。

qiita.com

下半期は CKA の取得をはやめに済ませたい。
TOEIC は今年受けるかどうか微妙だなあ。

こまめにブログを書く

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

上半期、Qiita には 9 件の記事を投稿している。 このブログには主に CKAD の学習ログを投稿しており、合算すると月2のペースはクリアできている。

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

Terraform を勉強する

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

これは具体的になにか勉強をしているわけではないが、業務で扱う中でなんとなく雰囲気は掴めた気がする。
ちなみに Terraform では GCP と OCI を主に扱っている。

golang を勉強する

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

これが全然できていない。。 業務で必要にならないとやっぱりモチベーションが上がらないのがよくないところ。 必要になったらやろう（）

というわけで

まあおおむね目標通りに進んでいるように思う。 この調子で下半期もやっていければいいんじゃないでしょうか。

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション8

Kubernetes

引き続き、『Kubernetes Certified Application Developer (CKAD) with Tests』を進めていく。
今回は Section 8: State Persistence。ここまでで試験範囲は終わり。以降は Mock Exam(模試) となる。

Section 8: State Persistence

Volumes

コンテナが生成するデータ（ファイル）を永続化させるため、Pod に Volume をアタッチする。 以下に示すマニフェストでは、ノードの記憶領域をコンテナに /opt としてマウントしている。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - image: alpine
    name: alpine
    command: ["/bin/sh", "-c"]
    args: ["shuf -i 0-100 -n 1 >> /opt/number.out"]
    volumeMounts:
    - mountPath: /opt
      name: data-volume
  volumes:
  - name: data-volume
    hostPath:
      path: /data
      type: Directory

hostPath は特定のノード（Pod の配置されるノード）の記憶領域を利用するが、マルチノードの場合やノードのフェイルオーバーなど、ノードが替わった場合に一貫性が損なわれる。 そのため、通常は後述する Persistent Volume によりクラウドストレージ等を利用して永続化を図る。

volume の種別は他に、emptyDir, downwardAPI, projectedなどがある。 emptyDir は一時的な領域で、Pod が terminate されると削除される。downwardAPI は Pod の情報などをファイルとして保持するためのもの、projected は複数の volume をまとめるもの。

Persistent Volumes

Persistent Volumes(PV) は、ストレージ空間を提供するプールのような役割をしている。 大量の Pod をデプロイする場合に、各マニフェストで逐一 Volume を管理するのではなく、PV によって利用されるストレージを作成・管理し、Pod からは Persistent Volume Claim(PVC) を用いて利用する。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-sample
spec:
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  capacity:
    storage: 1Gi
  hostPath:
    path: /tmp/data

Persistent Volume Claims

先述した PV を Pod から利用するためのリソース。 accessModes や resources に指定した内容に合致する PV が紐付く。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-sample
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

素の k8s では、PV を作って PVC を作って... という流れで利用するが、GKE などではデフォルトでいい感じの StorageClass (kubernetes.io/gce-pd)が設定されており、PVC を作るだけで PV が Dynamic Provisioning される。

Storage Classes, Stateful Sets...

これらは CKAD の範囲ではないそうなので、今はスキップ。

『Kubernetes Certified Application Developer (CKAD) with Tests』記録 - セクション7

Kubernetes

引き続き、『Kubernetes Certified Application Developer (CKAD) with Tests』を進めていく。
今回は Section 7: Services & Networking。

Section 7: Services & Networking

Services

k8s 内で動いている Web アプリケーションに対して、クラスタ外から単に Pod の IP アドレスにアクセスしてもアプリケーションへアクセスできない。
これは、Pod IP は異なるネットワークであり、クラスタ外からは見ることができないものだからだ。

クラスタ外から到達できる IP は基本的にノードの IP となる。そのため、ノードへのアクセスを所望の Pod に配分するリソースが必要となる。
この際作成するサービスは、例えば NodePort サービスが挙げられる。これはノードの特定のポートに来たリクエストと、指定した Pod や Deployment との間のやりとりを仲介するリソース。

ほかに、

  • ClusterIP
    クラスタ内でのみ疎通性のあるロードバランシング/ディスカバリを行うリソース。
  • LoadBalancer
    外部疎通性のある IP を払い出し、ノードに対するロードバランシングを提供するリソース。クラウドプロバイダが提供する LB を作成する。

などがある1。

NodePort Service はクラスタ内に作成された ClusterIP Service に対してノードの特定ポートを利用した外部疎通性を確保しているもので、トラフィックの経路としては Node の特定ポート -> ClusterIP Service -> Target Pod といった流れとなる。
同様に、LoadBalancer Service は NodePort Service に対する外部疎通性を確保するものである。

そのため、NodePort を作成したら内部的には ClusterIP も併せて作成され、LoadBalancer を作成したら NodePort も作成される。
このような ClusterIP <- NodePort <- LoadBalancer といった関係は、Pod <- ReplicaSet <- Deployment や、Job <- CronJob といった親子関係に似ている。

Services - ClusterIP

Deployment によって冗長化された Pod に対して、他の Pod からリクエストを送る場合、内部的なロードバランシングが必要となる。
この場合に利用されるのが ClusterIP Service であり、先述のとおりこれはクラスタ内でのみ利用可能な Service。

Ingress Networking

提供するサービスごとにコンテナを分けるといったマイクロサービス的なデプロイをした場合、サービス全体を外部公開した際にパスベースのルーティングを行いたいケースがある。
NodePort や LoadBalancer はあくまで L4 のロードバランシングを行うため、パスベースルーティングといった L7 のロードバランシングを行うためには、リバースプロキシのようなものが必要になる。

Ingress リソースは L7 のロードバランシングを提供する。
Pod や Service といったリソースのように、マニフェストファイルをもとに L7 ロードバランサを提供することができ、K8s 内で一貫した外部疎通性の確保が可能となる。

Ingress リソースは、デフォルトのクラスタでは提供されていない。多くのマネージド k8s では、クラウドプロバイダが提供する外部の LB と連携した Ingress Controller がデプロイされている。
そうでないクラスタ(オンプレミスのクラスタや Oracle Cloud Infrastructure の k8s などが該当する)では、Nginx controller を利用することとなる。

前者の外部 LB を利用した方法では、外部 LB がそれぞれの NodePort へトラフィックを転送する。
後者の場合は、クラスタ内に Nginx Ingress controller がデプロイされるため、別途 LoadBalancer や NodePort で外部疎通性を確保することとなる。LoadBalancer サービスは Nginx controller へトラフィックを転送し、Nginx controller が各 Pod へトラフィックを転送する。

Network Policies

Pod 間の通信ルールを設定するリソース NetworkPolicy について。
Kubernetes では、NetworkPolicy を設定しない場合は全ての通信が許可される。

NetworkPolicy では、Pod への通信である ingress rule と、Pod からの通信である egress rule を設定できる。 NetworkPolicy を設定した場合、そこで許可されていないトラフィックはすべて拒否される。

マニフェストの例は以下の通り。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Developing network policies

上記マニフェストの各種ルールについて。

  • ipBlock
    指定した CIDR から/へ の通信を許可する。
  • namespaceSelector
    指定した namespace から/へ の通信を許可する。
  • podSelector
    指定した Pod から/へ の通信を許可する。

from/to にリストのアイテムとして指定されたルールは、それぞれが or 条件として処理される。アイテム内に複数のルールを指定した場合は、and 条件として処理される。

  1. ほか、ExternalIP や ExternalName など。↩