[学習メモ]Certified Kubernetes Administrator（CKA）に向けて〜随時更新〜

## 背景

業務でKubernetesを扱い初めて一年ほどになるので、自信を付けたくてCertified Kubernetes Administrator（CKA）を取ることにしました。

## 対象としている人

Certified Kubernetes Administrator（CKA）を目指している人

Kubernetes初学者

# それぞれのコンポーネントについて

ここではそれぞれのコンポーネントについて説明していきます。

## ETCDについて

バージョンによってコマンドが違うのは歴史的な背景を知る必要がある。

### 役割

クラスターに加えられた全ての変更は、etcdサーバーに変更される

etcdに更新された時点で初めて変更が完了したことになる。

## Kube-apiserver

etcdと唯一やり取りをするコンポーネント
### 役割
SchedulerやKubeletなどとetcdの仲介役
これらのコンポーネントはKube-apiserverを通じて、それぞれの領域でクラスタ内の更新を行う
異なるコンポーネントとやり取りするときにSSL/TLS証明書が使われている
## Kube Controller Manager
### 役割
Nodeの状態を常に監視し、異常があれば必要措置を行う。
Kubernetesで使われるControllerとはシステム内の様々なコンポーネントの状態を継続的に監視し、システム全体を望ましい状態にするためのプロセスのことを言う。
RepricaSet, Stateful-set, CronJobなどもKube Controller Managerと呼ばれる一つのプロセスにパッケージ化されている。
## Kubelet
master nodeと唯一やり取りをするコンポーネント
### 役割
masterのschedulerの指示に従いコンテナのコントロールを行う
### プロセス
Kubernetesワーカーノード内のKubeletがノードをKubernetesクラスターに登録する。<br>
ノード上でコンテナやポッドをロードする指示を受けると、Dockerなどのコンテナランタイムエンジンに要求し、必要なImageを引き出してインスタンスを実行する。
## KubeProxy
Kubernetesクラスタの各ノードで実行されるプロセス
### 役割
新しいServiceが生まれるたびに、そのServiceへのトラフィックをバックエンドポッドに転送するための適切なルールを各ノードで作成すること。
ServiceはKubernetesのメモリのみ存在する仮想的なコンポーネント
# Scheduler
podは、`spec.nodeName`で定義されたnodeにスケジュールされる。
Schedulerはこのプロパティが設定されていないpodがあれば、適したnodeを特定し、[Binding](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/binding-v1/)オブジェクトを生成しスケジュールする。
## Labels and Selectors
- Labelはオブジェクトをグループ化するため
- Selectorはオブジェクトをフィルターするため
    - RepricaSetやDeploymentのselectorなど
### annotations
**識別用途でない任意のメタデータをオブジェクトに割り当てるためのフィールド**
annotationはオブジェクトを一意に識別するためのものではない。
Kubernetesでは内部的に使われず、人間が識別するために使われる
## Taints and Tolerations
ノード上でスケジュールできるポッドの制限する
podに特定のnodeに行くように指示するものではなく、nodeに許容範囲のpodのみ受け入れるように設定する
### Taints
Taintsの設定の仕方
```zsh
kubectl traint nodes <node-name> <key>=<value>:<taint-effect>
# NoSchefule
# PreferNoSchedule
# NoExecute
```
Taintsを外したい時
```zsh
kubectl traint nodes <node-name> <key>=<value>:<taint-effect>-
```
### Tolerations
Coming Soon...
### Static Pod
一言で言えば、**initContainerのNode版**
kubelet がアクセスできる場所に配置することで Pod を作成できる。
Kubernetes API Server によって管理されず、kubelet によって直接管理される。
#### メリット
- Node起動時にPodが生成される
- Kubeletによって管理されるために外部に依存しない
    - マスターノードにおいて障害が発生しても、KubeletによってPodが作成されるためクラスタの可用性が高まる
#### ユースケース
- k8sのプラットフォームなどを提供している場合に有効
- Node起動直後にStatic PodによるProxyを構築することで独自ネットワークなどを設定できる
- フルマネージドでないk８sにて、etcdなどのNode起動直後に動作してほしいリソースなどに有効
## Security
### CertificateSigningRequest
証明書署名リクエスト（Certificate Signing Request、CSR）を作成するためのもの
- 証明書署名リクエストとは
    - SSL/TLS証明書を取得するために必要な情報を含んだファイルのこと
    - 証明書の使用目的、ドメイン名、組織名、所在地、および署名者への連絡先などが含まれる
```yaml
# sample manifest
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: <name>
spec:
  groups:
  - system:authenticated
  request: <Paste the base64 encoded value of the CSR file>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
```
#### spec.groups
Kubernetesにおける認証のグループを指定する
- **`system:authenticated`**
    - Kubernetesの認証プロセスによって認証されたすべてのユーザーが含まれるグループ
- **`system:nodes`**:
    - ノードに関する情報にアクセスできるグループ
- **`system:serviceaccounts`**
    - サービスアカウントに関する情報にアクセスできるグループ
- **`system:controllers`**
    - クラスタ内のコントローラに関する情報にアクセスできるグループ
- **`system:authenticated:oauth`**
    - OAuthトークンによって認証されたユーザーが含まれるグループ
- **`system:masters`**
    - クラスタ内のマスターノードにアクセスできるグループ
#### spec.request
証明書署名要求(Certificate Signing Request)をbase64エンコードした値を指定する
#### spec.signerName
**`kubernetes.io/`**で始まる署名者名が指定される
- **`kubernetes.io/kube-apiserver-client`**
    - Kubernetes APIサーバーが発行するクライアント証明書に使用されます。
- **`kubernetes.io/kubelet-serving`**
    - Kubernetes Kubeletサーバーが発行する証明書に使用されます。
- **`kubernetes.io/etcd-serving`**
    - Kubernetes etcdサーバーが発行する証明書に使用されます。
- **`kubernetes.io/legacy-unknown`**
    - Kubernetesが提供する署名者に対して未知の署名者が使用された場合に指定されます。
- **`kubernetes.io/kube-proxy`**
    - Kubernetes kube-proxyが発行する証明書に使用されます。
- **`kubernetes.io/service-account-signing-key`**
    - Kubernetesサービスアカウントが発行するトークン署名キーに使用されます。
#### spec.usages
証明書がどのような目的で使用されるかを指定できる
- **`client auth`**
    - クライアント証明書として使用される。
    - Kubernetesクラスタに対する認証を行う。
- **`server auth`**
    - サーバー証明書として使用される。
    - Kubernetes APIサーバーなどのサーバーに対する認証を行う。
- **`key encipherment`**
    - 鍵暗号化に使用される。
- **`data encipherment`**
    - データ暗号化に使用される。
- **`digital signature`**
    - デジタル署名に使用される。
- **`cert sign`**
    - 証明書署名に使用される。
- **`crl sign`**
    - CRL (Certificate Revocation List) 署名に使用される。
## KubeConfig
クラスター、ユーザー(役割)、名前空間をまとめ、簡単に切り替えることができる
`$HOME/.kube/config`ファイルに定義される
- Clusters: endpointのserver(kube-apiserver, etcdなど)の指定、証明書(certificate authority)の役割
    - Kubernetes Clusterのようなもの
    - ex) Development, Productionなど
- Users: 公開鍵と秘密鍵
    - ロールや権限のこと
    - ex) Admin, Dev User, Prod Userなど
- Contexts: ClusterとUserのがっちゃんこ
    - どのユーザーアカウントでどのクラスタにアクセスするか定義するもの
    - ex)Admin@Production, Dev@Developmentなど
```yaml
apiVersion: v1
kind: Config
clusters:
- name: my-cluster
  cluster:
    certificate-authority: /path/to/ca.crt
    server: https://my-cluster.example.com
users:
- name: my-user
  user:
    client-certificate: /path/to/user.crt
    client-key: /path/to/user.key
contexts:
- name: my-context
  context:
    cluster: my-cluster
    user: my-user
current-context: my-context
```
## To Be Continue...
随時更新していきます。