(1)Imperative (命令型)
(2)Declarative (宣言型)

Dockerコマンド
Dockerコマンドは、個々のコンテナを管理するために使用されます。アプリケーションやサービスが単一のコンテナで完結している場合や、手動で複数のコンテナを連携させる場合に適しています。
Docker Compose
Docker Composeコマンドは、複数のコンテナを一度に定義、起動、管理するために使用されます

(2)はdocker-compose的。(1)と違ってコマンドぽちぽち一杯しなくてOK

どんなオブジェクトを作るのか
どのように作られるのか
他のどのオブジェクトと関連しているのか

をyamlファイルに書いて、ターミナルに戻って『どのyamlファイルの内容をclusterを作るために適用するのか？』という意味のコマンドを打ちます

kubectl apply -f config.yaml

Kumamoto-Hamachi

k8sのyamlファイルの基礎の基礎

apiVersion
どのバージョンか？
(https://kubernetes.io/ja/docs/concepts/workloads/controllers/deployment/ で一応確認)
kind
どのオブジェクトを作成したいのか
metadata
オブジェクトを一意に特定するための情報
kubectl create deployment <deployment名>で指定したdeployment名の部分
spec
~~オブジェクトの望ましい状態~~
=>yamlファイルで設定されるオブジェクトの詳細について書く！

Kumamoto-Hamachi

Deploymentオブジェクト 1

赤で囲まれている部分がdeploymentオブジェクトに関する事
オレンジで囲まれている部分がpodに関する事

Deploymentオブジェクトはpodに関する事(いくつpodを用意するかなど)をマネージする役割(？)

Kumamoto-Hamachi

Deploymentオブジェクト 2

specの下のpod側情報

replica

デフォルトは1
Deploymentオブジェクトを作る時、いくつのpodで始めるか
※スケーリングした数とかではなく初期値(？)

kind

kind:podだが、これは省略してOK。

template

Podに関しての情報。
labels:でpod名を書く。

※Deploymentオブジェクトのmetadata@だとname:`に当たる部分

spec

『Podの』specification(スペック)。
前提としてPodはContainerを囲んでいるwrapperのようなもの
なので、containerに関する情報を書く。(nameとかimageとか)

selector

どのDeploymentがどのpodと結びついているのかを明示する。
下記のようにpodのlabelsに書いたキーバリューペアーを書く。

selector:
  matchLables:
    app: first-app

全部書けたらkubectl apply -f=<ファイル名.yaml>で適用

Kumamoto-Hamachi

Deploymentオブジェクトの知識整理

apiVersion、kind、metadata(name:{オブジェクトを一意に指定する名前})
Deploymentオブジェクトとpodの関係
podとコンテナの関係
オブジェクトの詳細(spec)
- replica
- selector(matchlabels)
- template
  - metadata(labels)
- spec(containers)

Kumamoto-Hamachi

Serviceオブジェクト TODO

Kumamoto-Hamachi

ConfigMapオブジェクト

$ kubectl create configmap params-test --from-file=params.txt
configmap/params-test created

$ kubectl get configmap
NAME          DATA   AGE
params-test   1      19s

apiVersion: v1
data:
  params.txt: |-
    name hoge
    age 1
    country piyo
kind: ConfigMap
metadata:
  creationTimestamp: "2020-03-09T04:17:50Z"
  name: params-test
  namespace: test

TODO：namespace

Kumamoto-Hamachi

メモ yamlファイルの読み方 by chatgpt

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Kubernetes（k8s）では、ラベルを用いて、オブジェクト（ここではPods）を選択し、管理することが一般的です。このYAMLファイルでは、Deploymentとそれに紐づくPodを作成する指示が書かれています。各セクションにあるlabelsフィールドについて解説します。

1. メタデータのラベル

metadata:
  name: nginx-deployment
  labels:
    app: nginx

ここでのラベル（app: nginx）は、このDeploymentオブジェクト自体に付与されます。このラベルは、後からオブジェクトを識別しやすくするためや、特定のオブジェクトのグループに対して操作をする際に役立ちます。例えば、クエリで「app=nginxのラベルが付いたDeploymentをすべてリストアップする」などの操作が可能です。

2. セレクターのラベル

spec:
  selector:
    matchLabels:
      app: nginx

selector内のmatchLabelsで指定されたラベル（app: nginx）は、このDeploymentが管理すべきPodをどのように識別するかを指定します。具体的には、templateによって定義されたPodテンプレートをインスタンス化して作成されたPodに、app: nginxというラベルが自動で付与され、Deploymentはこのラベルを持つPodを管理対象とします。

3. テンプレートメタデータのラベル

  template:
    metadata:
      labels:
        app: nginx

ここで指定されているラベル（app: nginx）は、templateに基づいて新しいPodが作成されたとき、そのPodに付与されます。このラベルは2.で指定したセレクターに一致するため、DeploymentによってそのPodが管理下に置かれます。このラベルは、Podを識別するものであり、サービスやネットワークポリシー等といった他のKubernetesオブジェクトがPodを見つけるためのキーともなります。

要約すると、このyamlファイルに記述されているラベルは以下の役割を持っています：

Deployment自体を識別するため
Deploymentが管理すべきPodを選択・識別するため
作成されるPodを識別し、他のリソースと関連づけるため

それぞれのラベルがKubernetesの中でどのような役割を果たすかを理解することは、リソースを効果的に管理する上で非常に重要です。

Kumamoto-Hamachi

コマンドメモ

yamlファイル変更した時のお話

$ kubectl diff -f ./hoge.yaml

$ kubectl apply -f ./hoge.yaml

pod一覧のLiveの状態を表示

$ kubectl get -n {ネームスペース} po -w

yamlファイル変更の反映後にrollout(podの入れ替え)したい

$ kubectl rollout restart -n {ネームスペース} {kind？：例deploy}/{Deploymentオブジェクトのmetadataのname}

複数コンテナのpodで特定のコンテナにコマンドを実行させる

$ kubectl exec -it {pod名} -n {ネームスペース} -c {コンテナ：例nginx} -- {実行コマンド：例nginx -V}

Kumamoto-Hamachi

helmfile is 何？

HelmはKubernetesのパッケージマネージャ。

Kubernetesクラスタ上で動くアプリケーションリソースのかたまりをChartとしてパッケージ化している
ChartパッケージがHelmリポジトリ上に公開されており、自由に取得できる (Linuxにおけるyum、macOSにおけるhomebrewのように例えられることが多いですね)
取得したChartの設定値を自身の環境に合わせて変え、簡単にデプロイすることができる