セットアップ

セットアップ
正しいソリューションの選択
Kubernetesのダウンロード
オンプレミスVM
Kubernetes Version and Version Skew Support Policy (EN)
大規模クラスタの構築
複数のゾーンで動かす
CRIのインストール
KRIBを使用してDigital Rebar Provision (DRP)と共にKubernetesをインストールする
Minikubを使用してローカル環境でKubernetesを動かす
PKI証明書とその要件
ゼロからのカスタムクラスターの作成
ノードのセットアップの検証

Edit This Page

PKI証明書とその要件

Kubernetes requires PKI certificates for authentication over TLS. If you install Kubernetes with kubeadm, the certificates that your cluster requires are automatically generated. You can also generate your own certificates – for example, to keep your private keys more secure by not storing them on the API server. This page explains the certificates that your cluster requires.

あなたのクラスタではどのように証明書が使われているのか

Kubernetes requires PKI for the following operations:

Note: front-proxy certificates are required only if you run kube-proxy to support an extension API server.

etcd also implements mutual TLS to authenticate clients and peers.

証明書の保存場所

If you install Kubernetes with kubeadm, certificates are stored in /etc/kubernetes/pki. All paths in this documentation are relative to that directory.

手動で証明書を設定する

If you don’t want kubeadm to generate the required certificates, you can create them in either of the following ways.

単一ルート認証局

You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.

Required CAs:

path Default CN description
ca.crt,key kubernetes-ca Kubernetes general CA
etcd/ca.crt,key etcd-ca For all etcd-related functions
front-proxy-ca.crt,key kubernetes-front-proxy-ca For the front-end proxy

全ての証明書

If you don’t wish to copy these private keys to your API servers, you can generate all certificates yourself.

Required certificates:

Default CN Parent CA O (in Subject) kind hosts (SAN)
kube-etcd etcd-ca server, client [1][etcdbug] localhost, 127.0.0.1
kube-etcd-peer etcd-ca server, client <hostname>, <Host_IP>, localhost, 127.0.0.1
kube-etcd-healthcheck-client etcd-ca client
kube-apiserver-etcd-client etcd-ca system:masters client
kube-apiserver kubernetes-ca server <hostname>, <Host_IP>, <advertise_IP>, [1]
kube-apiserver-kubelet-client kubernetes-ca system:masters client
front-proxy-client kubernetes-front-proxy-ca client

[1]: kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local

where kind maps to one or more of the x509 key usage types:

kind Key usage
server digital signature, key encipherment, server auth
client digital signature, key encipherment, client auth

証明書のパス

Certificates should be placed in a recommended path (as used by kubeadm). Paths should be specified using the given argument regardless of location.

Default CN recommend key path recommended cert path command key argument cert argument
etcd-ca etcd/ca.crt kube-apiserver –etcd-cafile
etcd-client apiserver-etcd-client.crt apiserver-etcd-client.crt kube-apiserver –etcd-certfile –etcd-keyfile
kubernetes-ca ca.crt kube-apiserver –client-ca-file
kube-apiserver apiserver.crt apiserver.key kube-apiserver –tls-cert-file –tls-private-key
apiserver-kubelet-client apiserver-kubelet-client.crt kube-apiserver –kubelet-client-certificate
front-proxy-client front-proxy-client.key front-proxy-client.crt kube-apiserver –proxy-client-cert-file –proxy-client-key-file
etcd-ca etcd/ca.crt etcd –trusted-ca-file, –peer-trusted-ca-file
kube-etcd etcd/server.crt etcd –cert-file
kube-etcd-peer etcd/peer.key etcd/peer.crt etcd –peer-key-file –peer-cert-file
etcd-ca etcd/ca.crt etcdctl[2] –cacert
kube-etcd-healthcheck-client etcd/healthcheck-client.key etcd/healthcheck-client.crt etcdctl[2] –key –cert

[2]: For a liveness probe, if self-hosted

ユーザアカウント用に証明書を設定する

You must manually configure these administrator account and service accounts:

filename credential name Default CN O (in Subject)
admin.conf default-admin kubernetes-admin system:masters
kubelet.conf default-auth system:node:<nodename> system:nodes
controller-manager.conf default-controller-manager system:kube-controller-manager
scheduler.conf default-manager system:kube-scheduler
  1. For each config, generate an x509 cert/key pair with the given CN and O.

  2. Run kubectl as follows for each config:

KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system

These files are used as follows:

filename command comment
admin.conf kubectl Configures administrator user for the cluster
kubelet.conf kubelet One required for each node in the cluster.
controller-manager.conf kube-controller-manager Must be added to manifest in manifests/kube-controller-manager.yaml
scheduler.conf kube-scheduler Must be added to manifest in manifests/kube-scheduler.yaml

Feedback