Kubernetesの基礎
Kubernetes の基礎
第2回目までは分かりやすくするために、「KubernetesがDockerホストを管理している」とお話してきました。しかし実際には、Docker以外のコンテナランタイムを用いたホストも管理することができるように作られています。そのため、これ以降はKubernetes Nodeと表記していきます。実際にはKubernetesはKubernetes MasterとKubernetes Nodeから成り立っています。Kubernetes MasterはAPIエンドポイントの提供、コンテナのスケジューリング、コンテナのスケーリングなどを担います。もう一方のKubernetes Nodeは、いわゆるDocker Hostに相当する実際にコンテナが起動するホストです。
Kubernetesクラスタを操作する際には、CLIツールのkubectlとYAML形式で書かれたManifestファイルを用いてKubernetes Masterに「リソース」の登録を行います。実際にはkubectlも内部でKubernetes MasterのAPIを叩いているだけなので、ライブラリやcurlなどでも操作することが可能です。
Kubernetesとリソース
Kubernetes では「リソース」を登録することで、非同期にコンテナの実行やロードバランサの作成が行われます。リソースにはコンテナ、ロードバランサ、ノードなど様々な種類があり、リソースによってYAMLマニフェストに指定できるパラメータが異なります。PodリソースがKubernetesクラスタのdefault namespace上に登録されている場合には、API的には/api/v1/namespaces/default/pods/以下に登録されています。
Kubernetesのリソースはたくさんの種類がありますが、大きく分けて次の5種類に大別されています。
リソースの分類 | 内容 |
---|---|
Workloadsリソース | コンテナの実行に関するリソース |
Discovery&LBリソース | コンテナを外部公開するようなエンドポイントを提供するリソース |
Config&Storageリソース | 設定・機密情報・永続化ボリュームなどに関するリソース |
Clusterリソース | セキュリティやクォータなどに関するリソース |
Metadataリソース | リソースを操作する系統のリソース |
今回の連載では全体像を把握出来るように、ユーザが利用する5種類のリソースについて説明していきます(内部的に利用されているリソースは除きます)。次回以降、これらの各リソースについて詳細な説明を行います。また、この中でもアプリケーション開発者が特に利用するのは、Workload、Discovery&LB、Config&Storageの3種類になります。
Workloadsリソース
1つ目のWorkloadsリソースは、クラスタ上にコンテナを起動させるのに利用するリソースです。内部的に利用されているものを除いて利用者が直接利用するものとしては、全部で8種類のWorkloadsリソースが存在します。
- Pod
- ReplicationController
- ReplicaSet
- Deployment
- DaemonSet
- StatefulSet
- Job
- CronJob
Discovery&LBリソース
2つ目のDiscovery&LBリソースは、コンテナのサービスディスカバリや、外部からもアクセス可能なエンドポイントなどを提供するリソースです。内部的に利用されているものを除いて利用者が直接利用するものとしては、ServiceとIngressの2種類のDiscovery&LBリソースが存在します。そのうちのServiceには、エンドポイントの提供方式が異なる複数のタイプが用意されています。
- Service
- ClusterIP
- NodePort
- LoadBalancer
- ExternalIP
- ExternalName
- Headless
- Ingress
Config&Storageリソース
3つ目のConfig&Storageリソースは、設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供するリソースです。SecretとConfigMapはいずれもKey-Valueのデータ構造を持ち、設定に適しているか機密データに適しているかの違いがあります。PersistentVolumeClaimは、コンテナから永続ボリュームを利用する際に利用します。
- Secret
- ConfigMap
- PersistentVolumeClaim
Clusterリソース
4つ目のClusterリソースは、クラスタ自体の振る舞いを定義するリソースです。様々なリソースが存在していますが、セキュリティや利便性に関する設定、ポリシーなどのリソースが該当します。
- Namespace
- ServiceAccount
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
- NetworkPolicy
- ResourceQuota
- PersistentVolume
- Node
Metadataリソース
5つ目のMetadataリソースは、クラスタ内の他のリソースの動作を制御するようなリソースです。例えば、Podをオートスケールさせるために利用されるHorizontalPodAutoscalerは、Deploymentなどのリソースを操作することでオートスケールを実現しています。
- CustomResourceDefinition
- LimitRange
- HorizontalPodAutoscaler
Namespaceによる仮想的なクラスタの分離
KubernetesにはNamespaceと呼ばれる仮想的なKubernetesクラスタの分離機能が存在します。完全な分離レベルではないため使い所は限られますが、1つのKubernetesクラスタを複数チームで利用することが可能です。マネージドサービスや構築ツールを使って構築されるKubernetesクラスタの大部分は、RBAC(Role-Based Access Control)がデフォルトで有効になっているため、Namespaceをスコープとした権限設定をすることにより、分離性を高めることが可能です。
Kubernetesは初期状態で、下記の3つのNamespaceを作成します。kube-systemでは、慣習的にKubernetes Dashboardといったシステムコンポーネントやアドオン的な位置づけのシステムが展開されます。もう一方のkube-publicでは、慣習的に全ユーザが共通して利用する設定値などを保存しておくNamespaceとして作られています。複数人で共有利用する予定がなく、システムが複雑ではない場合には、default Namespaceを利用する運用で問題ないと思います。
- default:デフォルトのNamespace
- kube-system:Kubernetesクラスタのコンポーネントやaddonが展開されるNamespace
- kube-public:全ユーザが利用できるConfigMapなどを配置するNamespace
CLIツールkubectlと認証情報
kubectlがKubernetes Masterとやり取りを行う際には、接続先サーバの情報や認証情報などが必要となります。デフォルトではkubectlは「~/.kube/config」に書かれている情報をもとに接続を行います。~/.kube/configもYAML Maniestと同じフォーマットとなっており、下記のような形で書かれています。
apiVersion: v1 kind: Config preferences: {} clusters: - name: sample-cluster cluster: server: https://localhost:6443 users: - name: sample-user user: client-certificate-data: LS0tLS1CRUdJTi... client-key-data: LS0tLS1CRUdJTi... contexts: - name: sample-context context: cluster: sample-cluster namespace: default user: sample-user current-context: sample-context
~/.kube/configにはcluster、user、contextの3種類を定義するようになっています。clustersには接続先クラスタの情報、usersには認証情報をそれぞれ定義します。認証情報には様々なproviderが利用できるようになっています。そしてcontextには、clusterとuser のペアにnamespaceを指定したものを定義します。kubectlはこのcontextを切り替えていくことで、複数の環境を操作できるように設計されています。
上記のような設定は手動で作成することも可能ですが、kubectlコマンドを使って作成することもできます。
# クラスタの定義 $ kubectl config set-cluster prd-cluster \ --server=https://localhost:6443 # 認証情報の定義 $ kubectl config set-credentials admin-user \ --client-certificate=./sample.crt \ --client-key=./sample.key \ --embed-certs=true # コンテキストの定義 (クラスタ、認証情報、Namespace を定義) $ kubectl config set-context prd-admin \ --cluster=prd-cluster \ --user=admin-user \ --namespace=default
実際にコンテキストを切り替えながら使うことで、複数のクラスタやユーザを扱うことが可能です。
# コンテキストの切り替え $ kubectl config use-context prd-admin Switched to context "prd-admin". # 現在のコンテキストを表示 $ kubectl config current-context prd-admin
コンテキストやネームスペースの切り替えを行うkubectlのコマンドが冗長だと思う方は、kubectx/kubensの利用も検討してみて下さい。
# コンテキストの切り替え $ kubectx prd-admin Switched to context "prd-admin". # ネームスペースの切り替え $ kubens kube-system Context "prd-admin" is modified. Active Namespace is "kube-system".
kubectlとYAML Manifest
さて、kubectlが利用できるようになったところで、実際にYAML Maniefstを使ってコンテナを起動してみましょう。今回は次のような1コンテナからなるPodを作成してみます。
# sample-pod.yml apiVersion: v1 kind: Pod metadata: name: sample-pod spec: containers: - name: nginx-container image: nginx:1.12
リソースを作る際は、kubectl createコマンドを利用します。すでに該当のリソースが存在する場合には、Errorが発生します。
# リソースが存在しない場合 $ kubectl create -f sample-pod.yml pod "sample-pod" created # リソースが存在する場合 $ kubectl create -f sample-pod.yml Error from server (AlreadyExists): error when creating "sample-pod.yml": pods "sample-pod" already exists
一方でリソースを削除する際は、kubectl deleteコマンドを利用します。こちらもリソースが存在しない場合には、Errorが発生します。
# リソースが存在する場合 $ kubectl delete -f sample-pod.yml pod "sample-pod" deleted # リソースが存在しない場合 $ kubectl delete -f sample-pod.yml Error from server (NotFound): error when stopping "sample-pod.yml": pods "sample-pod" not found
リソースの更新は、kubectl applyコマンドを利用します。今回はDockerイメージのアップデートを想定して、先ほどのsample-pod.ymlのイメージタグの部分を下記のように編集します。
# 変更差分 8c8 < image: nginx:1.12 --- > image: nginx:1.13
新しいnginx imageを利用するようにYAMLファイルを書き換えたあとは、kubectl applyコマンドを使って変更を適用します。kubectl applyコマンドは、変更差分がある場合には変更処理を行い、変更差分がない場合には何もしません。また、リソースが存在しない場合には、kubectl createコマンドと同様に新規作成を行います。そのため基本的にはkubectl createではなくkubectl applyを使ったほうが利便性は高いといえます。
# 変更点がある場合 $ kubectl apply -f sample-pod.yml pod "sample-pod" configured # 変更点がない場合 $ kubectl apply -f sample-pod.yml pod "sample-pod" unchanged # リソースが存在しない場合 $ kubectl apply -f sample-pod.yml pod "sample-pod" created
その他、kubectl set、kubectl replace、kubectl editなどの各コマンドでも、更新処理を行うことが可能です。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- KubernetesのDiscovery&LBリソース(その1)
- Oracle Cloud Hangout Cafe Season5 #3「Kubernetes のセキュリティ」(2022年3月9日開催)
- KubernetesのConfig&Storageリソース(その1)
- KubernetesのDiscovery&LBリソース(その2)
- Kubernetes環境を構築して、実際にコンテナを動かしてみよう
- Project CalicoをKubernetesで使ってみる:構築編
- 「kwok」でKubernetesクラスターをシュミレーションする
- KubernetesのWorkloadsリソース(その1)
- 「Inspektor Gadget」でKubernetesクラスタをデバッグする
- KubernetesのWorkloadsリソース(その2)