1.Kubernetes徹底解説

1.1 アプリケーションのデプロイ方式の進化

• 利点：シンプルで、他の技術を必要としません。

• 欠点：リソースの境界をアプリケーションに定義できないため、計算リソースを適切に割り当てることが難しく、また、プログラム間で影響が生じやすいです。

• 利点：プログラム環境が互いに影響しないため、ある程度のセキュリティを提供します。

• 欠点：オペレーティングシステムの追加により、一部のリソースが無駄になります。

• 各コンテナには、ファイルシステム、CPU、メモリ、プロセススペースなどがあります。

• アプリケーションの実行に必要なリソースはすべて、コンテナにパッケージ化され、基盤と解離されます。

• コンテナ化されたアプリケーションは、クラウドサービスプロバイダー間、Linuxディストリビューション間でデプロイできます。

• 1つのコンテナが故障した場合、即座に別のコンテナを起動して故障したコンテナを置き換える方法は？

• 並行アクセスが増加する場合、コンテナの数をどのようにスケーリングするか

• Swarm：Docker自身のコンテナオーケストレーションツール

• Mesos：Apacheのリソース統合管理ツール。Marathonと組み合わせて使用します。

• Kubernetes：Googleがオープンソース化したコンテナオーケストレーションツール

1.2 Kubernetesの概要

• 自己修復：コンテナがクラッシュした場合、約1秒で新しいコンテナを迅速に起動できる

• 弾力性のあるスケーリング：必要に応じて、クラスター内の実行中のコンテナの数を自動的に調整できる

• サービス発見：サービスは自動的に他のサービスへの依存関係を見つけることができます。

• ロードバランシング：複数のコンテナでサービスを起動した場合、リクエストの負荷分散を自動的に実行できる

• バージョンロールバック：新しいリリースのプログラムバージョンに問題がある場合、即座に元のバージョンに戻ることができる

• ストレージオーケストレーション：コンテナが必要とするストレージボリュームを自動的に作成できます。

1.3 Kubernetesのコンポーネント

• ApiServer：リソースを操作するの唯一のエントリーポイントであり、ユーザーからの入力コマンドを受け取り、認証、認可、APIの登録と検出などのメカニズムを提供します。

• Scheduler：クラスターのリソーススケジューリングを担当し、事前に定義されたスケジューリングポリシーに従ってPodを適切なノードにスケジュールします。言い換えれば、どのコンテナの容器をどの物理サーバーに配置することを管理します。

• ControllerManager：クラスターの状態を維持する役割で、プログラムのデプロイ方式、障害検出、自動拡張、ローリングアップデート(順次更新)などを行います。

• Etcd：クラスター内のさまざまなリソースオブジェクトの情報を保存する役割を担います。

• Kubelet：コンテナの管理者であり、Dockerを操作してコンテナを作成、更新、削除します。

• KubeProxy：クラスター内のサービスの発見と負荷分散を担当します。

• Docker：ノード上でのコンテナの操作を行います。

• まず、Kubernetes環境が起動されると、クラスタの各ノードは自身の情報をetcdデータベースに保存します。

• WordPressサービスのデプロイリクエストは、最初にマスターノードのapiServerコンポーネントに送信されます。

• apiServerは、WordPressサービスをどのノードにデプロイするかを決定するためにschedulerコンポーネントを呼び出します。

• この時、schedulerは各ノードの情報をetcdから読み取り、特定の方法(アルゴリズム)でノードを選択し、結果をapiServerに通知します。

• apiServerはcontroller-managerを呼び出して、WordPressサービスをワーカーノードにデプロイできるように、どうデプロイするのか、いろいろ計画して、調整します。

• kubeletは指示を受け取ると、WordPressのポッドを起動してもらうようにワーカーノードに指示します。

• これで、ポッドはKubernetesの最小単位であり、コンテナはポッド内で実行されます。

• WordPressサービスが起動すると、ポッドはkube-proxyを介してアクセスされます。

• これにより、外部ユーザーはクラスター内のWordPressサービスにアクセスできます。

1.4マスターの基本要素

• Master：クラスターの制御ノードであり、各クラスターには少なくとも1つのマスターノードが必要で、クラスターの制御を担当します。

• ワーカーNode：作業負荷ノードであり、マスターがこれらのノードにコンテナを割り当て、ノードにコンテナのデプロイを担当します。

• Pod：Kubernetesの最小制御単位であり、すべてのコンテナはPod内で実行されます。1つのPodには1つまたは複数のコンテナが含まれます。

• Controller：コントローラーは、Podの管理を行います。Podの起動、停止、数のスケーリングなどがこれに含まれます。

• Service：外部サービスへの統一されたアクセスポイントです。複数のPodを同じ種類のものとして維持します。

• Label：Podを分類するためのラベルです。同じ種類のPodは同じラベルを持ちます。

• NameSpace：Podの実行環境を分離するための名前空間です。(開発環境や本番環境など分けます)

2.kubernetesクラスター環境の構築

2.1 前提知識

2.2 kubeadm デプロイメント方法の簡単紹介

1. マスターノードを作成する：kubeadm init

2. ノードを現在のクラスターに追加する：kubeadm join <マスターノードのIPとポート>

2.3 インストール要件

• 1つ以上のマシン：オペレーティングシステムはCentOS 7.x-86_x64である必要があります。

• ハードウェアの構成：2GB以上のRAM、2つ以上のCPU、30GB以上のハードディスクが必要です。

• クラスター内のすべてのマシンがネットワークで通信できる必要があります。

• 外部ネットワークにアクセスできる必要があります。イメージを取得する必要があります。

• swapパーティションを無効にする必要があります。

• すべてのノードにDockerとkubeadmをインストールします。

• Kubernetesマスターを展開します。

• コンテナーネットワークプラグインを展開します。

• Kubernetesノードを展開し、ノードをKubernetesクラスターに追加します。

• Dashboard Webページを展開し、Kubernetesリソースを可視化して表示します。

3.リソース管理

3.1 リソース管理の概要

• Kubernetesは、基本的にはクラスターシステムであり、クラスター内にさまざまなサービスを展開できます。サービスの展開とは、Kubernetesクラスター内で個々のコンテナを実行し、指定されたプログラムをコンテナ内で実行することです。

• Kubernetesの最小の管理単位はポッドであり、コンテナはポッド内に配置されます。一般的に、Kubernetesはポッドを直接管理せず、ポッドコントローラーを介してポッドを管理します。

• ポッドがサービスを提供すると、ポッドへのアクセス方法を考える必要があります。Kubernetesは、この機能を実現するためにServiceリソースを提供します。

• また、ポッド内のプログラムのデータを永続化する必要がある場合、Kubernetesはさまざまなストレージシステムも提供します。

3.2 YAML言語の紹介

• 大文字と小文字が区別されます。

• インデントを使用して階層関係を表します。

• インデントにはタブを使用せず、スペースのみが許可されます。

• インデントのスペース数は重要ではありません。同じレベルの要素は左揃えされる必要があります。

• '#'はコメントを表します。

• スカラー：単一の、分解できない値

• オブジェクト：キーと値の組み合わせの集まり、マッピング（mapping）/ ハッシュ（hash）/ 辞書（dictionary）とも呼ばれる

• 配列：順序に並んだ値のグループ、シーケンス（sequence）/ リスト（list）とも呼ばれる

• 1.YAMLを書くときは、末尾にスペースを追加することを忘れないでください。

• 2. 複数のYAML構成を1つのファイルに入れる必要がある場合は、---で区切ってください。

• 3. こののサイトは、YAMLが正しく書かれているかどうかを検証するために使用できる、YAMLをJSONに変換するツールです。 https://www.json2yaml.com/convert-yaml-to-json

3.3 リソース管理方法

• 命令によるオブジェクト管理：kubectlコマンドを使って直接Kubernetesリソースを操作します。

• 命令によるオブジェクト設定：kubectlコマンドや設定ファイルを使用してKubernetesリソースを設定します。

• 宣言的なオブジェクト設定：applyコマンドや設定ファイルを使ってKubernetesリソースを設定します。

3.4kubectlコマンド

• command：リソースに対して実行する操作を指定します。例えば、create、get、deleteなどがあります。

• type：リソースの種類を指定します。例えば、deployment、pod、serviceなどがあります。

• name：リソースの名前を指定します。名前は大文字と小文字が区別されます。

• flags：追加のオプションパラメータを指定します。

3.4.1命令式オブジェクト管理

3.4.2命令式オブジェクト設定

3.4.3宣言的オブジェクト設定

• リソースが存在しない場合は、作成されます（kubectl createと同様）。

• リソースが既に存在する場合は、指定された状態に更新されます（kubectl patchと同様）。

1. マスターノードで、kubectlの設定が含まれた.kubeファイルがあることを確認します。

2. ノードノードに.kubeファイルをコピーします。これには、scpやrsyncなどのファイル転送ツールを使用できます。

3. ノードノードでkubectlを実行します。必要に応じて、kubectlの実行権限を確認してください。

📎 参考文章

• 一些引用

• 引用文章