HowTo

Railsアプリ開発のためのDocker/Kubernetes入門3 Kubernetes入門編

Table of Contents

  1. 1. 前提
  2. 2. はじめに
  3. 3. 開発環境の構築
  4. 4. 最小限のKubernetes(k8s)入門
    1. 4.1. Kubernetesとは
    2. 4.2. minikubeとは
      1. 4.2.1. minikube start: k8sクラスタ用VMの作成と起動
      2. 4.2.2. minikube dashboard: k8sダッシュボード
      3. 4.2.3. minikube docker-env: VM上のdockerdに接続するための環境変数の表示
      4. 4.2.4. minikube delete: k8sクラスタ用VMの停止と削除
    3. 4.3. k8sの基本
      1. 4.3.1. 準備
    4. 4.4. APIオブジェクトのマニフェストファイルとkubectlのチュートリアル
      1. 4.4.1. Deploymentの概要
      2. 4.4.2. Deploymentのマニフェストファイルの例
      3. 4.4.3. kubectl apply: APIオブジェクトの作成と更新
      4. 4.4.4. kubectl get: APIオブジェクトの状態の確認
      5. 4.4.5. kubectl logs (またはstern): コンテナのログの確認
      6. 4.4.6. kubectl port-forward: コンテナのポートをホスト側にポートフォワード
      7. 4.4.7. kubectl delete: APIオブジェクトの削除
      8. 4.4.8. Serviceの概要
      9. 4.4.9. kubectl run: コマンドによるDeploymentの作成
      10. 4.4.10. kubectl explain: ドキュメントの表示
  5. 5. 参考情報

RailsアプリケーションをKubernetes(以後、k8s)で運用できるようにするための手順を書きます。 この記事はシリーズ連載記事の第三回です。

今回は下記について書きます。

  • 最小限のk8s入門
  • minikubeの使い方
  • kubectlコマンドのチュートリアル

前提

  • macOSでの作業を前提としています。
  • 使用したツールのバージョンなどは 初回 の記事を参照してください。

はじめに

Kubernetesには膨大な機能があるので、最初から汎用的な使い方を学ぼうとすると挫折しがちです。 このドキュメントでは、紹介する機能や概念を「初心者がRailsアプリを動かすために必要な機能」という観点で限定し、 かつ段階的に説明していきます。

まずは minikubeを使ってmacOS上の仮想マシンにスタンドアローンのk8sクラスタを作り、 そこに前回 Docker Compose/Dockerfile編 で使用したサンプルアプリを デプロイする具体的な手順を示します。

紹介するサンプルコードは全て下記のリポジトリにあります。

https://github.com/kwhrtsk/rails-k8s-demoapp

開発環境の構築

下記のツールを使います。

  • minikube k8sクラスタをローカルVM上に構築するためのツールです。
  • hyperkitのドライバ minikubeがmacOS上でVMを操作するために必要です。
  • kubectl k8sクラスタを操作するためのCLIツールです。
  • helm k8sのマニフェストをパッケージとして管理するためのツールです。第六回 Helm編で使用します。
  • stern k8s上のコンテナのログを見るためのツールです。必須ではありませんがあると便利です。
  • GNU Make XCode付属のものを使います。無くても大丈夫です。

minikubeとkubectlとsternはHomebrew(cask)でインストールできます。

$ brew cask install minikube
$ brew install kubernetes-cli kubernetes-helm
$ brew install stern

hyperkitのドライバは次の手順でインストールしてください。参考

$ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-hyperkit \
&& chmod +x docker-machine-driver-hyperkit \
&& sudo mv docker-machine-driver-hyperkit /usr/local/bin/ \
&& sudo chown root:wheel /usr/local/bin/docker-machine-driver-hyperkit \
&& sudo chmod u+s /usr/local/bin/docker-machine-driver-hyperkit

macOS版のminikubeでは、hyperkitの代わりにVirtualBoxを使うこともできます。 全ての手順は両方で動作を確認していますが、hyperkitの方が高速です。 筆者の環境ではRailsアプリやMySQLなど一式k8sにデプロイするのにかかる時間はVirtualBoxだとおおよそ2分20秒前後、 hyperkitだと50秒前後でした。

最小限のKubernetes(k8s)入門

Kubernetesとは

k8sはDocker Composeと同じく複数のコンテナを管理するためのツールです。

Docker Composeでは一つのホスト上に複数のコンテナを起動することができましたが、 k8sでは複数のDockerサーバで一つのクラスタを構成し、その上に複数のコンテナを分散配置することができます。

また、Docker Composeは単にコンテナの起動や停止だけでなく、コンテナ間通信やボリュームの管理を行うことができましたが、 k8sはさらにロードバランサや定期実行ジョブなど実環境で必要になる多様な機能を抽象化し管理することができます。

minikubeとは

k8sをセットアップして使えるようにするためには色々な方法があります。代表的なものをいくつか紹介します。

  • GKE: GCP上のマネージドサービス
  • kops: AWS上にec2インスタンスを複数起動してk8sクラスタとして構成するツール
  • AKS: Azure上のマネージドサービス
  • kubespray: オンプレミスを含む任意の環境にk8sクラスタをセットアップするツール

本番環境でk8sを運用するためには上記のようなものを使う必要がありますが、 k8sを試してみるだけなら手元の環境で動作するminikubeを使うのが一番簡単です。

minikubeは端末上のVMへk8sをインストールして簡単に使えるようにするためのツールです。 VMドライバとしてはVirtualBox、hyperkit、KVMなどがサポートされています。

minikube/drivers.md

macOS上で試すのであれば VirtualBox か hyperkit が簡単です。 デフォルトでは VirtualBox が選択されるようですが、hyperkitの方が高速なのでこちらを使うのがおすすめです。

hyperkitはmacOS組み込みの仮想化フレームワーク 「Hypervisor Framework」を使うためのツールで、Docker for Macでも使われています。

次節以降ではminikubeの基本的な使い方を説明します。

minikube start: k8sクラスタ用VMの作成と起動

下記のコマンドを実行すると、CPUコア3つ、メモリ2GBを割り当ててminikube専用のVMインスタンスを起動することができます。

# hyperkitを使う場合
$ minikube start --cpus=3 --memory=2048 --vm-driver=hyperkit --disk-size=12g

# virtualboxを使う場合
$ minikube start --cpus=3 --memory=2048 --vm-driver=virtualbox

このドキュメントで紹介する手順は全て上記の構成で動作を確認しています。

hyperkitを使う場合、--disk-sizeを指定しないと無条件に20GBのファイルが ~/.minikube/machines/minikube/minikube.rawdisk に作成されます。 ホスト側のストレージが足りない場合はこれが原因で起動に失敗することがあるので注意してください。 上記の例では12GB割り当てています。

VirtualBoxを使う場合、ストレージファイルは必要に応じて拡張されていくのでサイズ指定は省略しています。 ストレージの消費量は起動直後で2GB程度です。

minikube dashboard: k8sダッシュボード

下記のコマンドを実行すると、ブラウザでk8sのダッシュボードが開かれます。

$ minikube dashboard

このダッシュボード上では、k8sクラスタ上の各種オブジェクトの状態の確認や編集を行うことができます。

minikube docker-env: VM上のdockerdに接続するための環境変数の表示

minikubeが動作しているVM上でもDockerプロセスが動作しています。

普段 docker image ls などのコマンドを実行するとDocker for MacのDockerプロセスに接続していますが、 下記のようにminikube docker-envで出力される環境変数をロードするとminikube VM上のDockerプロセスに接続することができます。

$ eval $(minikube docker-env)
$ docker image ls
REPOSITORY                                   TAG        IMAGE ID        CREATED        SIZE
k8s.gcr.io/kube-proxy-amd64                  v1.10.0    bfc21aadc7d3    5 weeks ago    97MB
k8s.gcr.io/kube-apiserver-amd64              v1.10.0    af20925d51a3    5 weeks ago    225MB
k8s.gcr.io/kube-controller-manager-amd64     v1.10.0    ad86dbed1555    5 weeks ago    148MB
k8s.gcr.io/kube-scheduler-amd64              v1.10.0    704ba848e69a    5 weeks ago    50.4MB
(省略)

通常、自分でビルドしたイメージをk8s上でコンテナとして起動するためには、何らかのレジストリサービスにそのイメージを登録する必要があるのですが、 このドキュメントでは手順を簡単にするためにminikube VM上のDockerプロセスに直接接続してRailsアプリのイメージをビルドする方法を紹介します。 これについての詳細は次回Kubernetes応用編で説明します。

minikube delete: k8sクラスタ用VMの停止と削除

下記のコマンドを実行すると、k8s用に作成したVMを丸ごと削除します。 気軽にk8sクラスタの初期化を行えるのがminikubeの良いところです。

$ minikube delete

k8sの基本

k8sではコンテナを直接操作することはありません。 DeploymentやServiceなど抽象化されたリソースを介してコンテナの起動や停止を行います。 これらのリソースをk8sではAPIオブジェクトと呼びます(単にオブジェクトと呼ばれることもあります)。

k8sクラスタにAPIオブジェクトを作成したり更新したりする方法には大まかに3つの方法があります。

  1. YAML形式のマニフェストファイルをkubectl apply -fで指定して実行する。
  2. kubectl create deploymentやkubectl run、kubectl exposeなどのコマンドを実行する。
  3. ダッシュボード上のメニューで作成や更新を実行する。

インフラ構成を管理する上で一番望ましいのは、構成をコード化してバージョン管理できる1の方法です。 このドキュメントでは、一部の例外をのぞいて全て1の方法で説明します。

一部の例外というのは以下の二つです。詳細は後述します。

  • TLS証明書用のSecretオブジェクトの作成
  • テストを目的とした対話的な操作のための一時的なコンテナの作成

準備

まずサンプルアプリのコードをチェックアウトしてminikubeを起動してください。

# サンプルアプリのコードをチェックアウト
$ git clone https://github.com/kwhrtsk/rails-k8s-demoapp.git
$ cd rails-k8s-demoapp

# minikubeを起動
$ minikube start --cpus=3 --memory=2048 --vm-driver=hyperkit --disk-size=12g

# kubernetesのダッシュボードをオープン
$ minikube dashboard

APIオブジェクトのマニフェストファイルとkubectlのチュートリアル

この節ではAPIオブジェクトの例としてDeploymentとServiceを取り上げ、 kubectlコマンドを使用してオブジェクトの作成などを行う方法を説明します。

Deploymentの概要

k8sの最も重要なAPIオブジェクトの一つはDeploymentです。 状態を持たないアプリケーションのコンテナはDeploymentオブジェクトによって管理します。

Deploymentオブジェクトを作成すると、その配下へ自動的にReplicaSetとPodというオブジェクトが作成されます。

Podはk8sにおいてコンテナを管理するための最小単位です。多くの場合、コンテナと一対一に対応しています。 (一つのPodに複数のコンテナを入れることもできますが、 それは高度なユースケースであるとドキュメントにも書いてありますし、ここでは取り上げません)

ReplicaSetは、同じ設定で作られたPodがreplicasパラメータで指定された個数だけ維持されるように調整します。

        +--------------+
        |  Deployment  |
        +------+-------+
               |
        +------+-------+
        |  ReplicaSet  |   replicas: 2
        +-+----------+-+
          |          |
      +---+---+  +---+---+
      |  Pod  |  |  Pod  |
      +-------+  +-------+

Deploymentは、ReplicaSetを管理します。 コンテナイメージの更新などを行う際には新しい設定のReplicaSetを作成して、 古いReplicaSetからPodを削除しながら新しいReplicaSetにPodを作成します。

              +--------------+
              |  Deployment  |
              +------------+-+
                :          |
   +------------+-+      +-+----------+-+  
   |  ReplicaSet  |  ->  |  ReplicaSet  |  
   +-+----------+-+      +-+----------+-+  
     |          |          |          |    
 +---+---+  +---+---+  +---+---+  +---+---+
 |  Pod  |  |  Pod  |  |  Pod  |  |  Pod  |
 +-------+  +-------+  +-------+  +-------+

Deploymentのマニフェストファイルの例

以下のYAMLデータはmysql:5.7.21のコンテナを一つ起動するだけのDeploymentのマニフェストファイルです。

# k8s/manifests-step0/mysql-deploy.yaml
---
apiVersion: apps/v1   # このYAMLデータのスキーマバージョン
kind: Deployment      # オブジェクトの種類
metadata:
  name: mysql         # オブジェクトの名前
  labels:             # オブジェクトを選択するために使うラベル(後述)
    app: mysql        # 任意のキー・値を設定して良い
spec:
  replicas: 1         # 起動するPodの数
  selector:           
    matchLabels:      # .spec.template.metadata.labelsと一致させる必要がある
      app: mysql
  template:
    metadata:
      labels:         # ReplicaSetとPodに付けられるラベル
        app: mysql
    spec:
      restartPolicy: Always   # コンテナが死亡した際の対応
      containers:
        - name: mysql         # コンテナのNAME属性に使用
          image: mysql:5.7.21 # コンテナイメージ
          env:                # 環境変数を指定
            - name: MYSQL_ALLOW_EMPTY_PASSWORD
              value: "yes"

簡単な注釈を加えていますが、わかりにくい部分をいくつか補足します。

  • .apiVersion

apps/v1の他に、v1、extensions/v1beta1などの値を取る場合があり、 kindとapiVersionの組み合わせによってYAMLデータの構造が決まります。

各オブジェクトのapiVersionの推奨値はk8sのAPIバージョンによって決まっていて、 例えば2018年5月30日時点で最新のk8sのバージョン1.10では、DeploymentのapiVersionの推奨値はapps/v1になります。

参考: Workloads API changes in versions 1.8 and 1.9 | Kubernetes

  • .metadata.labels

ラベルです。 他のAPIオブジェクトの設定からこのDeploymentを参照する際に使用する場合があります。 また、kubectl getなど一部のCLIツールでオブジェクトをフィルタリングする際にも使用できます。

  • .spec.selector.matchLabels

以前のバージョンでは省略できたのですが、apiVersionがapps/v1になって必須パラメータになりました。 必ず .spec.template.metadata.labels にマッチしている必要があります。 書き方によっては、別のDeploymentで定義したオブジェクトを参照してしまう場合があるので注意が必要です。

  • .spec.template.spec.restartPolicy

コンテナが停止した時に再起動するかどうかを Always, OnFailure, Neverのいずれかで指定します。参考

このファイルはサンプルコードのk8s/manifests-step0/mysql-deploy.yamlに置いてあります。

以降、このマニフェストファイルを使ってkubectlコマンドの基本的な使い方を説明します。

kubectl apply: APIオブジェクトの作成と更新

前述のYAMLファイルを使ってk8sクラスタにDeploymentオブジェクトを作るには下記のようにします。

$ kubectl apply -f k8s/manifests-step0/mysql-deploy.yaml
deployment.apps "mysql" created

複数のYAMLファイルを指定する場合は下記のように標準入力で指定します。

$ cat k8s/manifests-step0/*.yaml | kubectl apply -f -

この際、各オブジェクトの定義が --- で区切られている必要がある点に注意してください。 上記のようにcatで結合しやすいように、あらかじめ各YAMLファイルの先頭に --- を入れておくのが良いと思います。

作成したオブジェクトの設定を更新したい場合は、マニフェストファイルを編集してもう一度同じコマンドを実行します。

以前のバージョンでは、作成はkubectl create -f、更新はkubectl apply -fと使い分けていましたが、現在は両方ともkubectl apply -fを使います。

kubectl get: APIオブジェクトの状態の確認

Deployment、ReplicaSet、Podオブジェクトの状態を確認するには、下記のようにします。

$ kubectl get deployments,replicaset,pods
NAME                          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/mysql   1         1         1            1           1s

NAME                                     DESIRED   CURRENT   READY     AGE
replicaset.extensions/mysql-55fb9dc7db   1         1         1         1s

NAME                         READY     STATUS    RESTARTS   AGE
pod/mysql-55fb9dc7db-5mh8v   1/1       Running   0          1s

kubectl getのパラメータにはAPIオブジェクトの種類を示す文字列を指定しますが、略称がある場合はそれを使えます。

# kubectl get deploymentsと同じ
$ kubectl get deploy

このドキュメントで扱う主要なAPIオブジェクトの略称は下記の通りです。

名称 略称
deployments deploy
configmaps cm
deployments deploy
ingresses ing
jobs 無し
namespaces ns
persistentvolumeclaims pvc
persistentvolumes pv
pods po
replicasets rs
secrets 無し
services svc
storageclasses sc

完全なリストはパラメータ無しで kubectl get を実行すると表示されます。

kubectl logs (またはstern): コンテナのログの確認

コンテナのログを確認するには、オブジェクトの種類とNAMEを指定して下記のようにします。 NAMEは前述のkubectl getで確認できます。

# Deploymentを指定する場合
$ kubectl logs deployments/mysql

# ReplicaSetを指定する場合
$ kubectl logs replicasets/mysql-55fb9dc7db

# Podを指定する場合
$ kubectl logs pods/mysql-55fb9dc7db-5mh8v

これはdocker container logs相当の機能です。コンテナの標準出力と標準エラー出力の履歴を確認できます。

Podを指定する場合、マニフェストファイルで設定したラベル(.spec.template.metadata.labels)の値を使って、下記のように指定できます。

$ kubectl logs --selector "app=mysql"

# ラベルが複数ある場合はカンマ区切りでAND指定
$ kubectl logs --selector "app=demoapp,component=mysql"

ログの閲覧は stern を使うともっと簡単です。 Podの名前に対して正規表現でマッチさせることができ、複数のPodのログを一度にtailすることができます。

$ stern "mysql.*"

kubectl port-forward: コンテナのポートをホスト側にポートフォワード

Docker ComposeではportsエントリをYAMLファイルに書いておくだけでコンテナのポートをホスト側にマッピングすることができましたが、 k8sではクラスタの外側からコンテナに接続するためにはServiceやIngressなど別のAPIオブジェクトを設定する必要があります。

ただし、kubectl port-forwardコマンドを使うと、 k8sクラスタのノードにsshで接続して特定のコンテナのポートをホストOSにポートフォワードすることができます。 このコマンドではDeploymentまたはPodの名前をパラメータに指定する必要があります。

# Deploymentを指定する場合
$ kubectl port-forward deployment/mysql 3306:3306

# TYPEを省略するとPodを指定したことになる
$ kubectl port-forward mysql-55fb9dc7db-5mh8v 3306:3306

ポート番号は左側がホスト側のポートです。コンテナとホストのポートが同じ場合は3306のように番号を一つだけ指定することもできます。

別のターミナルで下記のコマンドを実行すると、k8s上のmysqlコンテナに接続することができます。 オブジェクトの起動直後はエラーになる場合があるので、数秒待ってから試してみてください。

$ mysql -u root --host 0.0.0.0 --port 3306

Podの名前を指定する場合は、下記のようにするとラベルでオブジェクトを選択することができます。

$ kubectl port-forward $(kubectl get pods --selector "app=mysql" --output "jsonpath={.items..metadata.name}") 3306

kubectl delete: APIオブジェクトの削除

kubectl apply -fで指定したファイルを指定してオブジェクトを削除することができます。

$ kubectl delete -f k8s/manifests-step0/mysql-deploy.yaml

Serviceの概要

k8sの最も重要なAPIオブジェクトのもう一つはServiceです。

前節ではmysqlコンテナを管理するDeploymentの例を示しましたが、 別のPodからこのMySQLサーバにアクセスするためにはPodのIPアドレスとポートを指定する必要があります。 PodのIPアドレスは起動するたびに変わってしまうので、アプリケーションの設定に記述することはできません。

Serviceオブジェクトを作ると、ラベルで指定したPod群へアクセスできるIPアドレスとDNS名がk8sによって用意されます。

前節のmysqlのDeploymentに対応するService定義の例を示します。

# k8s/manifests-step0/mysql-svc.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 3306     # 接続するPod側のポートを指定
  selector:          # 接続するPodのラベルを指定
    app: mysql

上記のマニフェストをkubectl applyで実行してServiceオブジェクトを作ると、 k8sクラスタ上のコンテナ上ではServiceオブジェクトの名前である"mysql"という文字列をホスト名として指定することで mysqlのDeploymentが管理しているPodにアクセスできるようになります。

.spec.typeにはClusterIP、NodePort、LoadBalancer、ExternalNameのいずれかを指定します。 ClusterIPは、このServiceオブジェクトが作るエンドポイントがk8sクラスタの内部向けであることを意味します。 k8sクラスタの外側からアクセスできるようなエンドポイントを作る場合にはNodePortまたはLoadBalancerを指定します。 このドキュメントでは、最終的にはIngressオブジェクトを使用して外部向けのエンドポイントを用意するため、 NodePortやLoadBalancerの詳細については割愛します。 また、ExternalNameを使うとk8sの外側のサービスのエイリアスを作ることができますが、このドキュメントでは扱いません。

kubectl run: コマンドによるDeploymentの作成

インフラ構成管理の観点からは全てのDeploymentはマニフェストファイルで管理するのが望ましいのですが、 k8sクラスタ上に一時的なコンテナを作成して簡単なオペレーションを実行したい時もあります。

そのような場合にはkubectl runコマンドを使うとYAMLファイル無しでDeploymentを作成することができ便利です。 フォアグラウンドで対話的なコマンドを実行することもできるため、トラブルシュートにも最適です。

利用例として、前節までに紹介したmysql用のDeploymentとServiceを作成した後、 kubectl runコマンドでシェルを起動し、Serviceによって用意されたエンドポイント経由でMySQLサーバに接続する方法を示します。

まずmysqlのDeploymentとServiceを作成します。

$ kubectl apply -f k8s/manifests-step0/mysql-deploy.yaml
deployment.apps "mysql" created

$ kubectl apply -f k8s/manifests-step0/mysql-svc.yaml
service "mysql" created

$ kubectl get deployments,replicasets,pods,services
NAME                          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/mysql   1         1         1            1           9s

NAME                                    DESIRED   CURRENT   READY     AGE
replicaset.extensions/mysql-b59b886c9   1         1         1         9s

NAME                        READY     STATUS    RESTARTS   AGE
pod/mysql-b59b886c9-955tg   1/1       Running   0          9s

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP    1d
service/mysql        ClusterIP   10.110.107.218   <none>        3306/TCP   4s

service/kubernetesはシステム標準のServiceです。 service/mysqlというServiceオブジェクトが作成されているのを確認できます。

次に下記のコマンドで新たにmysql:5.7.21イメージのDeploymentを作成します。 コンテナの中ではmysqldコマンドの代わりに対話モードでbashを起動して、プロンプトからMySQLサーバに接続します。

$ kubectl run mysql-client --image=mysql:5.7.21 -it --rm --restart=Never /bin/bash
If you don't see a command prompt, try pressing enter.
root@mysql-client:/#

上記のようにシェルのプロンプトが表示されたらmysqlコマンドを入力してください。

root@mysql-client:/# mysql -u root --host mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.21 MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

MySQLサーバに接続できました。kubectl runコマンドのパラメータの意味は次の通りです。

  • mysql-clientはDeploymentの名前です。
  • --imageはコンテナのイメージ名です。
  • -itオプションはdocker container run(旧 docker run)コマンドと同じ意味です。
  • --rmオプションを指定すると、コマンドの終了時に自動的にDeployment削除されます。
  • --restart=NeverをつけておかないとDeploymentが削除されるまでのわずかな間にPodが再起動されるケースがあり、動作がやや不安定になります。

kubectl explain: ドキュメントの表示

すでに見てきたように、マニフェストファイルは結構複雑な構造のYAMLデータです。 慣れないうちはリファレンスを見ながら書くことになると思いますが、 公式サイトのドキュメントは個々の機能の解説に注力しているため、 今ひとつマニフェスト定義自体の全貌をつかむことができません。

マニフェストの構造を確認するためにはAPIのリファレンスを参照する方が確実です。

また、kubectlには指定したオブジェクトのAPIリファレンスを参照する機能があります。 Webよりもこちらの方が便利かもしれません。

$ kubectl explain --api-version=apps/v1 deployment
KIND:     Deployment
VERSION:  apps/v1

DESCRIPTION:
     Deployment enables declarative updates for Pods and ReplicaSets.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object metadata.

   spec <Object>
     Specification of the desired behavior of the Deployment.

   status       <Object>
     Most recently observed status of the Deployment.

オブジェクトの名前に続けて.区切りでフィールドを指定するとネストした要素のドキュメントを参照できます。 また、オブジェクトの名前はkubectl getと同じ略称を使うことができます。

$ kubectl explain --api-version=apps/v1 deployment.spec.template.spec.containers.resources
KIND:     Deployment
VERSION:  apps/v1

RESOURCE: resources <Object>

DESCRIPTION:
     Compute Resources required by this container. Cannot be updated. More info:
     https://kubernetes.io/docs/concepts/storage/persistent-volumes#resources

     ResourceRequirements describes the compute resource requirements.

FIELDS:
   limits       <map[string]string>
     Limits describes the maximum amount of compute resources allowed. More
     info:
     https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

   requests     <map[string]string>
     Requests describes the minimum amount of compute resources required. If
     Requests is omitted for a container, it defaults to Limits if that is
     explicitly specified, otherwise to an implementation-defined value. More
     info:
     https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

参考情報

Kubernetesのより詳細な情報は下記のドキュメントを参照してください。

  • APIリファレンス(v1.10)
    • マニフェストのスキーマに関する網羅的な定義はここが詳しいです。
  • Concepts | Kubernetes
    • メニューが階層化しているため慣れるまでわかりにくいですが、各種APIオブジェクトの解説はここが公式なドキュメントです。 今回のドキュメントで取り上げたオブジェクトのドキュメントを挙げておきます。
    • Deployments
    • ReplicaSet
    • Pods
    • Services
  • kubectl Cheat Sheet | Kubernetes
    • kubectlコマンドのチートシートです。1度目を通しておくと引き出しが増えるのでおすすめです。

おすすめの書籍はこの2冊です。

一冊めの「プログラマのためのDocker教科書」は前回の記事でも紹介した書籍です。 おおよそ2章分と比較的大きく紙面を割いてKubernetesの概要と基礎的なAPIオブジェクトの説明がわかりやすく書いてあります。 また、GCP上で開発を行う方法がコードの管理からイメージのビルドまで丁寧に説明してあり、付録でGCPの使い方まで説明されていて手厚いです。

一方、Podの死活監視の設定やServiceによるサービスディスカバリの詳細など、少し踏み込んだ内容は大胆に省略してあります。 もう少し詳しい仕組みを知りたい場合は二冊目の「入門Kubernetes」で補うのが良いと思います。 これ一冊で入門するのは正直しんどいと思うのですが、ある程度知識を持った状態で読むのであればおすすめです。

次回は Kubernetes基礎編 です。