はじめに

本記事は、これからKubernetesをはじめる方を対象とし、コンテナ開発の基本を最速で理解するための入門記事になります。

入門記事といっても、コンテナ型仮想化技術に対する単なる抽象概念の理解は前提知識とし、少し掘り下げながら、Kubernetesの導入や、基本的な操作及び周辺技術の理解を目的にまとめています。

前提知識

Kubernetesをはじめるにあたり、コンテナ型仮想化技術に関する知識が求められます。
本記事では、コンテナ型仮想化技術としてDockerを使用しますが、Dockerの基本的なことについてはTL;DRになるので割愛します。なお、おさえておきたい知識としては、以下になります。

コンテナ型仮想化技術（概要レベル）
コンポーネント（Docker Engine/Docker Compose/Docker Swarm/Docker Machine/Docker Kitematic/Docker Registry等）
Dockerの操作（イメージ・コンテナ）
オーケストレーションツールの知識
Docker Hub

コンテナ型仮想化技術について少し深堀

コンテナ型仮想化技術は、OSのカーネルの機能により実現さています。
OSのカーネルの機能を使用することで、ホストのリソースを各コンテナごとに隔離及び分配することで、独立した空間を作り出しています。また、この独立した空間を作り出す仕組みを提供しているソフトウェアとして、LXCがあります。

LXCは、Linux カーネルが持つコンテナ機能のためのユーザスペースのインターフェースです。 DockerとLXCは混合しやすいですが、それぞれ別のソフトウェアになります。Dockerは、アプリケーションのデプロイを目的として設計されているため、「1コンテナ1プロセス」をうたっていますが、LXCは「OSレベル仮想化のソフトウェア」と言われています。 Dockerも0.8まではLXCを使用していました。

現在、Dockerアーキテクチャは4つのコンポーネントに分割されています。Docker Engine、containerd、containerd-shm、及びrunC。バイナリはそれぞれdocker、docker-containerd、docker-containerd-shim、及びdocker-runcと呼ばれます。

コンテナを実行するために、Docker Engineはイメージを作成し、それをcontainerdに渡します。containerdは、runCを使用してコンテナを実行するcontainerd-shimを呼び出します。その後、containerd-shimはランタイム（この場合はrunC）がコンテナの起動後に終了できるようにします。このようにすると、コンテナ用の長時間のランタイムプロセスを持つ必要がなくなるため、デーモンレスコンテナを実行できます。

ランタイム

ランタイムは、プログラム実行時のことや、実行するときに必要な物を意味します。
コンテナランタイムについて少し捕捉します。

containerd

containerdは、ランタイムが実行したコンテナを管理します。

containerdはもともとDocker社によって開発されてきましたが、標準的なランタイム実装を実現するために、Docker社から中立的な団体である**Cloud Native Computing Foundationに（CNCF）**に、2017年3月に寄贈されました。

containerd-shim

containerd-shimは、デーモンレスコンテナを可能にします。
起動されたすべてのコンテナの親プロセスであり、デーモンなしのコンテナも許可されます。

runC

runCは、コンテナを作成や起動したりするバイナリのプログラムです。また、runCはDocker Engineと同じ技術であるlibcontainer上に実装されています。

Docker社によって開発され、オープンソース化されていますが、現在はコンテナ型仮想化技術の標準化に取り組む**Open Container Initiative（OCI）**（※1）が定義する仕様で、事実上コンテナ型仮想化技術のデファクトスタンダードとなっています。実装としては、Namespace、cgroups、pivot_root、AppArmor、SELinux、seccomp等により、セキュア（※2）なコンテナを作り出しています。

（※1）Open Container Initiative（OCI）は、コンテナエコシステム内での潜在的な断片化や分割を回避するために、ソフトウェアコンテナの共通標準を確立することを目的とし、二つの指定が含まれています。

runtime-spec：ランタイム仕様
image-spec：イメージ仕様

（※2）2019年2月12日に、runcの脆弱性（CVE-2019-5736）が発見されています。この脆弱性により、悪意のあるコンテナが（最小限のユーザーで）許可されます。ホストのruncバイナリを上書きして、rootレベルになるホスト上で任意のコマンドを実行することができるようになります。

Dockerで使用しているランタイムの確認
docker info | grep 'Runtime'

libcontainer

libcontainerは、Go言語で実装されたライブラリです。

Dockerのコンテナ機能は、0.8までLXCに依存してきましたが、0.9以降はカーネルのコンテナAPIを直接コールするlibcontainerドライバに変更されました。

カーネル

カーネルは、オペレーティングシステム (OS) のコアとなる部分です。
CPU、メモリ、デバイスの入出力といったハードウェアリソースを抽象化します。

コンテナ型仮想化技術は、ホスト型やハイパーバイザー型等他の仮想化技術に比べて、オーバーヘッドが少ないため、軽量で高速に動作するのが特徴です。

ファイルシステム

Dockerでは、複数のファイルシステム上のディレクトリやファイルをレイヤとして重ね合わせ、それらを仮想的に一つのファイルシステムとして扱うことにより、イメージを実現しています。また、イメージレイヤに対するコンテナ上でのファイルの更新は、コピーオンライトによって実現しています。コピーオンライト処理は、ストレージドライバによって実装が異なります。

例として、Aufsは、複数の異なるファイルシステム (ブランチと呼ばれる) のファイルやディレクトリ同士を透過的に重ねる (マージする) ことができる技術です。

Dockerで使用しているドライバの確認
docker info | grep 'Storage Driver'
Docker イメージレイヤの確認
docker history イメージ

Namespace

Namespaceは、コンテナ毎に異なる論理的な空間を提供し、隔離するための技術です。

名前空間	定数	概要
IPC	CLONE_NEWIPC	System V プロセス間通信オブジェクトと呼ばれる、POSIXメッセージキュー等内部のプロセス間通信を分離する。
MOUNT	CLONE_NEWNS	Namespace内に隔離されたファイルシステムツリーを作り、ファイルシステムツリーを分離する。
Network	CLONE_NEWNET	ネットワークデバイス、IPアドレス、ポート番号、ルーティングテーブル、フィルタリングテーブル等ネットワークリソースを分離する
PID	CLONE_NEWPID	PID(プロセスID)を分離する。
UID	CLONE_NEWUSER	UIDやGIDを分離する。
UTS	CLONE_NEWUTS	uname() システムコールから返される2つのシステム識別子(ホスト名やNISドメイン名)を分離する。

cgroups

cgroupsは、プロセスグループのリソース(CPU、メモリ、ディスクI/O等)の利用を制限・隔離するLinuxカーネルの機能です。グループ内のプロセスから他のグループのリソースが見えないようにできているのは、名前空間による隔離機能が働いているためです。

興味があれば、カーネルソースのtask_struct()を見てみるといいかもしれません。

Linux カーネル内部では、プロセスは task_struct と呼ばれるかなり大きな構造体で表現されます。task_struct は ./linux/include/linux/sched.h に含まれています。

chroot

chrootは古い技術ですが、仮想化技術をより理解するためには、知ってるといいでしょう。

chrootは、ファイルシステムの名前空間を隔離します。もう少し分かりやすく言うと、これ以上のディレクトリに行かせないように、ルートディレクトリを変更します。但し、隔離するのは、あくまでファイルシステムのみです。他のリソースは隔離しないため、ユーザーIDやネットワークインターフェイスは共通のものが見えます。

身近な例としては、bindの構築で使用されています。chrootすることで、/var/named/chrootがルートディレクトリになり、bindプロセスがアクセス可能な範囲を制限することを目的としています。これにより、万が一攻撃を受けて侵入されても、/var/namedディレクトリだけが影響を受けます。

chrootを使用する場合は、どこを起点にしているかで相対的位置を理解しておくと、トラブルの防止になります。

Kubernetes概要

Kubernetesは、宣言型構成及びコンテナ自動運用を可能とするコンテナオーケストレーションツールの一つです。分散システムとしてAPIを提供するために、信頼性・可用性・拡張性を実現します。

Googleが開発（※1）して2014年にオープンソース化されたKubernetesは、2017年10月のDockerCon EUでの、DockerのKubernetes統合発表を機に、取り巻く状況は大きく変わっていきました。現在は主要なクラウドサービスでもサポートされ、依然コンテナオーケストレーションツールとして、その重要性は変わっていません。

GKE（Google Kubernetes Engine）
Amazon EKS（Amazon Elastic Container Service for Kubernetes）
AKS（Azure Kubernetes Service）（※2）
CEK（Container Engine for Kubernetes）（※3）

（※1）Googleが社内のアプリケーション基盤として利用していた「Borg」と呼ばれるシステムが元
（※2）ACS（Azure Container Service）のサポートは2020年1月31日をもって終了
（※3）Oracleが提供するクラウドサービス

オーケストレーションツール

オンプレミスにおけるシステムの拡張方式は、スケールアップやスケールアウトの運用が一般的でしたが、クラウドの登場により、必要なときに、必要なリソースを迅速に構築する仕組みとしてオーケストレーションツールが生まれました。コンテナに係るオーケストレーションツールとして、主要なクラウドサービス以外でも以下のような種類があります。

開発元	サービス
Red Hat	OpenShift
Pivotal	PKS
Docker	Swarm
Apache	Apache Mesos
Rancher Labs	Rancher
Mesosphere	Mesosphere DC/OS
Cloud Foundry	CFCR（Cloud Foundry Container Runtime）

オーケストレーションツールは、Kubernetesのシェアが高いですが、Googleがオープンソース化したgVisor、OpenStack Foundationが開発したKata Containers、Kubernetesにネイティブ対応したコアランタイムのcontainerd等多様なランタイムが登場すると見込まれており、コンテナ型仮想化技術の動向踏まえて、今後も目が離せません。

アーキテクチャ

Kubernetesを構成する要素はリソースとして区別され、Kubernetes Cluster（以降、クラスタ）はKubernetesの管理するリソースの集合体である
NodeはKubernetes クラスタで管理されるDockerホストであり、MasterとNodeに区別される
クラウドサービスで提供されるGKEの様なマネージドサービスでは、開発者がMasterを意識することはほとんどない
Kubernetes クラスタのリソースに対する操作は標準化されたAPIによる行う
Deploymentを1つの単位として、アプリケーションをデプロイする

Kubernetesのコンポーネント

MasterでAPIの受け付けを行い、Nodeの管理やKubernetes クラスタのコントロールを行なっています。Node内のkubeleteにより、Pod内のコンテナを管理します。また、ダッシュボードやDNS等のアドオンにより、Kubernetes クラスタとして機能します。

Kubernetesのコンポーネントの詳細は、Kubernetes Componentsを参照。

CRI（Container Runtime Interface）

KubernetesとDockerのあいだでは、Kubernetesで標準化されたAPIであるCRI（Container Runtime Interface）によってやりとりが行われます。以下は、KubernetesでのContainer Runtime Interface（CRI）の紹介についてのブログ記事です。

Introducing Container Runtime Interface (CRI) in Kubernetes

なお、KubernetesとCRIの対応についていは、Git Hubのcontainerd/criのリポジトリのREADMEを参照。

Kubernetesの意義

Kubernetesの意義を知りましょう。
Borgの歴史は、Borg, Omega, and Kubernetesから、知ることができます。

その他

Kubernetesに関連するツールや、フレームワーク等について以下に記載します。

kubeadm
kubeadmは、ベストプラクティスに準拠した最低限実行可能なKubernetesクラスタを構築することができます。ラップトップ、サーバー、Raspberry Pi等色々なプラットフォームに対応しています。
minikube
minikubeは、macOS、Linux、およびWindows上にローカルKubernetesクラスタを構築することができます。
k3s
k3sは、Rancher Labs社がオープンソースで公開したKubernetesのディストリビューションです。わずか40MBでありながら、標準のKubernetesとしての機能を備えつつ、Kubernetes認証プログラムである「Certified Kubernetes」を取得。Rancher Labsよりダウンロードできます。
Knative
Knativeは、最新のサーバーレスワークロードをビルド、デプロイ、管理できる Kubernetes ベースのプラットフォーム。ワークロードをオンプレミスで実行している環境においてもコンテナをビルドできます。
OpenFaaS
OpenFaaSは、Docker SwarmとKubernetesをサポートしているFaaSフレームワークで、リクエストに応じてコードを実行、状況に応じて自動的にインスタンスをスケールさせるということができます。オンプレミスや各社のクラウドサービス上でも導入することができます。
kubeless
Kubelessは、Kubernetes固有のサーバーレスフレームワークで、基盤となるインフラストラクチャを気にせずに小さなコード（関数）をデプロイできます。
Osiris
Osirisは、アイドル状態のワークロードを自動的にゼロまでスケールアップし、ゼロまでのスケールのワークロードをインバウンド要求によってオンデマンドで自動的に再アクティブ化することを可能にすることで、Kubernetesクラスター内のリソース効率を向上させます。まだ、開発中のコンポーネントのようです。
Virtual Kubelet
Virtual Kubeletは、Microsoftが始めたOSSプロジェクトです。Kubernetesを拡張して、特定のワークロードをノードレスのサービスとして実行することができます。イメージとしては、VMwareのvMotionのように、Virtual Kubeletが動作するノードとは別のコンピューティングリソースに、コンテナを展開できます。
Anthos
Anthosは、Kubernetesをベースにアプリケーションのマルチクラウド対応を実現する新サービスです。Google Cloud上ではGoogle Kubernetes Engine（GKE）上で稼働し、オンプレミスではGKE on Prem上で稼働。さらにAWS上でも稼働予定のため、Google以外のクラウドサポートが見込まれています。また、オンプレミスでのAnthosの実行環境は、現時点ではGKE on premの稼働条件であるVMware 6.5以上、F5 BIG-IPとされています。

Kubernetesのインストール

ローカル環境でKubernetesをインストールして使ってみましょう。

本記事の環境は以下になります。

環境：iMac
前提条件：Docker Desktop for Macがインストール済み

画面上部のDockerアイコンから、「Preferences」をクリックして、「Kubernetes」を選択します。

「Install」をクリックします。

インストールが始まるので少し待ちます。

インストールが終わったら「Close」をクリックして、「Kubernetes is running」と緑色で表示されたら正常に起動しています。

Kubernetesの操作

Kubernetesは、コマンドラインとGUIで操作ができます。

kubectl

kubectlは、Kubernetesをコマンドラインで操作するためのツールです。kubectlの概要（コマンドの構文等）は、 Overview of kubectlを参照。

Kubernetes クラスタの状態確認

Kubernetes クラスタの状態確認行うコマンドを以下に記載します。

クラスタのバージョン確認
kubectl version

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:38:32Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

クラスタの正常性確認
kubectl get componentstatus

NAME                 STATUS    MESSAGE              ERROR
controller-manager   Healthy   ok                   
scheduler            Healthy   ok                   
etcd-0               Healthy   {"health": "true"}

クラスタのノード一覧表示
kubectl get nodes

NAME                 STATUS    ROLES     AGE       VERSION
docker-for-desktop   Ready     master    59d       v1.10.11

クラスタのノード詳細情報表示
kubectl describe nodes ノード名

ダッシュボード

ダッシュボードを使用することで、ブラウザからKubernetes クラスタを管理することができます。

以下のコマンドを実行し、ダッシュボードを追加します。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.8.3/src/deploy/recommended/kubernetes-dashboard.yaml

secret "kubernetes-dashboard-certs" created
serviceaccount "kubernetes-dashboard" created
role.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" created
rolebinding.rbac.authorization.k8s.io "kubernetes-dashboard-minimal" created
deployment.apps "kubernetes-dashboard" created
service "kubernetes-dashboard" created

以下のコマンドを実行し、デプロイされたことを確認します。

kubectl get pod --namespace=kube-system -l k8s-app=kubernetes-dashboard

NAME                                    READY     STATUS    RESTARTS   AGE
kubernetes-dashboard-7d5dcdb6d9-6tpxv   1/1       Running   0          1m

以下のコマンドを実行し、ダッシュボードへのプロキシサーバを起動します。

kubectl proxy

Starting to serve on 127.0.0.1:8001

ブラウザから、ダッシュボードにアクセスすると、以下の様な画面が表示されるので「SKIP」をクリックします。

（※）実際に運用で使用する際は、認証機能を使用した方がセキュリティ的に望ましいです。

ダッシュボードが表示されます。

トークンの取得方法

ダッシュボードログイン時に、Tokenを指定してログインする方法を以下に記載します。

以下のコマンドを実行し、デフォルトトークンを特定します。

kubectl -n kube-system get secret | grep default-token

default-token-fx2v4                              kubernetes.io/service-account-token   3         52d

以下のコマンドを実行し、tokenの内容を出力します。

kubectl -n kube-system describe secret default-token-fx2v4

Name:         default-token-fx2v4
Namespace:    kube-system
Labels:       <none>
Annotations:  kubernetes.io/service-account.name=default
              kubernetes.io/service-account.uid=d9b76415-3c80-11e9-9164-025000000001

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1025 bytes
namespace:  11 bytes
token:      （※）トークンの内容が出力される

ダッシュボードログイン時に、Tokenを指定し、上記コマンド出力結果のtokenを入力することでログインができます。

Kubernetes API オブジェクト

Kubernetes上にある全てのリソースは、RESTfulリソース（Kubernetesオブジェクト）で表現されます。

例えば、Kubernetes Deploymentは、Kubernetes クラスタ上で実行されているアプリケーションを表すことができるオブジェクトです。Kubernetesオブジェクトを操作するために、Kubernetes APIを使用します。

Kubernetes APIのオブジェクトは、YAMLあるいはJSONで表現できます。オブジェクトの作成、更新、削除等の操作はYAMLやJSONのファイルを使用してAPIによる操作が行えます。

Pod

Podは、Kubernetes クラスタ上での最小のデプロイ単位です。Pod内のアプリケーションは、同じIPアドレスとポートを使用します。Podの設定は、Podマニフェストに記述します。

Podマニフェストは、YAMLあるいはJSONで記述します。一般的にはYAMLで記述する方法が汎用的です。YAMLではインデントを使ってデータの階層構造を表すため、非常に読みやすく書きやすいですが、デプロイ時のエラーの原因でもあります。

KubernetesのYAMLフォーマットの書き方はUnderstanding Kubernetes Objectsを参照。

Pod操作

kuardを例に、基本的なPod操作を行うコマンドを以下に記載します。

kubectlコマンドの引数で指定するリソース種別は、「pod」または「pods」のどちらでも実行できます。また、略して「po」で指定することもできます。

kuard-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - name: kuard
      image: gcr.io/kuar-demo/kuard-amd64:1
      ports:
        - containerPort: 8080
          name: echo
          protocol: TCP

インスタンス起動
kubectl apply -f kuard-pod.yaml

pod "kuard" created

Podの一覧表示
kubectl get pod

NAME                READY     STATUS    RESTARTS   AGE
kuard               1/1       Running   0          5s

Podの詳細情報表示
kubectl describe pod kuard

Name:         kuard
Namespace:    default
Node:         docker-for-desktop/192.168.65.3
Start Time:   Sun, 21 Apr 2019 20:41:37 +0900
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"kuard","namespace":"default"},"spec":{"containers":[{"image":"gcr.io/kuar-demo/kua...
Status:       Running
IP:           10.1.0.65
Containers:
  kuard:
    Container ID:   docker://c5440df7d9eec2b10aa77baf29fe690597a98d68681d4ea49d1ee075745d5f78
    Image:          gcr.io/kuar-demo/kuard-amd64:1
    Image ID:       docker-pullable://gcr.io/kuar-demo/kuard-amd64@sha256:bd17153e9a3319f401acc7a27759243f37d422c06cbbf01cb3e1f54bbbfe14f4
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sun, 21 Apr 2019 20:41:39 +0900
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-vgzn7 (ro)
Conditions:
  Type           Status
  Initialized    True 
  Ready          True 
  PodScheduled   True 
Volumes:
  default-token-vgzn7:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-vgzn7
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason                 Age   From                         Message
  ----    ------                 ----  ----                         -------
  Normal  Scheduled              41s   default-scheduler            Successfully assigned kuard to docker-for-desktop
  Normal  SuccessfulMountVolume  41s   kubelet, docker-for-desktop  MountVolume.SetUp succeeded for volume "default-token-vgzn7"
  Normal  Pulled                 40s   kubelet, docker-for-desktop  Container image "gcr.io/kuar-demo/kuard-amd64:1" already present on machine
  Normal  Created                39s   kubelet, docker-for-desktop  Created container
  Normal  Started                39s   kubelet, docker-for-desktop  Started container

Podの削除
kubectl delete pod/kuard
kubectl delete -f kuard-pod.yaml

pod "kuard" deleted

インスタンスのログ取得
kubectl logs kuard

2019/04/23 09:10:58 Starting kuard version: v0.8.1-1
2019/04/23 09:10:58 **********************************************************************
2019/04/23 09:10:58 * WARNING: This server may expose sensitive
2019/04/23 09:10:58 * and secret information. Be careful.
2019/04/23 09:10:58 **********************************************************************
2019/04/23 09:10:58 Config: 
{
  "address": ":8080",
  "debug": false,
  "debug-sitedata-dir": "./sitedata",
  "keygen": {
    "enable": false,
    "exit-code": 0,
    "exit-on-complete": false,
    "memq-queue": "",
    "memq-server": "",
    "num-to-gen": 0,
    "time-to-run": 0
  },
  "liveness": {
    "fail-next": 0
  },
  "readiness": {
    "fail-next": 0
  },
  "tls-address": ":8443",
  "tls-dir": "/tls"
}
2019/04/23 09:10:58 Could not find certificates to serve TLS
2019/04/23 09:10:58 Serving on HTTP on :8080

コンテナ接続（対話的）
kubectl exec -it kuard ash
ポートフォワード
kubectl port-forward kuard 8080:8080

ReplicaSet

レプリカという言葉は、複製と言う意味です。
Kubernetes クラスタ上でのReplicaSetは、Podの複製を行います。
ReplicaSetマニフェストで定義したreplicasの値の通り(※)にPodの複製を行います。

(※)既にPodが起動していて、不足していればその分Podを複製します。多い場合にReplicaSetマニフェストを適用すると、その分削除されます。

ReplicaSet操作

kuardを例に、基本的なReplicaSet操作を行うコマンドを以下に記載します。

kubectlコマンドの引数で指定するリソース種別は、「replicaset」または「replicasets」のどちらでも実行できます。また、略して「rs」で指定することもできます。

kuard-rs.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: kuard
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kuard
        version: "2"
    spec:
      containers:
        - name: kuard
          image: gcr.io/kuar-demo/kuard-amd64:2

ReplicaSetの作成
kubectl apply -f kuard-rs.yaml

replicaset.extensions "kuard" created

ReplicaSetの一覧表示
kubectl get replicaset

NAME      DESIRED   CURRENT   READY     AGE
kuard     1         1         1         6s```

ReplicaSetの詳細情報表示
kubectl describe rs kuard

Name:         kuard
Namespace:    default
Selector:     app=kuard,version=2
Labels:       app=kuard
              version=2
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"extensions/v1beta1","kind":"ReplicaSet","metadata":{"annotations":{},"name":"kuard","namespace":"default"},"spec":{"replicas":1,"templat...
Replicas:     1 current / 1 desired
Pods Status:  1 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=kuard
           version=2
  Containers:
   kuard:
    Image:        gcr.io/kuar-demo/kuard-amd64:2
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  1m    replicaset-controller  Created pod: kuard-d65gb

ReplicaSetのスケール
kubectl scale replicasets kuard --replicas=4

replicaset.extensions "kuard" scaled

ReplicaSetの削除
kubectl delete rs kuard

replicaset.extensions "kuard" deleted

Service

Serviceは、サービスディスカバリを定義します。
サービスディスカバリとは、システム上のインフラにおけるサービスの問題を検出すると言うことを意味します。

例えば、マイクロサービスとしてサービスを提供しているコンテナにシステム障害が起きて停止した場合、障害が発生したコンテナ（Pod）に対するトラフィックを制御することができます。他にも、何らかのシステム障害発生時に、システム監視による検知でDNSレコードを更新したりして、DNSでサービスのディスカバリが行うことができます。

仕組みとして、各Podには固有のIPアドレスがありますが、それらのIPはServiceなしではクラスタの外部に公開されません。Serviceにより、アプリケーションはトラフィックを受信できます。

ClusterIP

デフォルトは、ClusterIPになります。ClusterIPはクラスタ内の内部にサービスを公開できます。ClusterIPにより、クラスタ内のPod間通信はServiceを介して行うことはできますが、外部からのアクセスはできません。

NodePort

NATを使用して、外部からクラスタに対するアクセスが可能になります。

LoadBalancer

主にクラウドサービスで提供されているロードバランサと連携して使用します。ロードバランサがサポートされている場合、サービスに固定の外部IPを割り当てることができます。

ExternalName

クラスタ内から外部のホストの名前解決を行うためのエイリアス（CNAME record）を設定することができます。なお、本機能はkube-dns v1.7以上になります。

Ingress

Kubernetes v1.1で追加されたIngressは、クラスタ外からのHTTP及びHTTPSの通信をクラスタ内のServiceに公開します。

Job

Jobは、指定された数のポッドの処理が成功するまで実行されるため、バッチ処理などに適しています。処理が成功するまで、JobコントローラがPodを作り直します。

ConfigMap

コンテナ運用で重要なのは、コンテナの特性を失わずに運用を行うことです。
例えば、Webサーバ機能を持つコンテナの設定を変えるために、Nginxの設定ファイルを変更するのはポータビリティを低下させます。環境変数を使用することで、チューニングがしやすくなります。環境変数の組み込みは色々やり方があると思いますが、KubernetesにはConfigMapという便利な機能があります。

ConfigMap操作

kuardを例に、基本的なConfigMap操作を行うコマンドを以下に記載します。

my-config.txt

parameter1 = value1
parameter2 = value2

ConfigMapの作成
kubectl create configmap my-config --from-file=my-config.txt --from-literal=extra-param=extra-value --from-literal=another-param=another-value

configmap "my-config" created

ConfigMapの一覧表示
kubectl get configmap

NAME        DATA      AGE
my-config   3         2d

ConfigMapの詳細情報表示
kubectl get configmap my-config -o yaml

apiVersion: v1
data:
  another-param: another-value
  extra-param: extra-value
  my-config.txt: |
    parameter1 = value1
    parameter2 = value2
kind: ConfigMap
metadata:
  creationTimestamp: 2019-04-25T06:23:43Z
  name: my-config
  namespace: default
  resourceVersion: "1030540"
  selfLink: /api/v1/namespaces/default/configmaps/my-config
  uid: ac8694d8-6722-11e9-97d1-025000000001

ConfigMapの削除
kubectl delete configmap my-config

configmap "my-config" deleted

Deployment

Deploymentは、Kubernetesクラスタ上で、デプロイされたアプリケーションのバージョン管理ができるオブジェクトです。Deploymentにより、ダウンタイムを発生させることなく、アプリケーションのバージョンのロールアウトが行えます。また、DeploymentはReplicaSetを管理します。

Deployment操作

基本的なDeployment操作を行うコマンドを以下に記載します。

kubectlコマンドの引数で指定するリソース種別は、「deployment」または「deployments」のどちらでも実行できます。また、略して「deploy」で指定することもできます。

runコマンドでデプロイ
kubectl run nginx --image=nginx:1.7.12

kubectl run nginx --image=nginx:1.7.12

Deploymentの一覧表示
kubectl get deployment

kAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx     1         1         1            1           52s

Deploymentの詳細情報表示
kubectl describe deployment nginx

dName:                   nginx
Namespace:              default
CreationTimestamp:      Sat, 27 Apr 2019 16:13:52 +0900
Labels:                 run=nginx
Annotations:            deployment.kubernetes.io/revision=1
Selector:               run=nginx
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:  run=nginx
  Containers:
   nginx:
    Image:        nginx:1.7.12
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-7d9bf79f9b (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  29s   deployment-controller  Scaled up replica set nginx-7d9bf79f9b to 1

Deploymentのスケール
kubectl scale deployment nginx --replicas=2

deployment.extensions "nginx" scaled

Deploymentの削除
kubectl delete deployment nginx

deployment.extensions "nginx" deleted

Deploymentの作成
kubectl get deployment nginx --export -o yaml > nginx-deployments.yaml
nginx-deployments.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: null
  generation: 1
  labels:
    run: nginx
  name: nginx
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      run: nginx
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:1.7.12
        imagePullPolicy: IfNotPresent
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status: {}

kubectl scaleコマンドではなく、Deploymentを宣言的に管理するする場合は、YAMLファイルのレプリカ数を変更して、kuberctl applyコマンドでDeploymentを更新します。また、合わせてコンテナイメージの部分を変更することで、新しいバージョンのロールアウトを可能とします。

ロールアウトの状態確認
kubectl rollout status deployment nginx

deployment "nginx" successfully rolled out

Deploymentが管理しているReplicaSetsのイメージ確認
kubectl get replicasets -o wide

NAME               DESIRED   CURRENT   READY     AGE       CONTAINERS   IMAGES                                             SELECTOR
nginx-784d96dbff   1         1         1         1m        nginx        nginx:1.9.10                                       pod-template-hash=3408528699,run=nginx
nginx-7d9bf79f9b   0         0         0         35m       nginx        nginx:1.7.12                                       pod-template-hash=3856935956,run=nginx

ロールアウト履歴
kubectl rollout history deployment nginx

deployments "nginx"
REVISION  CHANGE-CAUSE
1         <none>
2         Update nginx to 1.9.10

デプロイしたリビジョンの詳細情報表示
kubectl rollout history deployment nginx --revision=2

deployments "nginx" with revision #2
Pod Template:
  Labels:	pod-template-hash=3408528699
	run=nginx
  Annotations:	kubernetes.io/change-cause=Update nginx to 1.9.10
  Containers:
   nginx:
    Image:	nginx:1.9.10
    Port:	<none>
    Host Port:	<none>
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

ロールバック
kubectl rollout undo deployment nginx

deployment.apps "nginx"

Persistent Volumes

Kubernetesは、ストレージをプロビジョニングする方法として、静的または動的による二つの方法があります。

Persistent Volumesは、コンテナとは別に独立した永続化データを管理するための仕組みを静的に提供します。また、Kubernetesでは、NFS、iSCSI、クラウドプロバイダー固有のストレージシステムをサポートしています。

PePersistent Volumesの使い方は、Configure a Pod to Use a PersistentVolume for Storageを参照。

PersistentVolumeClaim

Persistent Volumesを作成したら、PersistentVolumeClaimも作成します。
Persistent Volumesを使用することで、論理的なストレージ割り当てを行い、Podがストレージに対するアクセスを要求できます。

その他、動的ボリューム割り当ては、StorageClassesオブジェクトを使用することで可能になります。

永続的ボリュームの詳細については、Persistent Volumesを参照。

エラー時の勘所

以下は、本記事執筆時に遭遇したエラーです。

Podにアクセスできない場合（ローカル環境）
ホストのFWやウイルス対策ソフトの設定を確認します。例として、ウイルス対策ソフトによりポート通信が遮断されることはよく考えられます。
ConfigMapを使用して、Podが作成できない
kubectl describe pod ポッド名の出力結果より、「Events」を見て、「Error: Couldn't find key 環境変数 in ConfigMap 」のログが出力されていたら、ConfigMapの環境変数に謝りがあります。ConfigMapの環境変数が正しいか見直しましょう。

Warning  Failed                 4m (x7 over 5m)    kubelet, docker-for-desktop  Error: Couldn't find key extra-param in ConfigMap default/my-config

StatefulSetオブジェクトを使用して、MongoDBのPodを作成できない
原因は、YAMLフォーマットの「spec」-「serviceName」で大文字を使用していたため。

Events:
  Type     Reason        Age               From                    Message
  ----     ------        ----              ----                    -------
  Warning  FailedCreate  3s (x10 over 5s)  statefulset-controller  create Pod mongo-0 in StatefulSet mongo failed error: Pod "mongo-0" is invalid: spec.subdomain: Invalid value: "Mongo": a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

おわりに

これからDevOpsエンジニア（※）を目指すにあたり、Kubernetesは必要不可欠なスキルです。

また、Kubernetesを更に理解するためには、コンテナ型仮想化技術やLinux等の知識も必須になってきます。

Kubernetesは深淵の海のように範囲が広く深いため、学習コストは高いですが、オンプレミスのインフラ経験を活かしてステップアップすることは十分に可能です。インフラエンジニアからDevOpsエンジニアへの階段を登りましょう。

（※）日本で言うインフラエンジニアは、オンプレミスのサーバ（OS/MW）・ネットワーク等幅広いですが、海外にならい開発と運用を組み合わせたDevOpsというアプローチとともに、SRE（Site Reliability Engineering）をイメージしています。

参考

本記事で記載している一部のサンプルコードは、以下の書籍を参考にしています。

出典：日本語版「入門 Kubernetes」Kelsey Hightower、Brendan Burns、Joe Beda　著、オライリー・ジャパン、ISBN978-4-87311-840-6