https://thinkit.co.jp/article/13289
- Kubernetesはコンテナ化されたアプリケーションの展開、スケーリング、および管理を自動化するためのコンテナオーケストレーションエンジンです。
- Dockerに注目が集まり、プロダクションで利用するシーンが増えたため、あと、Microservices化などの流れに伴って、流行している。
- 以前はDocker Swarmもあったが、デファクトスタンダードはk8sになっている。
- GCP: Google Container Engine（GKE）
- Azure: Azure Container Service（AKS）
- AWS: Amazon Elastic Container Service for Kubernetes（EKS）
- 複数のDockerホストの管理
- コンテナのスケジューリング
- ローリングアップデート
- スケーリング / オートスケーリング
- コンテナの死活監視
- 障害時のセルフヒーリング
- サービスディスカバリ
- ロードバランシング
- データの管理
- ワークロードの管理
- ログの管理
- Infrastructure as Code
- その他エコシステムとの連携や拡張
- YAMLのマニフェストファイルで、実行コンテナなど宣言的に記述できる（Infrastructure as a Code: devOps）
- Kubernetesは、複数のDockerホストを管理してコンテナクラスタを構築します。また、コンテナをKubernetes上で実行する際には、同じコンテナのレプリカとして展開することで負荷分散や耐障害性の確保をすることが可能です。さらに負荷に応じて、コンテナのレプリカ数を増減（オートスケーリング）することもできます。
https://thinkit.co.jp/article/13338
- 手元のWindows/Mac上でローカル Kubernetes 環境を立ち上げる
- 構築ツールを使ってクラスタを構築する
- パブリッククラウドのマネージド Kubernetes を利用する
マネージドサービスを使うのが一般的!?
- ローカルKubernetes
- Minikube
- Docker for Mac
- Kubernetes構築ツール
- kubeadm
- Rancher
- パブリッククラウド上のマネージドKubernetes
- Google Kubernetes Engine（GKE）
- Azure Container Service（AKS）
- Elastic Container Service for Kubernetes（EKS）
- ローカルで動かす場合に使われることが多い。
- デフォルトでVirtual Boxが必要。
- Preferencesから、Kubernetesを有効化すれば利用できる（起動まで5分ほどかかる）
- Minikubeを利用している場合は、コンテキストを切り替える必要がある。
$ kubectl config use-context docker-for-desktop
https://thinkit.co.jp/article/13542
- Kubernetes MasterはAPIエンドポイントの提供、コンテナのスケジューリング、コンテナのスケーリングなどを担います。
- Kubernetes Nodeは、いわゆるDocker Hostに相当する実際にコンテナが起動するホストです。
- kubectlも内部でKubernetes MasterのAPIを叩いているだけなので、ライブラリやcurlなどでも操作することが可能です。
- Kubernetes では「リソース」を登録することで、非同期にコンテナの実行やロードバランサの作成が行われます。
- リソースにはコンテナ、ロードバランサ、ノードなど様々な種類があり、リソースによってYAMLマニフェストに指定できるパラメータが異なります。
| リソースの分類 | 内容 |
|---|---|
| Workloadsリソース | コンテナの実行に関するリソース |
| Discovery＆LBリソース | コンテナを外部公開するようなエンドポイントを提供するリソース |
| Config＆Storageリソース | 設定・機密情報・永続化ボリュームなどに関するリソース |
| Clusterリソース | セキュリティやクォータなどに関するリソース |
| Metadataリソース | リソースを操作する系統のリソース |
クラスタ上にコンテナを起動させるのに利用するリソースです。内部的に利用されているものを除いて利用者が直接利用するものとしては、全部で8種類のWorkloadsリソースが存在します。
- Pod
- ReplicationController
- ReplicaSet
- Deployment
- DaemonSet
- StatefulSet
- Job
- CronJob
2つ目のDiscovery＆LBリソースは、コンテナのサービスディスカバリや、外部からもアクセス可能なエンドポイントなどを提供するリソースです。
- Service
- ClusterIP
- NodePort
- LoadBalancer
- ExternalIP
- ExternalName
- Headless
- Ingress
3つ目のConfig＆Storageリソースは、設定や機密データをコンテナに埋め込んだり、永続ボリュームを提供するリソースです。
- Secret
- ConfigMap
- PersistentVolumeClaim
4つ目のClusterリソースは、クラスタ自体の振る舞いを定義するリソースです。
- Namespace
- ServiceAccount
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
- NetworkPolicy
- ResourceQuota
- PersistentVolume
- Node
5つ目のMetadataリソースは、クラスタ内の他のリソースの動作を制御するようなリソースです。
- CustomResourceDefinition
- LimitRange
- HorizontalPodAutoscaler
- nginxの起動
- ログの確認
- コンテナ内にttyで接続
https://thinkit.co.jp/article/13610
- Workloads リソースの最小単位
- 1つ以上のコンテナから構成
- ネットワークは隔離されておらず、IP Addressなどは共有しています。
- コンテナ単位でIPアドレスが割り当てられるわけではなく、Pod単位でIPアドレスが割り当てられる。
- 多くの場合は、1Pod1コンテナを含むが、Proxyの役割をするコンテナ、設定値の動的な書き換えを行うコンテナ、ローカルキャッシュ用のコンテナ、SSL終端用のコンテナなどをPod内に入れておくことで2コンテナ以上を内包したPodが利用されることも。
- 補助するサブコンテナのことを「サイドカー」と呼ぶ。
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
spec:
containers:
- name: nginx-container
image: nginx:1.12
ports:
- containerPort: 80複数コンテナの場合:
apiVersion: v1
kind: Pod
metadata:
name: sample-2pod
spec:
containers:
- name: nginx-container-112
image: nginx:1.12
ports:
- containerPort: 80
- name: nginx-container-113
image: nginx:1.13
ports:
- containerPort: 8080コンテナへのログイン
$ kubectl exec -it sample-pod /bin/bash
- ReplicaSetはPodのレプリカを生成し、指定した数のPodを維持し続けるリソースです。
- ReplicationControllerは今後廃止の流れになっている。
- 複数のReplicaSetを管理することで、ローリングアップデートやロールバックなどを実現可能にするリソース
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-deployment
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
containers:
- name: nginx-container
image: nginx:1.12
ports:
- containerPort: 80https://thinkit.co.jp/article/13611
- ReplicaSetの特殊な形ともいえるリソース
- DaemonSetは、全nodeに1 podずつ配置するリソース
- レプリカ数などは指定できませんし、2 podずつ配置するといったこともできません。
- データベースなどstatefulなワークロードに対応するためのリソース
- 生成されるPod名が数字でindexingされたものになる
- 永続化するための仕組みを有している
- PersistentVolumeを使っている場合は同じディスクを利用して再作成される
- Pod名が変わらない
- コンテナを利用して一度限りの処理を実行させるリソース
- 並列実行なども行いながら、指定した回数までコンテナの実行（正常終了）が保証されるリソース
- バッチ的な処理の場合にはJobを積極的に利用しましょう。
apiVersion: batch/v1
kind: Job
metadata:
name: sample-job
spec:
completions: 1
parallelism: 1
backoffLimit: 10
template:
spec:
containers:
- name: sleep-container
image: centos:latest
command: ["sleep"]
args: ["60"]
restartPolicy: Never- Jobに似たリソース
- Kubernetes 1.4までScheduledJobという名前でしたが、CronJobに名称が変更になった。
- Cronのようにスケジュールされた時間にJobを生成します。
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: sample-cronjob
spec:
schedule: "*/1 * * * *"
concurrencyPolicy: Forbid
startingDeadlineSeconds: 30
successfulJobsHistoryLimit: 5
failedJobsHistoryLimit: 5
jobTemplate:
spec:
template:
spec:
containers:
- name: sleep-container
image: centos:latest
command: ["sleep"]
args: ["30"]
restartPolicy: Never- 基本的にはPodやReplicaSetを使うようなケースはDeploymentを使っておいたほうが良いでしょう。
- 細かい仕様の差はさておき、この8個のWorkloadsリソースは把握しておく必要があります。