以下を自分の言葉でまとめる

画像などを以下から引用

https://kubernetes.io/ja/

ebi_yu

歴史

◾️ オンプレサーバ時代

社内に物理サーバを立てる。
後から、リソースの増減/スペックの変更が難しい

◾️ 社内仮想サーバ時代

社内の物理サーバに仮想サーバをたて、必要に応じでスペックの変更を行う。
必要になった時に仮想サーバの立て直しができる。

◾️ IaaS時代

IaaS(AWSなど)が仮想サーバ用の物理サーバも用意してくれるようになった。
より軽量に仮想サーバを動かすため、コンテナが登場(必要なリソースのみを含む仮想OS)。
コンテナを複数運用する機会が増えたことで、複数のコンテナを管理するサービスが必要になった
→ コンテナオーケストレーションの誕生
Kubernetesがコンテナオーケストレーションのデファクトスタンダードになる

ebi_yu

Kubernetesとは

Kubernetes（クーバネティス）は、コンテナ化されたアプリケーションを管理し、自動でデプロイ、スケーリング、運用するためのオープンソースのプラットフォームです。
Kubernetesにおいてコンテナはポッド上で管理され、ノード上で実行される。

ポッドとは

ポッドとはKubenetesで実行可能な最小単位です。
ポッドは一つ以上のコンテナを含むことができ、これらのコンテナはストレージやネットワークリソースを共有しながらクラスター内のノード上で実行されます。

共有リソース

ポッド内のすべてのコンテナは同じIPアドレスとポート番号を共有し、ローカルで互いに通信することができます。これにより、密接に連携する複数のサービスを効率的に運用することが可能です。

一時的なエンティティ

ポッドは一時的なものであり、リプレースやスケーリングが頻繁に行われます。そのため、永続的なデータはポッド内部に保存するのではなく、外部ストレージに保持することが推奨されます。

自動管理

ポッドはKubernetesによって自動的にスケジューリングされ、ノード間で動的に配置されます。また、ポッドが失敗した場合は、Kubernetesが自動的に再起動や再配置を行います。

ノードとは

ノードはポッドを実行する物理的または仮想的なマシンです。
ノードはクラスター内で協調して働き、アプリケーションの実行環境を提供します。
ノードは次のような役割を果たします。

リソース提供

ノードはCPU、メモリ、ストレージなどの計算リソースを提供します。これらのリソースは、クラスター内のコンテナが使用することができます。

スケーラビリティと冗長性

ノードの追加や削除を通じて、クラスターのスケーラビリティと冗長性を向上させることができます。必要に応じてリソースを動的に調整することが可能です。

障害隔離

ノード単位で障害を隔離することができるため、一つのノードに問題が発生しても、クラスター全体の運用には影響を与えにくい構造になっています。]

ebi_yu

リソースとは

Kubernetesにおいて、「リソース」とは、クラスター内で管理される各種オブジェクトのことを指します。これにはポッド、サービス、ボリューム、ノードなどが含まれ、KubernetesのAPIを通じてこれらのリソースが作成、更新、削除されます。
リソースの定義や操作は主にYAML形式で記述されたマニフェストファイルを用いて行われます。

マニフェスト

マニフェストファイルは、リソースの設定を記述するYAMLまたはJSON形式のドキュメントで、Kubernetesクラスターに適用されることでリソースが作成されます。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 80

主要なリソースとその役割

下記から画像を引用

ポッド(Pod)

ポッド(Pod) とはKubernetesの基本実行単位で、一つ以上のコンテナを含むことができます。ポッドはネットワークやストレージリソースを共有し、密に連携するコンテナグループとして機能します。

レプリカセット(ReplicaSet)

レプリカセット(ReplicaSet) とは指定された数のポッドが常に実行されていることを保証するためのリソースです。
これにより、一部のポッドがダウンした場合でも自動的に新しいポッドが作成され、サービスの中断を最小限に抑えることができます。

デプロイメント（Deployment）

デプロイメント（Deployment）は、Kubernetesにおいてポッドの作成、削除、更新を管理するためのリソースです。デプロイメントはレプリカセットを世代管理し、定義された数のポッドレプリカが常に稼働していることを保証します。

サービス（Service）:

サービス（Service）は、動的に変化するポッドのセットに対して一貫したアクセスポイント（IPアドレスとポート番号）を提供します。これにより、ポッドが再起動されたり、スケールアウト/スケールインされたりしても、そのサービスを利用するクライアントや他のサービスは影響を受けずに通信を続けることができます。

イングレス（Ingress）

イングレス（Ingress）はロードバランサとしての機能を提供するリソースです。
イングレスはクラスター外からクラスター内ServiceへのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはイングレスリソース上で定義されるルールによって制御されます。

ebi_yu

kubectlとは

Kubernetes API サーバーと通信するために使用するコマンドラインツール。
podの状態の確認や、pod内のコンテナにアクセスしたりできる。

kubectlコマンドメモ

#現在のコンテキスト
$ kubectl config current-context
#コンテキストの一覧
$ kubectl config get-contexts
 #コンテキストの切り替え
$ kubectl config use-context <context>
#pod一覧取得
$ kubectl get pods -A
#podのコンテナに入る
$ kubectl exec -it -n ${namespace} ${name} -- sh
# コンテナからローカルにファイルコピーの例
$ kubectl cp -n kube-system nginx-ingress-controller-6cddc4f65d-qcgd8:/etc/ingress-controller/ssl/ca-test-cacert-dev.pem ca-test-cacert-dev.pem
# ログを見る。-f でリアルタイムにログを監視。-c でコンテナ指定。
$ kubectl logs -f <pod> -n <namespace> -c <container>
# node の cpu と memory の requests と limits を見る
$ kubectl describe no | grep "Name:\|Resource\|cpu\|memory" | grep -v "cpu:\|memory:\|MemoryPressure" 
# node の cpu と memory のリソース確認
$ kubectl top no
# API リソースを一覧表示（pod や node などの省略形とか色々見れる）
$ kubectl api-resources

# ローカルPCにpodの特定portをポートフォワーディング
$ kubectl port-forward service/test-database-pgpool-postgresql-svc 15432:9999 --namespace=test-database

ebi_yu

 HelmとはKubernetesのリソース(Deployments, Services, Ingress, Secretsなど)を一つの単位として管理するツール。
アプリケーションの設定や依存関係をHelmチャートという形式で定義します。
アプリケーションのデプロイ、アップデート、ロールバックを簡単に実行可能です。

 Helmが生まれた背景コンテナの普及に伴い、Kubernetesはインフラ管理のデファクトスタンダードとなりました。

しかし、Kubernetesは多くのリソースを扱うため、手動管理が難しくなり、それを解決するためにHelmが登場しました。

 Helmの仕組みHelmは、Kubernetes上で複数のリソース（Deployment、Service、Ingressなど）をひとまとめに管理するためのツールで、以下の主要コンポーネントから構成されています。
Helm CLI

ユーザーが利用するコマンドラインツールです。Helmチャートのインストール、更新、削除といった操作を行います。
Helmチャート

Kubernetesリソースをひとまとめにしたテンプレート集です。アプリケーションの構成や設定をYAMLファイルで定義し、リリースとしてデプロイできます。
リリース (Release)

HelmによってデプロイされたKubernetesアプリケーションのインスタンスです。HelmはチャートをもとにKubernetesリソースを生成し、これを「リリース」として管理します。複数のバージョンを保持できるため、過去のバージョンへのロールバックも可能です。

 Helmの全体の動作フロー
https://blog.kubesimplify.com/introduction-to-helm
Helm CLIを使用してチャートを指定し、helm installコマンドを実行。
Helm CLIがチャートのYAMLテンプレートを元にKubernetesリソースを生成。
生成されたリソースがKubernetesクラスタに適用され、リリースとしてデプロイ。
Helmはリリースを管理し、必要に応じてアップグレードやロールバックが可能。
Helmを利用することで、複雑なリソース管理が簡単になり、アプリケーションのバージョン管理や設定変更が迅速に行えます。

 参考https://www.redhat.com/ja/topics/devops/what-is-helm
https://blog.kubesimplify.com/introduction-to-helm
https://qiita.com/thinksphere/items/5f3e918015cf4e63a0bc

ebi_yu

Helmチャートの構造

Helmチャートはディレクトリ構造になっており、アプリケーション構成に必要な情報をYAMLファイルで定義します。

└── - nginx-chart/ : nginxアプリケーションのchartを定義
    ├── - Chart.yaml : チャートのメタデータ (名前、バージョンなど)
    ├── - values.yaml : 設定値を定義 (カスタマイズ可能)
    └── - templates/ : Kubernetesリソースのテンプレート
        └── - deployment.yaml  : Deploymentリソースのテンプレート
            └── - service.yaml : Serviceリソースのテンプレート

Chart.yaml

チャートのメタ情報が記載されています。このファイルで、チャートの名前、バージョン、アプリケーションの概要などを定義します。

name: nginx-chart
version: 1.0.0
description: A Helm chart for deploying nginx on Kubernetes

values.yaml

設定値が定義され、テンプレート内で参照されることで、環境に応じた設定変更が可能になります。

  replicaCount: 2
  image:
    repository: nginx
    tag: "1.19.10"

templates/deployment.yaml

KubernetesのDeploymentリソースを定義するテンプレートです。
values.yaml内の値が参照され、動的に設定が適用されます。

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: {{ .Release.Name }}-nginx
  spec:
    replicas: {{ .Values.replicaCount }}
    selector:
      matchLabels:
        app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
          - name: nginx
            image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
            ports:
              - containerPort: 80

templates/service.yaml

KubernetesのServiceリソースを定義するテンプレートです。

apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Helmのメリット

例1: 開発環境と本番環境の設定の切り替え

アプリケーションのリソース使用量やレプリカ数を環境に応じて変更したい場合、Helmを使えばvalues.yamlで設定を簡単に切り替えられます。

開発環境ではレプリカ数を1、本番環境では10にしたい場合、values.yamlファイルの値をそれぞれ設定するだけで、他の設定を変更せずにデプロイ環境ごとの調整が可能です。

例2: アプリケーションのバージョン管理とロールバック

アプリケーションの新しいバージョンをリリースしたが、不具合が発生した場合、Helmのhelm rollbackコマンドで簡単に前のバージョンに戻すことができます。
これにより、ダウンタイムを最小限に抑え、迅速に問題を解決することが可能です。

# アプリケーションのリリース状況を確認
helm list
# 不具合があった場合、以前のバージョンにロールバック
helm rollback my-release 1

例3: 複数のKubernetesリソースを一度に管理

あるアプリケーションがデプロイメント、サービス、ConfigMap、シークレットなど複数のリソースで構成されている場合、Helmチャートにまとめて管理することで、すべてのリソースを1回のコマンドで操作できます。

新しい環境に同じアプリケーションを導入する際も、helm installコマンド1つで簡単にセットアップが完了します。

例４アプリのアンインストール

例えば、Kubernetesの標準コマンドであるkubectlを使ってアプリケーションを削除する場合、複数のリソース（Deployment、Service、ConfigMapなど）を削除する必要があります。

この場合、リソースを一つひとつ手動で削除するか、削除対象を記載したYAMLファイルを指定して削除しなければなりません。

# YAMLファイルで定義されたリソースを一括で削除
kubectl delete -f myapp.yaml

ただし、この方法ではすべてのリソースが整合性をもって削除される保証はありません。
一部のリソースが削除されずに残る場合もあり、クラスターの状態が不安定になるリスクがあります。

一方、Helmでは以下のように簡単にリリース全体を削除できます。

# Helmリリースをアンインストール
helm uninstall my-release

Helmの利点は、アプリケーションをデプロイした際に作成されたすべてのリソースが、自動的に整合性をもって削除されることです。この機能は、アプリケーションの更新や削除を効率化し、リソースの管理ミスを防ぐうえで非常に有用です。

ebi_yu

以下を自分の言葉でまとめる

歴史

◾️ オンプレサーバ時代

◾️ 社内仮想サーバ時代

◾️ IaaS時代

Kubernetesとは

ポッドとは

共有リソース

一時的なエンティティ

自動管理

ノードとは

リソース提供

スケーラビリティと冗長性

障害隔離

リソースとは

マニフェスト

主要なリソースとその役割

ポッド(Pod)

レプリカセット(ReplicaSet)

デプロイメント（Deployment）

サービス（Service）:

イングレス（Ingress）

kubectlとは

kubectlコマンドメモ

Helmとは

Helmが生まれた背景

Helmの仕組み

Helmの全体の動作フロー

参考

Helmチャートの構造

Chart.yaml

values.yaml

templates/deployment.yaml

templates/service.yaml

Helmのメリット

例1: 開発環境と本番環境の設定の切り替え

例2: アプリケーションのバージョン管理とロールバック

例3: 複数のKubernetesリソースを一度に管理

例４アプリのアンインストール

実際にいろいろ触ってみる