Kubernetes Advent Calendar 2016 13日目

Kubernetesの主な機能一覧 (v1.5時点)

kubernetes
165

10
いいね
0
コメント

tkusumi

2016年12月13日に更新

この記事はKubernetes Advent Calendar 2016の13日目の記事です。ちょうどこの記事の投稿日(12/13)に Kubernetes v1.5.0がリリースされました

日夜、進化し機能が増えているKubernetesについて、開発中のものも含めv1.5時点での主な機能の一覧をまとめてみました。

スケーラビリティ関連

クラスタリング機能

Kubernetesのクラスタリング機能はマスターコンポーネント(kube-apiserver,etcd,kube-scheduler,kube-controller-manager)とNodeコンポーネント(kubelet,kube-proxy)から構成されます。

クラスタが対応するノード数に関してはKubeCon 2016でMarek Grabowskiさんが発表した2000 Nodes and Beyond: How We Scaled Kubernetes to 60,000-Container Clusters and Where We're Going Nextというセッションの資料がまとまっています。

Kubernetesの構造上、各種コンポーネントはAPIサーバーを参照して処理を行うため、スケーラビリティの向上は主にAPIサーバーを中心に行われています。

2000 Nodes and Beyond のスライドより引用

2000 Nodes and Beyondのスライドによると、Kubernetesのバージョンごとの対応するノード数は下記のようになっています。

バージョン	対応ノード数	主な取り組み
v1.0	100	内部の型変換(versioned -> unversioned)をreflectからコード生成にした
v1.1	250	APIサーバーのetcdのwatchを1キーにつき1watchにまとめるようにした(cacher層)
v1.2	1,000	kubemarkというベンチマークができた
v1.3	2,000	APIサーバーの通信で内部クライアントはjsonからprotobufを使うようになった
v1.4	2,000
v1.5	?	etcd v2からv3への移行が予定されていたが見送りに

参考

複数クラスタ連携 (Federated Kubernetes)

Federated Kubernetesは複数のKubernetesを連携させる機能です。Ubernetes("uber-"は"超える"の意味の接頭辞)とも呼ばれます。AWS, GCPなどのクラウドプロバイダーやAvaiability Zoneをまたがってクラスタを連携させることで、可用性の向上やクラスタサイズの拡張を実現することができます。鋭意開発が進められており、v1.5でもDeployment, ConfigMapなどのリソースが対応されました。

@toshitanianさんが書かれたKubernetes Federationの今とこれからという記事が素晴らしくまとまっています。

参考

アプリケーションの水平オートスケール (HorizontalPodAutoscaler)

HorizontalPodAutoscalerという機能によりアプリケーションの水平(horizontal)オートスケールがサポートされます。アプリケーション(Pod)の数がCPU使用率等の計測値を用いて自動的に調整される機能です。計測値はデフォルトで用意されるCPU使用率の他、alpha機能で独自のメトリクスを使用することができます。

将来的にはアプリケーションの垂直(Vertical)スケールの機能も考えられているようです。垂直スケールの必要性に関してはKubeCon 2016でKubernetesのコア開発者であるTim Hockinさんが発表したEverything You Ever Wanted To Know About Resource Scheduling... Almostが詳しいです。

参考

アプリケーションのデプロイ・実行

アプリケーションの単位の提供 (Pod)

PodはKubernetesでアプリケーションを動かす最小単位で、Kubernetesの一番基本となるリソースです。同じプロセス空間、ネットワーク、ストレージを共有する1つ以上のコンテナから構成されます。これによりログコレクタのような補助プロセスを含めて1つのアプリケーションとしてデプロイすることができます。

What is a pod?

アプリケーションのレプリカ数管理 (ReplicationController / ReplicaSet)

ReplicationController及びReplicaSetはアプリケーション(Pod)のレプリカ数を管理するための仕組みです。クラスタで動くPodの数をユーザーが望むレプリカ数(desired state)に近づける形で動作します。オートヒーリングの仕組みもこの機能で実現しています。

ReplicationControllerとReplicaSetの違いは現状ほとんどなく、ReplicationControllerという名前が長く、リソース名にcontrollerとついて紛らわしいといったことからReplicaSetが作られました。

参考

ローリングアップデートなどのデプロイ管理 (Deployment)

Deploymentはデプロイを管理する仕組みでローリングアップデートやロールバックの機能を提供します。内部的にはReplicaSetを使用しており、ローリングアップデートは新旧2つのReplicaSetを作って切り替えていく形を取っています。

参考

What is a Deployment?

ステートフルアプリケーションの管理 (StatefulSet)

StatefulSet(v1.4まではPetSet)はステートフルアプリケーションをサポートするための機能です。ReplicaSetと違って管理するPodの1つづつがそれぞれの名前と状態を持てることになります。具体的にはetcdやzookeeperのようにそれぞれのメンバー(Pod)が状態を持ち識別が必要なアプリケーションをデプロイする場合が想定されています。

なおPetSetからStatefulSetに名前が変更された経緯はPlease consider changing the name of PetSet before General Availability #27430というissueで議論されていました。

参考

ノード毎のデーモンのデプロイ管理 (DaemonSet)

DaemonSetはクラスタの各ノードで特定のデーモンを実行する機能です。例えばcephのようなストレージのデーモンや、fluentdのようなログコレクタ、linkerdのような透過プロクシーなどをノードごとに動かす場合に利用します。

参考

What is a Daemon Set?
linkerd: RUNNING IN KUBERNETES WITH DAEMONSETS

ジョブ・バッチ処理 (Job)

Jobは単独のジョブ処理(明示的な終了がある処理)を行うための機能です。

What is a job?

スケジュールジョブ (CronJob)

CronJob(v1.4まではScheduledJob)を使うとcronのようなスケジュールに基づく処理を実行することができます。

@koudaiiiさんのCronJob(ScheduledJob)の記事がとてもよくまとまっています。

ネットワーク・サービス提供

サービスディスカバリ & ロードバランシング (Service / KubeDNS / kube-proxy)

Serviceはクラスタ内のサービスディスカバリとロードバランシングを提供する機能です。ServiceはPodをLabelとSelectorという仕組みで選択し、配下のPod群に対してロードバランスする仮想的なIPアドレス(ClusterIP)を提供します。また内部のDNS(KubeDNS)に自動的にドメインの登録を行いサービスディスカバリの機能を提供します。

ロードバランシングはノード毎にデーモンとして動くkube-proxyがServiceの情報をiptablesに設定することで実装されています(デフォルトの挙動)。そのため通常の構成ではClusterIPはクラスタの外部から通信を受けることはできません。クラスタ外部からの通信を受けるには通常Serviceのtype=LoadBalancerの指定か、IngressリソースによるL7ロードバランサなどの設定が必要になります。

クラウドプロバイダのL4ロードバランサとの連携(Service.Type=LoadBalancer)

Serviceのtype=LoadBalancerの指定により外部のL4ロードバランサによってサービスを公開することができます。この指定がなされると、自動的にServiceに連携したクラウドプロバイダ(AWS, GCPなど)ごとのロードバランサが作られます。

参考

Services#type-loadbalancer

L7ロードバランサとの連携 (Ingress)

Ingressはクラスタ外部(主にインターネット)からの通信を受けるL7ロードバランサに必要となる設定情報をリソースとして表現する機能になります。

    internet
        |
   [ Ingress ]
   --|-----|--
   [ Services ]

Service.Type=LoadBalancerとの主な違いは下記になります

L7ロードバランサであること(Service.Type=LoadBalancerはL4)
- ホスト名やパスによるルーティング、TLS終端が可能
Ingress自体はリソースとしてL7ロードバランサの情報をリソースとして表現するだけのもの
- 実際のロードバランサの設定はIngress ControllerというIngressリソースを監視する別の仕組みで行われる
- これによりロードバランサの情報と具体的なロードバランサが分離される

Ingress Controllerの実装としては下記のようなものがあります

nghttpx Ingress Controller
Nginx Ingress Controller
HTTP Load Balancer (Google Container Engine)

参考

What is Ingress?

プラガブルなネットワーク機能 (CNI)

KubernetesのネットワークはContainer Network Interface(CNI)というコンテナネットワークの共通インタフェースをプラグインとしてサポートしています。Canal(Calico, Flannel), Weave Netなどのネットワークプラグインが存在します。

参考

ネットワークポリシーの制御 (NetworkPolicy)

NetworkPolicyはNamespaceごとのネットワーク設定や、Podのアクセス制御の機能を提供します。KubernetesのネットワークがNetworkPolicyをサポートしない場合はこの設定は無視されます。

マニュアルの例(Namespaceごとのネットワーク設定)

kind: Namespace
apiVersion: v1
metadata:
  # アノテーションで分離の設定をいれる
  annotations:
    # 全てのPod外からの通信を拒否する。1.5時点でのサポートはDefaultDenyだけ
    net.beta.kubernetes.io/network-policy: |
      {
        "ingress": {
          "isolation": "DefaultDeny"
        }
      }

マニュアルの例(NetworkPolicy)

kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: access-nginx
spec:
  # 制限する対象
  podSelector:
    matchLabels:
      run: nginx
  ingress:
    # 許可する対象
    - from:
      - podSelector:
          matchLabels:
            access: "true"

参考

Network Policies

リソース管理

Podのリソース制御 (requests, limits)

spec.containers[].resourcesのrequests, limitsの指定によってPodのリソース(現状はCPUとメモリ)の制御が行えます。requestsは最低限確保して欲しい値を指定し、limitsは使用できる最大の値を指定します。

以下はマニュアルの例より

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    # リソース制御の指定
    resources:
      # 最低限確保してほしいCPU、メモリ
      requests:
        memory: "64Mi"
        # 0.25コア分
        cpu: "250m"
      # 使用できる最大の値
      limits:
        # メモリの場合はこれを超えるとターミネートされる
        memory: "128Mi"
        cpu: "500m"
  # 以下省略

Resource Requests and Limits of Pod and Container

Namespaceのリソース制御 (ResourceQuota)

ResourceQuotaはNamespace単位でのリソース制御の仕組みを提供します。CPU、メモリのリソースの他に、オブジェクトの数(PodやServiceの数)をNamespaceごとに設定することができます。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    # リソース数の制限(ここではPod数)
    pods: "4"
    # 最低限確保してほしいCPU、メモリ
    requests.cpu: "1"
    requests.memory: 1Gi
    # 使用できるCPU、メモリの最大値
    limits.cpu: "2"
    limits.memory: 2Gi

利用状況はkubectl describe ns NAMESPACEで以下のように確認することができます。

$ kubectl describe ns myspace
Name:   myspace
Labels: <none>
Status: Active

Resource Quotas
 Name:                  compute-resources
 Resource               Used    Hard
 --------               ---     ---
 limits.cpu             0       2
 limits.memory          0       2Gi
 pods                   0       4
 requests.cpu           0       1
 requests.memory        0       1Gi

No resource limits.

参考

Understanding Resource Quotas

設定管理

シークレット管理 (Secret)

Secretはパスワードや秘密鍵といった秘密情報を扱うための機能です。Secretを使うことでアプリケーションの定義に秘密情報を含まなくてよくなります。またアプリケーションからAPIサーバーにアクセスするためのServiceAccountのクレデンシャルにもSecretが使われており、これはVolumeとして自動的にマウントされるようになっています。

Overview of Secrets

設定情報管理 (ConfigMap)

ConfigMapはアプリケーションの定義と別に設定情報を管理するための機能です。設定情報はPodに対して環境変数、、ファイル(Volume)、コンテナ引数といった形で渡すことができます。

認証・認可

認証

Kubernetesは下記のようないろいろなユーザ認証方式を提供しています。Kubernetes自体はユーザは管理しておらず(ServiceAccountは除く)、認証方法ごとに取得するユーザ名をそのまま利用する形を取っています。

方法	備考
X509 Client Certs	クライアント証明書。`CN`がユーザ名、`O`がグループになります。例: `/CN=jbeda/O=app1/O=app2`
Static Token File	トークン認証。CSVで定義します。`Authorization: Bearer $TOKEN`ヘッダで認証。
Static Password File	Basic認証。CSVで定義します。
Service Account Tokens	ServiceAccountのJWT形式のトークン認証。
OpenID Connect Tokens	OIDCのID Tokenによる認証。
Webhook Token Authentication	外部のWebAPIによる認証。
Authenticating Proxy	認証プロクシーを前段においてヘッダでユーザ名が渡される方式
Keystone Password	Openstack Keystoneを使ったBasic認証。

参考

Users in Kubernetes

認可

Kubernetesでは認可も下記のように複数の方式が提供されています。認証されたユーザが何ができるかを管理する機能です。

方法	備考
AlwaysDeny	全て否認。テスト用です。
AlwaysAllow	全て承認。AlwaysAllowの設定です。認可が不要な場合に使います
ABAC	Attribute-Based Access Control。属性によるアクセス制御。Policyファイルによる静的な定義になるため、反映には再起動が必要です
RBAC	Roles-Based Access Contro。ロールによるアクセス制御。リソースを使った動的な管理が可能です
Webhook	外部のWebAPIによる認可。

参考

ヘッドレスアカウント (ServiceAccount)

Kubernetesでは人に対する認証の他に、アプリケーションなど人を介さない(ヘッドレス)場合の認証としてServiceAccountという仕組みが用意されています。例えばKubernetes DashboardのようなアプリケーションがAPIサーバーとやり取りする場合にServiceAccountが使われています。

NamespaceごとにdefaultというServiceAccountが作られている他、kubectl create serviceaccountで独自のServiceAccountを作ることができます。

参考

Using the Default Service Account to access the API server

APIサーバーのリクエスト制御 (AdmissionControl)

Admission ControlはKubernetesのAPIサーバーのリクエスト制御の機能です。APIリクエストに対して認証、認可を行ったあとのフェーズで、別途そのリクエストを受け入れるか制御を行います。また場合によって、リクエストの変更や別の操作を行います。

プラグイン形式で複数の制御の方法が用意されており、APIの起動オプション--admission-controlで有効にしたいものをカンマ区切りで指定します。

v1.5では下記のプラグインが用意されています。

AlwaysAdmit
AlwaysDeny
AlwaysPullImages
DefaultStorageClass
DenyEscalatingExec
DenyExecOnPrivileged
ImagePolicyWebhook
InitialResources
LimitPodHardAntiAffinityTopology
LimitRanger
NamespaceAutoProvision
NamespaceExists
NamespaceLifecycle
OwnerReferencesPermissionEnforcement
PersistentVolumeLabel
PodNodeSelector
PodSecurityPolicy
ResourceQuota
SecurityContextDeny
ServiceAccount

参考

セキュリティ

セキュリティ設定(SecurityContext)

SecurityContext, PodSecurityContext はContainer、Podに対して下記のセキュリティの設定を可能にします。

Podに対する設定 (PodSecurityContext)

seLinuxOptions SELinuxのオプション
runAsUser 実行するユーザのUID
runAsNonRoot rootで動かさないことを保証する (デフォルトfalse)
seLinuxContext SE Linuxのコンテキスト
supplementalGroups Supplemental Groupの指定
fsGroup ファイルシステムのGroupの指定

コンテナに対する設定 (SecurityContext)

capabilities Linuxのcapabilitiesの設定
privileged 特権モードで動かすかどうか (デフォルトfalse)
seLinuxOptions SELinuxのオプション
runAsUser 実行するユーザのUID
runAsNonRoot rootで動かさないことを保証する (デフォルトfalse)
readOnlyRootFilesystem read-onlyのルートファイルシステムかどうか (デフォルトfalse)

参考

Podのセキュリティポリシーの強制 (PodSecurityPolicy)

PodSecurityPolicyはPodに対してセキュリティポリシーを強制する機能です。AdmissionControlでPodSecurityPolicyプラグインを有効にすることで、下記のようなポリシーを全てのPodに強制することができます。

runAsUser 実行するユーザのUID
seLinuxContext SE Linuxのコンテキスト
supplementalGroups Supplemental Groupの指定
fsGroup ファイルシステムのGroupの指定
volumes 使えるボリュームの種別の制限

参考

What is a Pod Security Policy?

コンテナイメージのポリシー制御 (ImagePolicyWebhook)

ImagePolicyWebhookはKubernetesクラスタ上で動かすコンテナイメージを独自に制御したい場合に使える仕組みです。下記のようなユースケースが想定されているようです。

既知の脆弱性を含まないことを確認されたイメージだけを動かしたい
特定のベースイメージを使ったイメージだけを動かしたい
レビュー済みのコードでビルドされたイメージだけを動かしたい
署名されたイメージだけを動かしたい

Image Policy Webhookは、ユーザが定義するWebAPIに対してそのPodに含まれるコンテナイメージの情報を渡し、実行可否をチェックする仕組みです。コンテナイメージ制御自体は自前のWebAPIで行う必要があります。Admission ControllerプラグインImagePolicyWebhookとして実装されています。

参考

Kubernetes: Image Policy Webhookとは

外部システムとの連携

クラウドプロバイダの対応 (cloudprovider)

Kubernetesはクラウドプロバイダ(AWS, GCPなど)のロードバランサやインスタンス情報と連携する機能を持っています。v1.5時点では下記のクラウドプロバイダの実装が用意されています。

Amazon Web Services
Microsoft Azure
CloudStack
Google Compute Engine
Mesos
OpenStack
oVirt
Photon
Rackspace
vSphere

cloudproviderには下記のインタフェースが定義されており、プロバイダごとにこれを実装する形になっています。サポート状況はプロバイダによって異なります。

// Interface is an abstract, pluggable interface for cloud providers.
type Interface interface {
    // LoadBalancer returns a balancer interface. Also returns true if the interface is supported, false otherwise.
    LoadBalancer() (LoadBalancer, bool)
    // Instances returns an instances interface. Also returns true if the interface is supported, false otherwise.
    Instances() (Instances, bool)
    // Zones returns a zones interface. Also returns true if the interface is supported, false otherwise.
    Zones() (Zones, bool)
    // Clusters returns a clusters interface.  Also returns true if the interface is supported, false otherwise.
    Clusters() (Clusters, bool)
    // Routes returns a routes interface along with whether the interface is supported.
    Routes() (Routes, bool)
    // ProviderName returns the cloud provider ID.
    ProviderName() string
    // ScrubDNS provides an opportunity for cloud-provider-specific code to process DNS settings for pods.
    ScrubDNS(nameservers, searches []string) (nsOut, srchOut []string)
}

https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider

永続ストレージ連携(PersisntentVolume / PersisntentVolumeClaim)

PersistentVolumeは永続ストレージとの連携する機能を提供します。Kubernetes v1.5時点では下記のストレージに対応しています。

awsElasticBlockStore
azureDisk
azureFile
cephFS
cinder (OpenStack block storage)
fc (Fibre Channel)
flexVolume
flocker
gcePersistentDisk
glusterfs
hostPath (Nodeのホストのパス)
iscsi
nfs
photonPersistentDisk
quobyte
rbd (Ceph Block Device)
vsphereVolume

参考

拡張性

独自のリソース定義(ThirdPartyResource)

ThirdPartyResourceはユーザが独自のKubernetesのリソースを定義できる機能です。Kubernetesのリソース管理の仕組みをそのままフレームワークとして利用することができます。高度なアプリケーションの運用を実現するCoreOSのOperatorや、同じくCoreOSのOpenID Connect Provider dexのデータストアなど活用例が増えてきました。

ThirdPartyResourceの詳細については @shmurata さんのフレームワークとしての Kubernetesという記事がよくまとまっています。

おわりに

機能をまとめてみて改めてKubernetesの機能の多さに驚かされました。引き続きKubernetesの発展に注目していきたいと思います。

この記事は[Kubernetes Advent Calendar 2016](http://qiita.com/advent-calendar/2016/kubernetes)の13日目の記事です。ちょうどこの記事の投稿日(12/13)に [Kubernetes v1.5.0](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v150)がリリースされました :tada:

日夜、進化し機能が増えているKubernetesについて、開発中のものも含めv1.5時点での主な機能の一覧をまとめてみました。

# スケーラビリティ関連

## クラスタリング機能

Kubernetesのクラスタリング機能はマスターコンポーネント(`kube-apiserver`,`etcd`,`kube-scheduler`,`kube-controller-manager`)とNodeコンポーネント(`kubelet`,`kube-proxy`)から構成されます。

クラスタが対応するノード数に関してはKubeCon 2016でMarek Grabowskiさんが発表した[2000 Nodes and Beyond: How We Scaled Kubernetes to 60,000-Container Clusters and Where We're Going Next](https://schd.ws/hosted_files/cnkc16/57/KubeCon%202016%20Scalability%20slides%20%283%29.pdf)というセッションの資料がまとまっています。

> [2000 Nodes and Beyond](https://schd.ws/hosted_files/cnkc16/57/KubeCon%202016%20Scalability%20slides%20%283%29.pdf) のスライドより引用
> ![image](https://qiita-image-store.s3.amazonaws.com/0/100377/559555fc-bd8b-9b35-0596-be034a9557e8.png)

[2000 Nodes and Beyond](https://schd.ws/hosted_files/cnkc16/57/KubeCon%202016%20Scalability%20slides%20%283%29.pdf)のスライドによると、Kubernetesのバージョンごとの対応するノード数は下記のようになっています。

バージョン | 対応ノード数 | 主な取り組み
--- | --- | ---
v1.0 | 100 | 内部の型変換(versioned -> unversioned)をreflectからコード生成にした
v1.1 | 250 | APIサーバーのetcdのwatchを1キーにつき1watchにまとめるようにした(cacher層)
v1.2 | 1,000 | kubemarkというベンチマークができた
v1.3 | 2,000 | APIサーバーの通信で内部クライアントはjsonからprotobufを使うようになった
v1.4 | 2,000  |
v1.5 | ? | etcd v2からv3への移行が予定されていたが見送りに

参考

- [Kubernetes architecture](https://github.com/kubernetes/kubernetes/blob/master/docs/design/architecture.md)
- [2000 Nodes and Beyond: How We Scaled Kubernetes to 60,000-Container Clusters and Where We're Going Next](https://schd.ws/hosted_files/cnkc16/57/KubeCon%202016%20Scalability%20slides%20%283%29.pdf)
- [etcd v3 as storage backend for APIServer #44](https://github.com/kubernetes/features/issues/44)
- [Kubernetes: 構成コンポーネント一覧](http://qiita.com/tkusumi/items/c2a92cd52bfdb9edd613)
- [Kubernetes: コンテナが起動するまでの各コンポーネントの流れ](http://qiita.com/tkusumi/items/346d41a6240590b899cd)

## 複数クラスタ連携 (Federated Kubernetes)

Federated Kubernetesは複数のKubernetesを連携させる機能です。Ubernetes("uber-"は"超える"の意味の接頭辞)とも呼ばれます。AWS, GCPなどのクラウドプロバイダーやAvaiability Zoneをまたがってクラスタを連携させることで、可用性の向上やクラスタサイズの拡張を実現することができます。鋭意開発が進められており、[v1.5](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v150)でも`Deployment`, `ConfigMap`などのリソースが対応されました。

@toshitanianさんが書かれた[Kubernetes Federationの今とこれから](http://tech-blog.abeja.asia/entry/Kubernetes-federation)という記事が素晴らしくまとまっています。

参考

- [Kubernetes Federationの今とこれから](http://tech-blog.abeja.asia/entry/Kubernetes-federation)
- [Federation User Guide](http://kubernetes.io/docs/user-guide/federation/)

## アプリケーションの水平オートスケール (HorizontalPodAutoscaler)
`HorizontalPodAutoscaler`という機能によりアプリケーションの水平(horizontal)オートスケールがサポートされます。アプリケーション(`Pod`)の数がCPU使用率等の計測値を用いて自動的に調整される機能です。計測値はデフォルトで用意されるCPU使用率の他、alpha機能で独自のメトリクスを使用することができます。

将来的にはアプリケーションの垂直(Vertical)スケールの機能も考えられているようです。垂直スケールの必要性に関してはKubeCon 2016でKubernetesのコア開発者であるTim Hockinさんが発表した[Everything You Ever Wanted To Know About Resource Scheduling... Almost](https://speakerdeck.com/thockin/everything-you-ever-wanted-to-know-about-resource-scheduling-dot-dot-dot-almost)が詳しいです。

参考

- [What is Horizontal Pod Autoscaling?](http://kubernetes.io/docs/user-guide/horizontal-pod-autoscaling/)
- [Vertical pod auto-sizer #10782](https://github.com/kubernetes/kubernetes/issues/10782)

# アプリケーションのデプロイ・実行
## アプリケーションの単位の提供 (Pod)

`Pod`はKubernetesでアプリケーションを動かす最小単位で、Kubernetesの一番基本となるリソースです。同じプロセス空間、ネットワーク、ストレージを共有する1つ以上のコンテナから構成されます。これによりログコレクタのような補助プロセスを含めて1つのアプリケーションとしてデプロイすることができます。

- [What is a _pod_?](http://kubernetes.io/docs/user-guide/pods/)

## アプリケーションのレプリカ数管理 (ReplicationController / ReplicaSet)

`ReplicationController`及び`ReplicaSet`はアプリケーション(`Pod`)のレプリカ数を管理するための仕組みです。クラスタで動く`Pod`の数をユーザーが望むレプリカ数(desired state)に近づける形で動作します。オートヒーリングの仕組みもこの機能で実現しています。

`ReplicationController`と`ReplicaSet`の違いは現状ほとんどなく、`ReplicationController`という名前が長く、リソース名にcontrollerとついて紛らわしいといったことから`ReplicaSet`が作られました。

参考

- [What is a _replication controller_?](http://kubernetes.io/docs/user-guide/replication-controller/)
- [What is a _Replica Set_?](http://kubernetes.io/docs/user-guide/replicasets/)
- [Create ReplicaSet #3024](https://github.com/kubernetes/kubernetes/issues/3024)
- [Kubernetes: コンテナが起動するまでの各コンポーネントの流れ](http://qiita.com/tkusumi/items/346d41a6240590b899cd)

## ローリングアップデートなどのデプロイ管理 (Deployment)

`Deployment`はデプロイを管理する仕組みでローリングアップデートやロールバックの機能を提供します。内部的には`ReplicaSet`を使用しており、ローリングアップデートは新旧2つの`ReplicaSet`を作って切り替えていく形を取っています。

参考

- [What is a _Deployment_?](http://kubernetes.io/docs/user-guide/deployments/)

## ステートフルアプリケーションの管理 (StatefulSet)

`StatefulSet`(v1.4までは`PetSet`)はステートフルアプリケーションをサポートするための機能です。`ReplicaSet`と違って管理するPodの1つづつがそれぞれの名前と状態を持てることになります。具体的にはetcdやzookeeperのようにそれぞれのメンバー(Pod)が状態を持ち識別が必要なアプリケーションをデプロイする場合が想定されています。

なお`PetSet`から`StatefulSet`に名前が変更された経緯は[Please consider changing the name of PetSet before General Availability #27430](https://github.com/kubernetes/kubernetes/issues/27430)というissueで議論されていました。

参考

- [What is a PetSet?](http://kubernetes.io/docs/user-guide/petset/)
- [Kubernetes 1.3の変更点(予定)#PetSet(ステートフルアプリのサポート)の追加 (alpha)](http://qiita.com/tkusumi/items/f64fff37a724b86d9819#petset%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%95%E3%83%AB%E3%82%A2%E3%83%97%E3%83%AA%E3%81%AE%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%AE%E8%BF%BD%E5%8A%A0-alpha)

## ノード毎のデーモンのデプロイ管理 (DaemonSet)

`DaemonSet`はクラスタの各ノードで特定のデーモンを実行する機能です。例えばcephのようなストレージのデーモンや、fluentdのようなログコレクタ、[linkerd](https://linkerd.io/)のような透過プロクシーなどをノードごとに動かす場合に利用します。

参考

- [What is a _Daemon Set_?](http://kubernetes.io/docs/admin/daemons/)
- linkerd: [RUNNING IN KUBERNETES WITH DAEMONSETS](https://linkerd.io/getting-started/k8s-daemonset/)

## ジョブ・バッチ処理 (Job)

`Job`は単独のジョブ処理(明示的な終了がある処理)を行うための機能です。

- [What is a _job_?](http://kubernetes.io/docs/user-guide/jobs/)

## スケジュールジョブ (CronJob)
`CronJob`(v1.4までは`ScheduledJob`)を使うとcronのようなスケジュールに基づく処理を実行することができます。

@koudaiiiさんの[CronJob(ScheduledJob)](http://qiita.com/koudaiii/items/000724c27e65be2d4484)の記事がとてもよくまとまっています。

# ネットワーク・サービス提供

## サービスディスカバリ & ロードバランシング (Service / KubeDNS / kube-proxy)

`Service`はクラスタ内のサービスディスカバリとロードバランシングを提供する機能です。`Service`は`Pod`を[LabelとSelector](http://kubernetes.io/docs/user-guide/labels/)という仕組みで選択し、配下の`Pod`群に対してロードバランスする仮想的なIPアドレス(`ClusterIP`)を提供します。また内部のDNS(`KubeDNS`)に自動的にドメインの登録を行いサービスディスカバリの機能を提供します。

ロードバランシングはノード毎にデーモンとして動く`kube-proxy`が`Service`の情報をiptablesに設定することで実装されています(デフォルトの挙動)。そのため通常の構成では`ClusterIP`はクラスタの外部から通信を受けることはできません。 クラスタ外部からの通信を受けるには通常`Service`の`type=LoadBalancer`の指定か、`Ingress`リソースによるL7ロードバランサなどの設定が必要になります。

- [Connecting Applications with Services](http://kubernetes.io/docs/user-guide/connecting-applications/)
- [Using DNS Pods and Services](http://kubernetes.io/docs/admin/dns/)

## クラウドプロバイダのL4ロードバランサとの連携(Service.Type=LoadBalancer)

`Service`の`type=LoadBalancer`の指定により外部のL4ロードバランサによってサービスを公開することができます。この指定がなされると、自動的に`Service`に連携したクラウドプロバイダ(AWS, GCPなど)ごとのロードバランサが作られます。

参考

- [Services#type-loadbalancer](http://kubernetes.io/docs/user-guide/services/#type-loadbalancer)

## L7ロードバランサとの連携 (Ingress)

`Ingress`はクラスタ外部(主にインターネット)からの通信を受けるL7ロードバランサに必要となる設定情報をリソースとして表現する機能になります。

```
    internet
        |
   [ Ingress ]
   --|-----|--
   [ Services ]
```

`Service.Type=LoadBalancer`との主な違いは下記になります

- L7ロードバランサであること(`Service.Type=LoadBalancer`はL4)
  - ホスト名やパスによるルーティング、TLS終端が可能
- `Ingress`自体はリソースとしてL7ロードバランサの情報をリソースとして表現するだけのもの
  - 実際のロードバランサの設定は[Ingress Controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers)というIngressリソースを監視する別の仕組みで行われる
  - これによりロードバランサの情報と具体的なロードバランサが分離される

Ingress Controllerの実装としては下記のようなものがあります

- [nghttpx Ingress Controller](https://github.com/zlabjp/nghttpx-ingress-lb/)
- [Nginx Ingress Controller](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx)
- [HTTP Load Balancer](https://cloud.google.com/container-engine/docs/tutorials/http-balancer) (Google Container Engine)

参考

- [What is Ingress?](http://kubernetes.io/docs/user-guide/ingress/)

## プラガブルなネットワーク機能 (CNI)

Kubernetesのネットワークは[Container Network Interface(CNI)](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)というコンテナネットワークの共通インタフェースをプラグインとしてサポートしています。[Canal(Calico, Flannel)](https://github.com/tigera/canal), [Weave Net](https://github.com/weaveworks/weave)などのネットワークプラグインが存在します。

参考

- [Network Plugins](http://kubernetes.io/docs/admin/network-plugins/)
- [Why Kubernetes doesn’t use libnetwork](http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html)

## ネットワークポリシーの制御 (NetworkPolicy)
`NetworkPolicy`は`Namespace`ごとのネットワーク設定や、`Pod`のアクセス制御の機能を提供します。Kubernetesのネットワークが`NetworkPolicy`をサポートしない場合はこの設定は無視されます。

マニュアルの例(`Namespace`ごとのネットワーク設定)

```yaml
kind: Namespace
apiVersion: v1
metadata:
  # アノテーションで分離の設定をいれる
  annotations:
    # 全てのPod外からの通信を拒否する。1.5時点でのサポートはDefaultDenyだけ
    net.beta.kubernetes.io/network-policy: |
      {
        "ingress": {
          "isolation": "DefaultDeny"
        }
      }
```

マニュアルの例(`NetworkPolicy`)

```yaml
kind: NetworkPolicy
apiVersion: extensions/v1beta1
metadata:
  name: access-nginx
spec:
  # 制限する対象
  podSelector:
    matchLabels:
      run: nginx
  ingress:
    # 許可する対象
    - from:
      - podSelector:
          matchLabels:
            access: "true"
```

参考

- [Network Policies](http://kubernetes.io/docs/user-guide/networkpolicies/)

# リソース管理
## Podのリソース制御 (requests, limits)
`spec.containers[].resources`の`requests`, `limits`の指定によってPodのリソース(現状はCPUとメモリ)の制御が行えます。`requests`は最低限確保して欲しい値を指定し、`limits`は使用できる最大の値を指定します。

以下はマニュアルの例より

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    # リソース制御の指定
    resources:
      # 最低限確保してほしいCPU、メモリ
      requests:
        memory: "64Mi"
        # 0.25コア分
        cpu: "250m"
      # 使用できる最大の値
      limits:
        # メモリの場合はこれを超えるとターミネートされる
        memory: "128Mi"
        cpu: "500m"
  # 以下省略
```
- [Resource Requests and Limits of Pod and Container](http://kubernetes.io/docs/user-guide/compute-resources/)

## Namespaceのリソース制御 (ResourceQuota)

`ResourceQuota`は`Namespace`単位でのリソース制御の仕組みを提供します。CPU、メモリのリソースの他に、オブジェクトの数(PodやServiceの数)をNamespaceごとに設定することができます。

```yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    # リソース数の制限(ここではPod数)
    pods: "4"
    # 最低限確保してほしいCPU、メモリ
    requests.cpu: "1"
    requests.memory: 1Gi
    # 使用できるCPU、メモリの最大値
    limits.cpu: "2"
    limits.memory: 2Gi
```

利用状況は`kubectl describe ns NAMESPACE`で以下のように確認することができます。

```
$ kubectl describe ns myspace
Name:   myspace
Labels: <none>
Status: Active

Resource Quotas
 Name:                  compute-resources
 Resource               Used    Hard
 --------               ---     ---
 limits.cpu             0       2
 limits.memory          0       2Gi
 pods                   0       4
 requests.cpu           0       1
 requests.memory        0       1Gi

No resource limits.
```

参考

- [Understanding Resource Quotas](http://kubernetes.io/docs/admin/resourcequota/)

# 設定管理

## シークレット管理 (Secret)

`Secret`はパスワードや秘密鍵といった秘密情報を扱うための機能です。`Secret`を使うことでアプリケーションの定義に秘密情報を含まなくてよくなります。またアプリケーションからAPIサーバーにアクセスするための`ServiceAccount`のクレデンシャルにも`Secret`が使われており、これは`Volume`として自動的にマウントされるようになっています。

- [Overview of Secrets](http://kubernetes.io/docs/user-guide/secrets/)

## 設定情報管理 (ConfigMap)

`ConfigMap`はアプリケーションの定義と別に設定情報を管理するための機能です。設定情報はPodに対して環境変数、、ファイル(Volume)、コンテナ引数といった形で渡すことができます。

- [Overview of ConfigMap](http://kubernetes.io/docs/user-guide/configmap/)
- [KubernetesのConfigMapを試してみる](http://qiita.com/tkusumi/items/8e31fddda77f93ccfdd8)

# 認証・認可
## 認証

Kubernetesは下記のようないろいろなユーザ認証方式を提供しています。Kubernetes自体はユーザは管理しておらず(`ServiceAccount`は除く)、認証方法ごとに取得するユーザ名をそのまま利用する形を取っています。

方法 | 備考
--- | ---
X509 Client Certs | クライアント証明書。`CN`がユーザ名、`O`がグループになります。例: `/CN=jbeda/O=app1/O=app2`
Static Token File | トークン認証。CSVで定義します。`Authorization: Bearer $TOKEN`ヘッダで認証。
Static Password File | Basic認証。CSVで定義します。
Service Account Tokens | ServiceAccountのJWT形式のトークン認証。
OpenID Connect Tokens | OIDCのID Tokenによる認証。
Webhook Token Authentication | 外部のWebAPIによる認証。
Authenticating Proxy | 認証プロクシーを前段においてヘッダでユーザ名が渡される方式
Keystone Password | Openstack Keystoneを使ったBasic認証。

参考

- [Users in Kubernetes](http://kubernetes.io/docs/admin/authentication/)

## 認可

Kubernetesでは認可も下記のように複数の方式が提供されています。認証されたユーザが何ができるかを管理する機能です。

方法 | 備考
--- | ---
AlwaysDeny | 全て否認。テスト用です。
AlwaysAllow	| 全て承認。AlwaysAllowの設定です。認可が不要な場合に使います
ABAC | Attribute-Based Access Control。属性によるアクセス制御。Policyファイルによる静的な定義になるため、反映には再起動が必要です
RBAC | Roles-Based Access Contro。ロールによるアクセス制御。リソースを使った動的な管理が可能です
Webhook | 外部のWebAPIによる認可。

参考

- [Using Authorization Plugins](http://kubernetes.io/docs/admin/authorization/)
- [Kubernetes: RBACの設定におけるAPIリソース](http://qiita.com/tkusumi/items/300c566a74b6b64e7e89)

## ヘッドレスアカウント (ServiceAccount)

Kubernetesでは人に対する認証の他に、アプリケーションなど人を介さない(ヘッドレス)場合の認証として`ServiceAccount`という仕組みが用意されています。例えば[Kubernetes Dashboard](https://github.com/kubernetes/dashboard)のようなアプリケーションがAPIサーバーとやり取りする場合に`ServiceAccount`が使われています。

`Namespace`ごとに`default`という`ServiceAccount`が作られている他、[`kubectl create serviceaccount`](http://kubernetes.io/docs/user-guide/kubectl/kubectl_create_serviceaccount/)で独自の`ServiceAccount`を作ることができます。

参考

- [Using the Default Service Account to access the API server](http://kubernetes.io/docs/user-guide/service-accounts/)

## APIサーバーのリクエスト制御 (AdmissionControl)

プラグイン形式で複数の制御の方法が用意されており、APIの起動オプション--admission-controlで有効にしたいものをカンマ区切りで指定します。

v1.5では下記のプラグインが用意されています。

- AlwaysAdmit
- AlwaysDeny
- AlwaysPullImages
- DefaultStorageClass
- DenyEscalatingExec
- DenyExecOnPrivileged
- ImagePolicyWebhook
- InitialResources
- LimitPodHardAntiAffinityTopology
- LimitRanger
- NamespaceAutoProvision
- NamespaceExists
- NamespaceLifecycle
- OwnerReferencesPermissionEnforcement
- PersistentVolumeLabel
- PodNodeSelector
- PodSecurityPolicy
- ResourceQuota
- SecurityContextDeny
- ServiceAccount

参考

- [Using Admission Controllers](http://kubernetes.io/docs/admin/admission-controllers/)
- [Kubernetes: Admission Controlとは何か](http://qiita.com/tkusumi/items/f71882f47e2d87701223)

# セキュリティ
## セキュリティ設定(SecurityContext)

`SecurityContext`, `PodSecurityContext` は`Container`、`Pod`に対して下記のセキュリティの設定を可能にします。

Podに対する設定 (`PodSecurityContext`)

- **seLinuxOptions** SELinuxのオプション
- **runAsUser** 実行するユーザのUID
- **runAsNonRoot** rootで動かさないことを保証する (デフォルトfalse)
- **seLinuxContext** SE Linuxのコンテキスト
- **supplementalGroups** Supplemental Groupの指定
- **fsGroup** ファイルシステムのGroupの指定

コンテナに対する設定 (`SecurityContext`)

- **capabilities** Linuxの[capabilities](https://linuxjm.osdn.jp/html/LDP_man-pages/man7/capabilities.7.html)の設定
- **privileged** 特権モードで動かすかどうか (デフォルトfalse)
- **seLinuxOptions** SELinuxのオプション
- **runAsUser** 実行するユーザのUID
- **runAsNonRoot** rootで動かさないことを保証する (デフォルトfalse)
- **readOnlyRootFilesystem** read-onlyのルートファイルシステムかどうか (デフォルトfalse)

参考

- [Volume Security context](http://kubernetes.io/docs/user-guide/security-context/)
- [v1.SecurityContext](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_securitycontext)
- [v1.PodSecurityContext](http://kubernetes.io/docs/api-reference/v1/definitions/#_v1_podsecuritycontext)

## Podのセキュリティポリシーの強制 (PodSecurityPolicy)

`PodSecurityPolicy`はPodに対してセキュリティポリシーを強制する機能です。AdmissionControlで`PodSecurityPolicy`プラグインを有効にすることで、下記のようなポリシーを全てのPodに強制することができます。

- **runAsUser** 実行するユーザのUID
- **seLinuxContext** SE Linuxのコンテキスト
- **supplementalGroups** Supplemental Groupの指定
- **fsGroup** ファイルシステムのGroupの指定
- **volumes** 使えるボリュームの種別の制限

参考

- [What is a _Pod Security Policy_?](http://kubernetes.io/docs/user-guide/pod-security-policy/)

## コンテナイメージのポリシー制御 (ImagePolicyWebhook)

`ImagePolicyWebhook`はKubernetesクラスタ上で動かすコンテナイメージを独自に制御したい場合に使える仕組みです。下記のようなユースケースが想定されているようです。

- 既知の脆弱性を含まないことを確認されたイメージだけを動かしたい
- 特定のベースイメージを使ったイメージだけを動かしたい
- レビュー済みのコードでビルドされたイメージだけを動かしたい
- 署名されたイメージだけを動かしたい

Image Policy Webhookは、ユーザが定義するWebAPIに対してそのPodに含まれるコンテナイメージの情報を渡し、実行可否をチェックする仕組みです。コンテナイメージ制御自体は自前のWebAPIで行う必要があります。Admission Controllerプラグイン`ImagePolicyWebhook`として実装されています。

参考

- [Kubernetes: Image Policy Webhookとは](http://qiita.com/tkusumi/items/4013123f3981de96986b)

# 外部システムとの連携
## クラウドプロバイダの対応 (cloudprovider)

- Amazon Web Services
- Microsoft Azure
- CloudStack
- Google Compute Engine
- Mesos
- OpenStack
- oVirt
- Photon
- Rackspace
- vSphere

[cloudprovider](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider)には下記のインタフェースが定義されており、プロバイダごとにこれを実装する形になっています。サポート状況はプロバイダによって異なります。

```go
// Interface is an abstract, pluggable interface for cloud providers.
type Interface interface {
	// LoadBalancer returns a balancer interface. Also returns true if the interface is supported, false otherwise.
	LoadBalancer() (LoadBalancer, bool)
	// Instances returns an instances interface. Also returns true if the interface is supported, false otherwise.
	Instances() (Instances, bool)
	// Zones returns a zones interface. Also returns true if the interface is supported, false otherwise.
	Zones() (Zones, bool)
	// Clusters returns a clusters interface.  Also returns true if the interface is supported, false otherwise.
	Clusters() (Clusters, bool)
	// Routes returns a routes interface along with whether the interface is supported.
	Routes() (Routes, bool)
	// ProviderName returns the cloud provider ID.
	ProviderName() string
	// ScrubDNS provides an opportunity for cloud-provider-specific code to process DNS settings for pods.
	ScrubDNS(nameservers, searches []string) (nsOut, srchOut []string)
}
```

- https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider

## 永続ストレージ連携(PersisntentVolume / PersisntentVolumeClaim)

`PersistentVolume`は永続ストレージとの連携する機能を提供します。Kubernetes v1.5時点では下記のストレージに対応しています。

- awsElasticBlockStore
- azureDisk
- azureFile
- cephFS
- cinder (OpenStack block storage)
- fc (Fibre Channel)
- flexVolume
- flocker
- gcePersistentDisk
- glusterfs
- hostPath (Nodeのホストのパス)
- iscsi
- nfs
- photonPersistentDisk
- quobyte
- rbd (Ceph Block Device)
- vsphereVolume

参考

- [Persistent Volumes](http://kubernetes.io/docs/user-guide/persistent-volumes/)
- [Volumes](http://kubernetes.io/docs/user-guide/volumes/)

# 拡張性
## 独自のリソース定義(ThirdPartyResource)

`ThirdPartyResource`はユーザが独自のKubernetesのリソースを定義できる機能です。Kubernetesのリソース管理の仕組みをそのままフレームワークとして利用することができます。高度なアプリケーションの運用を実現するCoreOSの[Operator](https://coreos.com/blog/introducing-operators.html)や、同じくCoreOSのOpenID Connect Provider [dex](https://github.com/coreos/dex)のデータストアなど活用例が増えてきました。

ThirdPartyResourceの詳細については @shmurata さんの[フレームワークとしての Kubernetes](http://qiita.com/shmurata/items/58d7b010babf6476bb79)という記事がよくまとまっています。

# おわりに

機能をまとめてみて改めてKubernetesの機能の多さに驚かされました。引き続きKubernetesの発展に注目していきたいと思います。 :eyes:

tkusumi

311Contribution

Organization

編集リクエスト

この投稿は Kubernetes Advent Calendar 2016 の 13日目の記事です。

12日目の記事: フレームワークとしての Kubernetes

PR 社内メールでの情報共有をなくそう - Qiita:Team

Comments Loading...