Kubernetes Basics
Kubernetes Basics
このページの元の著者は Jorge です(元の投稿は こちら)
アーキテクチャと基本
Kubernetesの役割
コンテナをコンテナエンジンで実行できるようにします。
スケジュールによりコンテナを効率的にミッションできます。
コンテナを生かし続けます。
コンテナ間の通信を可能にします。
デプロイメント技術を可能にします。
大量の情報を処理します。
アーキテクチャ
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-68.jpg&width=768&dpr=4&quality=100&sign=4902871c&sv=1)
ノード: ポッドまたはポッドを持つオペレーティングシステム。
ポッド: 1つのアプリケーションのみを含むべきであるラッパーであるコンテナまたは複数のコンテナ。通常、1つのポッドは1つのコンテナを実行します。ポッドは、Kubernetesが実行しているコンテナ技術を抽象化する方法です。
サービス: 各ポッドは、ノードの内部範囲から1つの内部IPアドレスを持ちます。ただし、サービスを介して公開することもできます。サービスにはIPアドレスもあり、その目的はポッド間の通信を維持することです。したがって、1つがダウンした場合、新しい置換品(異なる内部IPを持つ)は、サービスの同じIPでアクセス可能に公開されます。内部または外部として構成できます。サービスは、2つのポッドが同じサービスに接続されている場合、ロードバランサーとして機能します。 サービスが作成されると、各サービスのエンドポイントを見つけることができます。
kubectl get endpoints
を実行して実行中の各サービスのエンドポイントを見つけることができます。Kubelet: プライマリノードエージェント。ノードとkubectlの間の通信を確立するコンポーネントであり、ポッドのみを実行できます(APIサーバーを介して)。kubeletは、Kubernetesによって作成されていないコンテナを管理しません。
Kube-proxy: apiserverとノード間の通信(サービス)を担当するサービスです。ベースはノード用のIPtablesです。経験豊富なユーザーは、他のベンダーからの他のkube-proxyをインストールすることができます。
サイドカーコンテナ: サイドカーコンテナは、ポッド内のメインコンテナと一緒に実行する必要があるコンテナです。このサイドカーパターンは、現在のコンテナの機能を拡張および強化しますが、それらを変更しません。現在、アプリケーションがどこでも実行されるようにするために、コンテナ技術を使用してすべての依存関係をラップすることを知っています。コンテナは1つのことだけを行い、そのことを非常によく行います。
マスタープロセス:
APIサーバー: ユーザーとポッドがマスタープロセスと通信する方法です。認証されたリクエストのみが許可されるべきです。
スケジューラ: スケジューリングは、Kubeletがそれらを実行できるように、Podがノードに一致するようにすることを指します。どのノードにより多くの利用可能リソースがあるかを判断し、新しいポッドをそのノードに割り当てるための十分な知能を持っています。スケジューラは新しいポッドを開始するのではなく、新しいポッドを起動するノード内で実行されているKubeletプロセスと通信します。
Kube Controller Manager: レプリカセットやデプロイメントなどのリソースをチェックして、例えば、正しい数のポッドやノードが実行されているかどうかを確認します。ポッドが不足している場合、新しいポッドを起動するためにスケジューラと通信します。APIへのレプリケーション、トークン、およびアカウントサービスを制御します。
etcd: データストレージ、永続的で一貫性があり、分散されています。Kubernetesのデータベースであり、クラスターの完全な状態を保持するキー値ストレージです(各変更はここに記録されます)。スケジューラやコントローラーマネージャーなどのコンポーネントは、変更が発生したことを知るためにこのデータに依存します(ノードの利用可能なリソース、実行中のポッドの数など)。
Cloud Controller Manager: AWSやOpenStackなどのクラスターがある場合、フロー制御とアプリケーションのための特定のコントローラーです。
複数のノード(複数のポッドを実行しているノード)があるため、複数のマスタープロセスがあり、それらのApiサーバーへのアクセスが負荷分散され、それらのetcdが同期されていることに注意してください。
ボリューム:
ポッドが消えても失われてはならないデータを作成する場合、物理ボリュームにデータを保存する必要があります。Kubernetesはポッドにボリュームをアタッチしてデータを永続化することを可能にします。ボリュームはローカルマシンまたはリモートストレージにあることができます。異なる物理ノードでポッドを実行している場合は、すべてのポッドがアクセスできるようにリモートストレージを使用する必要があります。
その他の構成:
ConfigMap: サービスにアクセスするためのURLを構成できます。ポッドはここからデータを取得して、他のサービス(ポッド)との通信方法を知ることができます。これは資格情報を保存するための推奨されない場所であることに注意してください!
Secret: これは、パスワード、APIキーなどの秘密データを保存する場所です。B64でエンコードされています。ポッドは必要な資格情報を使用するためにこのデータにアクセスできます。
Deployments: Kubernetesによって実行されるコンポーネントが指定される場所です。通常、ユーザーは直接ポッドと作業しません。ポッドはReplicaSets(複製された同じポッドの数)で抽象化され、デプロイメントを介して実行されます。デプロイメントはステートレスアプリケーション向けです。デプロイメントの最小構成は、名前と実行するイメージです。
StatefulSet: このコンポーネントは、同じストレージにアクセスする必要があるデータベースなどのアプリケーション向けに特に作成されています。
Ingress: これは、URLでアプリケーションを公開する構成です。外部サービスを使用しても同様のことができますが、これがアプリケーションを公開する正しい方法です。
Ingressを実装する場合は、Ingress Controllersを作成する必要があります。Ingress Controllerは、リクエストを受信し、チェックしてサービスにロードバランスするポッドです。Ingress Controllerは、構成されたIngressルールに基づいてリクエストを送信します。Ingressルールは、異なるパスやさらには異なる内部Kubernetesサービスへのサブドメインを指すことができます。
より良いセキュリティ慣行は、Kubernetesクラスターの一部を公開しないように、クラウドロードバランサーやプロキシサーバーをエントリーポイントとして使用することです。
Ingressルールに一致しないリクエストが受信された場合、Ingress Controllerは「デフォルトバックエンド」にそれをリダイレクトします。このパラメータのアドレスを取得するには、Ingress Controllerを
describe
できます。minikube addons enable ingress
PKIインフラストラクチャ - 証明書機関CA:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-66.jpg&width=768&dpr=4&quality=100&sign=ddfcd3be&sv=1)
CAはクラスタ内のすべての証明書の信頼されるルートです。
コンポーネントがお互いを検証できるようにします。
すべてのクラスタ証明書はCAによって署名されています。
ETCdには独自の証明書があります。
タイプ:
apiserver証明書。
kubelet証明書。
scheduler証明書。
基本的なアクション
Minikube
Minikubeは、完全なkubernetes環境を展開する必要なしに、kubernetesでいくつかのクイックテストを実行するために使用できます。マスターとノードプロセスを1つのマシンで実行します。Minikubeは、ノードを実行するためにvirtualboxを使用します。こちらでインストール方法を確認してください。
Kubectlの基本
**Kubectl
**は、kubernetesクラスター用のコマンドラインツールです。これは、kubernetesのアクションを実行したりデータを要求するために、マスタープロセスのApiサーバーと通信します。
Minikube ダッシュボード
このダッシュボードを使用すると、Minikube が実行している内容をより簡単に確認できます。アクセスするための URL は以下で見つけることができます:
YAML構成ファイルの例
各構成ファイルには3つの部分があります: metadata、specification (起動する必要があるもの)、status (望ましい状態)。 デプロイメント構成ファイルの仕様の中で、実行するイメージを定義する新しい構成構造で定義されたテンプレートが見つかります:
同じ構成ファイルで宣言されたDeployment + Serviceの例 (from here)
サービスは通常、1つのデプロイメントに関連しているため、同じ構成ファイルで両方を宣言することが可能です (この構成で宣言されたサービスは内部からのみアクセス可能です):
外部サービス構成の例
このサービスは外部からアクセス可能になります(nodePort
とtype: LoadBalancer
属性を確認してください):
これはテストには便利ですが、本番用には内部サービスのみと、アプリケーションを公開するためのIngressが必要です。
Ingress構成ファイルの例
これにより、アプリケーションが http://dashboard.com
で公開されます。
シークレット構成ファイルの例
パスワードがB64でエンコードされている点に注意してください(これは安全ではありません!)
ConfigMap の例
ConfigMap は、ポッドに与えられる構成であり、他のサービスの場所を特定しアクセスする方法を知っています。この場合、各ポッドは、mongodb-service
という名前が、通信できるポッドのアドレスであることを知っています(このポッドは mongodb を実行しています):
その後、デプロイメント構成内で、このアドレスを以下のように指定することで、ポッドの環境変数内に読み込まれるようになります:
ボリューム構成の例
https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes に、異なるストレージ構成のYAMLファイルの例があります。 ボリュームはネームスペース内に存在しないことに注意してください
ネームスペース
Kubernetesは、同じ物理クラスターでバックアップされた複数の仮想クラスターをサポートしています。これらの仮想クラスターはネームスペースと呼ばれます。これらは、多くのユーザーが複数のチームやプロジェクトにまたがって分散している環境で使用することを意図しています。数人から数十人のユーザーがいるクラスターでは、ネームスペースを作成したり考えたりする必要はありません。Kubernetesにデプロイされたアプリケーションの各部分をよりよく制御し、整理するためにネームスペースを使用するべきです。
ネームスペースは名前のスコープを提供します。リソースの名前はネームスペース内で一意である必要がありますが、ネームスペース間では一意である必要はありません。ネームスペースは互いに入れ子にすることはできず、各Kubernetesリソースは1つのネームスペースにのみ存在できます。
minikubeを使用している場合、デフォルトで4つのネームスペースがあります。
kube-system: ユーザーが使用するためではなく、触れてはいけないものです。マスターとkubectlプロセス用です。
kube-public: 公開されているデータ。クラスタ情報を含むconfigmapが含まれています。
kube-node-lease: ノードの可用性を決定します。
default: ユーザーがリソースを作成するために使用する名前空間
ほとんどのKubernetesリソース(例:ポッド、サービス、レプリケーションコントローラなど)はいくつかの名前空間にあります。ただし、名前空間リソースやノード、永続ボリュームなどの低レベルリソースなど、他のリソースは名前空間にありません。どのKubernetesリソースが名前空間にあるかどうかを確認するには、次の手順を実行します:
そのコンテキストでのすべての後続のkubectlコマンドのために、名前空間を保存できます。
Helm
HelmはKubernetesのパッケージマネージャです。これにより、YAMLファイルをパッケージ化して、それらを公開およびプライベートリポジトリで配布することができます。これらのパッケージはHelm Chartsと呼ばれます。
Kubernetesのシークレット
シークレットは、パスワード、トークン、またはキーなどの機密データを含むオブジェクトです。このような情報は通常、Podの仕様やイメージに配置される可能性があります。ユーザーはシークレットを作成でき、システムもシークレットを作成します。シークレットオブジェクトの名前は有効なDNSサブドメイン名である必要があります。公式ドキュメントを参照してください。
シークレットには次のようなものがあります:
API、SSHキー。
OAuthトークン。
資格情報、パスワード(平文またはb64 + 暗号化)。
情報やコメント。
データベース接続コード、文字列...。
Kubernetesには異なるタイプのシークレットがあります
組み込みタイプ | 使用法 |
---|---|
Opaque | 任意のユーザー定義データ(デフォルト) |
kubernetes.io/service-account-token | サービスアカウントトークン |
kubernetes.io/dockercfg | シリアル化された~/.dockercfgファイル |
kubernetes.io/dockerconfigjson | シリアル化された~/.docker/config.jsonファイル |
kubernetes.io/basic-auth | 基本認証の資格情報 |
kubernetes.io/ssh-auth | SSH認証の資格情報 |
kubernetes.io/tls | TLSクライアントまたはサーバーのデータ |
bootstrap.kubernetes.io/token | ブートストラップトークンデータ |
Opaqueタイプはデフォルトで、ユーザーによって定義された典型的なキーと値のペアです。
シークレットの動作方法:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-164.jpg&width=768&dpr=4&quality=100&sign=407ce89f&sv=1)
次の構成ファイルは、username: YWRtaW4=
およびpassword: MWYyZDFlMmU2N2Rm
の2つのキーと値のペアを持つmysecret
というシークレットを定義しています。また、mysecret
で定義されたusername
とpassword
を環境変数SECRET_USERNAME
およびSECRET_PASSWOR
に公開するsecretpod
というポッドを定義しています。また、username
シークレットを/etc/foo/my-group/my-username
パスに0640
の権限でマウントします。
etcd内のシークレット
etcdは、Kubernetesのバックエンドストアとして使用される一貫性があり高可用性のキーバリューストアです。etcdに保存されているシークレットにアクセスしましょう:
以下は、FS に配置されている証明書、キー、および URL が表示されます。これらを取得すると、etcd に接続できるようになります。
一度コミュニケーションを確立すると、シークレットを取得できるようになります。
ETCDへの暗号化の追加
デフォルトでは、すべてのシークレットはetcd内部に平文で保存されますが、暗号化レイヤーを適用しない限りです。次の例は、https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/に基づいています。
その後、作成した構成ファイルの場所を指すようにkube-apiserver
の--encryption-provider-config
フラグを設定する必要があります。/etc/kubernetes/manifest/kube-apiserver.yaml
を変更し、次の行を追加します:
volumeMounts でスクロールダウンしてください。
ボリュームマウントをhostPathにスクロールダウンします:
データが暗号化されていることを検証する
データはetcdに書き込まれる際に暗号化されます。kube-apiserver
を再起動した後、新しく作成されたまたは更新されたシークレットは保存される際に暗号化されるはずです。確認するために、etcdctl
コマンドラインプログラムを使用してシークレットの内容を取得できます。
default
ネームスペースにsecret1
という新しいシークレットを作成します:
etcdctlコマンドラインを使用して、etcdからそのシークレットを読み取ります:
ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
ここで[...]
はetcdサーバーに接続するための追加の引数である必要があります。 3. 保存されたシークレットがk8s:enc:aescbc:v1:
で始まっていることを確認します。これはaescbc
プロバイダーが結果データを暗号化したことを示します。 4. APIを介して取得された際にシークレットが正しく復号化されていることを確認します:
はmykey: bXlkYXRh
に一致するはずです。mydata
はエンコードされています。シークレットを完全にデコードするには、シークレットのデコードを確認してください。
シークレットは書き込み時に暗号化されるため、シークレットの更新を行うとその内容が暗号化されます:
最終的なヒント:
FSに秘密を保管しないようにして、他の場所から取得します。
秘密にさらなる保護を追加するためにhttps://www.vaultproject.io/をチェックしてください。
参考文献
Last updated