第2章 Kubernetes安装配置指南
2.1 系统要求
2.2 使用kubeadm工具快速安装Kubernetes集群
2.2.1 安装kubeadm和相关工具
2.2.2 kubeadm config
2.2.3 下载Kubernetes的相关镜像
2.2.4 运行kubeadm init命令安装Master
2.2.5 安装Node，加入集群
2.2.6 安装网络插件
2.2.7 验证Kubernetes集群是否安装完成
2.3 以二进制文件方式安装Kubernetes集群
2.3.1 Master上的etcd、kube-apiserver、kube-controller-manager、kube-scheduler服务
2.3.2 Node上的kubelet、kube-proxy服务
2.4 Kubernetes集群的安全设置
2.4.1 基于CA签名的双向数字证书认证方式
2.4.2 基于HTTP Base或Token的简单认证方式
2.5 Kubernetes集群的网络配置
2.6 内网中的Kubernetes相关配置
2.6.1 Docker Private Registry（私有Docker镜像库）
2.6.2 kubelet配置
2.7 Kubernetes的版本升级
2.7.1 二进制升级
2.7.2 使用kubeadm进行集群升级
2.8 Kubernetes核心服务配置详解
2.8.1 公共配置参数
2.8.2 kube-apiserver启动参数
2.8.3 kube-controller-manager启动参数
2.8.4 kube-scheduler启动参数
2.8.5 kubelet启动参数
2.8.6 kube-proxy启动参数
2.9 CRI（容器运行时接口）详解
2.9.1 CRI概述
2.9.2 CRI的主要组件
2.9.3 Pod和容器的生命周期管理
2.9.4 面向容器级别的设计思路
2.9.5 尝试使用新的Docker-CRI来创建容器
2.9.6 CRI的进展
2.10 kubectl命令行工具用法详解
2.10.1 kubectl用法概述
2.10.2 kubectl子命令详解
2.10.3 kubectl参数列表
2.10.4 kubectl输出格式
2.10.5 kubectl操作示例
2.1 系统要求
Kubernetes系统由一组可执行程序组成，用户可以通过GitHub上的Kubernetes项目页下载编译好的二进制包，或者下载源代码并编译后进行安装。
安装Kubernetes对软件和硬件的系统要求如表2.1所示。
Kubernetes需要容器运行时（Container Runtime Interface，CRI）的支持，目前官方支持的容器运行时包括：Docker、Containerd、CRI-O和frakti。
容器运行时CRI的原理详见3.9节的说明。本节以Docker作为容器运行环境，推荐版本为Docker CE 18.09。
宿主机操作系统以CentOS Linux 7为例，使用Systemd系统完成对Kubernetes服务的配置。其他Linux发行版的服务配置请参考相关的系统管理手册。
为了便于管理，常见的做法是将Kubernetes服务程序配置为Linux系统开机自启动的服务。
需要注意的是，CentOS Linux 7默认启动了防火墙服务（firewalld），
而Kubernetes的Master与工作Node之间会有大量的网络通信，安全的做法是在防火墙上配置各组件需要相互通信的端口号，
具体要配置的端口号详见2.8节各服务启动参数中监听的端口号。
在安全的内部网络环境中可以关闭防火墙服务：
# systemctl disable firewalld
# systemctl stop firewalld
另外，建议在主机上禁用SELinux，让容器可以读取主机文件系统：
# setenforce 0
或修改系统文件/etc/sysconfig/selinux，将SELINUX=enforcing修改成SELINUX=disabled，然后重启Linux。
2.2 使用kubeadm工具快速安装Kubernetes集群
最简单的方法是使用yum install kubernetes命令安装Kubernetes集群，
但仍需修改各组件的启动参数，才能完成对Kubernetes集群的配置，整个过程比较复杂，也容易出错。
Kubernetes从1.4版本开始引入了命令行工具kubeadm，致力于简化集群的安装过程，并解决Kubernetes集群的高可用问题。
在Kubernetes 1.13版本中，kubeadm工具进入GA阶段，宣称已经为生产环境应用准备就绪。
本节先讲解基于kubeadm的安装过程（以CentOS 7为例）。
2.2.1 安装kubeadm和相关工具
首先配置yum源，官方yum源的地址为https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64。
如果无法访问官方yum源的地址，则也可以使用国内的一个yum源，地址为http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/，
yum源的配置文件/etc/yum.repos.d/kubernetes.repo的内容如下：
[kubernetes]
name=Kubernetes Rspository
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
然后运行yum install命令安装kubeadm和相关工具：
# yum install -y kubectl kubeadm kubectl --disableexcludes=kubernetes
运行下面的命令，启动Docker服务（如果已安装Docker，则无须再次启动）和kubelet服务，并设置为开机自动启动：
# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
2.2.2 kubeadm config
kubeadm已经进入GA阶段，其控制面初始化和加入节点步骤都支持大量的可定制内容，因此kubeadm还提供了配置文件功能用于复杂定制。
同时，kubeadm将配置文件以ConfigMap的形式保存到集群之中，便于后续的查询和升级工作。
kubeadm config子命令提供了对这一组功能的支持：
kubeadm config upload from-file：由配置文件上传到集群中生成ConfigMap。
kubeadm config upload from-flags：由配置参数生成ConfigMap。
kubeadm config view：查看当前集群中的配置值。
kubeadm config print init-defaults：输出kubeadm init默认参数文件的内容。
kubeadm config print join-defaults：输出kubeadm join默认参数文件的内容。
kubeadm config migrate：在新旧版本之间进行配置转换。
kubeadm config images list：列出所需的镜像列表。
kubeadm config images pull：拉取镜像到本地。
例如，执行kubeadm config print init-defaults，可以取得默认的初始化参数文件：
# kubeadm config print init-defaults > init.default.yaml
对生成的文件进行编辑，可以按需生成合适的配置。
例如，若需要定制镜像仓库的地址，以及Pod的地址范围，则可以使用如下配置：
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
imageRepository: docker.io/dustise
kubernetesVersion: v1.14.0
networking:
podSubnet: "192.168.0.0/16"
将上面的内容保存为init-config.yaml备用。
2.2.3 下载Kubernetes的相关镜像
为了从国内的镜像托管站点获得镜像加速支持，建议修改Docker的配置文件，增加Registry Mirror参数，将镜像配置写入配置参数中，
例如echo '{"registry-mirrors":["https://registry.docker-cn.com"]}' > /etc/docker/daemon.json，然后重启Docker服务。
使用config images pull子命令下载所需镜像，例如：
# kubeadm config images pull --config=init-config.yaml
在镜像下载完成之后，就可以进行安装了。
2.2.4 运行kubeadm init命令安装Master
至此，准备工作已就绪，执行kubeadm init命令即可一键安装Kubernetes的Master。
在开始之前需要注意：
kubeadm的安装过程不涉及网络插件（CNI）的初始化，因此kubeadm初步安装完成的集群不具备网络功能，任何Pod包括自带的CoreDNS都无法正常工作。
而网络插件的安装往往对kubeadm init命令的参数有一定的要求。
例如，安装Calico插件时需要指定--pod-network-cidr=192.168.0.0/16，
详情可参考https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network。
接下来使用kubeadm init命令，使用前面创建的配置文件进行集群控制面的初始化：
# kubeadm init --config=init-config.yaml
运行后，控制台将输出如下内容：
等待一段时间后，Kubernetes的Master安装成功，显示如下信息：
"kubeadm join 10.211.55.30:6443 --token ah9koe.nvuvz2v60iam0e0d"
按照提示执行下面的命令，复制配置文件到普通用户的home目录下：
# mkdir -p $HOME/.kube
# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# sudo shown $(id -u):$(id -g) $HOME/.kube/config
这样就在Master上安装了Kubernetes，但在集群内还是没有可用的工作Node，并缺乏对容器网络的配置。
这里需要注意kubeadm init命令执行完成后的最后几行提示信息，其中包含加入节点的指令（kubeadm join）和所需的Token。
此时可以用kubectl命令验证在2.2.2节中提到的ConfigMap：
# kubectl get -n kube-system configmap
可以看到其中生成了名为kubeadm-config的ConfigMap对象。
2.2.5 安装Node，加入集群
对于新节点的添加，系统准备和Kubernetes yum源的配置过程是一致的，在Node主机上执行下面的安装过程。
（1）安装kubeadm和相关工具：
# yum install -y kubectl kubeadm kubectl --disableexcludes=kubernetes
运行下面的命令启动Docker服务与kubelet服务，并将其设置为开机自启动：
# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
（2）为kubeadm命令生成配置文件。创建文件join-config.yaml，内容如下：
apiVersion: kubeadm.k8s.io/v1beta1
kind: JoinConfiguration
discovery:
bootstrapToken:
apiServerEndpoint: 10.211.55.30:6443
token: ah9koe.nvuvz2v60iam0e0d
unsafeSkipCAVerification: true
tlsBootstrapToken: ah9koe.nvuvz2v60iam0e0d
其中，apiServerEndpoint的值来自Master服务器的地址，token和tlsBootstrapToken的值就来自于使用kubeadm init安装Master的最后一行提示信息。
（3）执行kubeadm join命令，将本Node加入集群：
# kubeadm join --config=join-config.yaml
kubeadm在Master上也安装了kubelet，在默认情况下并不参与工作负载。
如果希望安装一个单机All-In-One的Kubernetes环境，则可以执行下面的命令（删除Node的Label“node-role.kubernetes.io/master”），让Master成为一个Node：
# kubectl taint nodes --all node-role.kubernetes.io/master-
2.2.6 安装网络插件
执行kubectl get nodes命令，会发现Kubernetes提示Master为NotReady状态，这是因为还没有安装CNI网络插件：
# kubectl get nodes
下面根据kubeadm的提示安装CNI网络插件。
对于CNI网络插件，可以有许多选择，请参考https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network的说明。
例如，选择weave插件，执行下面的命令即可一键完成安装：
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d ' ')"
2.2.7 验证Kubernetes集群是否安装完成
执行下面的命令，验证Kubernetes集群的相关Pod是否都正常创建并运行：
# kubectl get pods --all-namespaces
如果发现有状态错误的Pod，则可以执行kubectl --namespace=kube-system describe pod <pod_name>来查看错误原因，常见的错误原因是镜像没有下载完成。
至此，通过kubeadm工具就实现了Kubernetes集群的快速搭建。
如果安装失败，则可以执行kubeadm reset命令将主机恢复原状，重新执行kubeadm init命令，再次进行安装。
2.3 以二进制文件方式安装Kubernetes集群
本节以二进制文件方式安装Kubernetes集群，并对每个组件的配置进行详细说明。
从Kubernetes发布官网https://github.com/kubernetes/kubernetes/releases找到对应的版本号，
单击CHANGELOG，找到已编译好的二进制文件的下载页面，如图2.1和图2.2所示。
本书基于Kubernetes 1.14版本进行说明。
在压缩包kubernetes.tar.gz内包含了Kubernetes的服务程序文件、文档和示例；在压缩包kubernetes-src.tar.gz内则包含了全部源代码。
也可以直接下载Server Binaries中的kubernetes-server-linux-amd64.tar.gz文件，其中包含了Kubernetes需要运行的全部服务程序文件。
主要的服务程序文件列表如表2.2所示。
Kubernetes的主要服务程序都可以通过直接运行二进制文件加上启动参数完成运行。
在Kubernetes的Master上需要部署etcd、kube-apiserver、kube-controller-manager、kube-scheduler服务进程，
在工作Node上需要部署docker、kubelet和kube-proxy服务进程。
将Kubernetes的二进制可执行文件复制到/usr/bin目录下，
然后在/usr/lib/system/system目录下为各服务创建systemd服务配置文件（完整的systemd系统知识请参考Linux的相关手册），这样就完成了软件的安装。
要使Kubernetes正常工作，需要详细配置各个服务的启动参数。
下面主要介绍各服务最主要的启动参数，每个服务完整启动的参数说明详见2.8节。
2.3.1 Master上的etcd、kube-apiserver、kube-controller-manager、kube-scheduler服务
1.etcd服务
etcd服务作为Kubernetes集群的主数据库，在安装Kubernetes各服务之前需要首先安装和启动。
从GitHub官网（https://github.com/coreos/etcd/releases）下载etcd二进制文件，将etcd和etcdctl文件复制到/usr/bin目录。
设置systemd服务配置文件/usr/lib/systemd/system/etcd.service：
[Unit]
Description=Etcd Server
After=network.target
[Service]
Type=simple
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
[Install]
WantedBy=multi-user.target
其中，WorkingDirectory（/var/lib/etcd/）表示etcd数据保存的目录，需要在启动etcd服务之前创建。
配置文件/etc/etcd/etcd.conf通常不需要特别的参数设置（详细的参数配置内容参见官方文档），etcd默认使用http://127.0.0.1:2379地址供客户端连接。
配置完成后，通过systemctl start命令启动etcd服务。同时，使用systemctl enable命令将服务加入开机启动列表中：
# systemctl daemon-reload
# systemctl enable etcd.service
# systemctl start etcd.service
通过执行etcdctl cluster-health，可以验证etcd是否正确启动：
# etcdctl cluster health
2.kube-apiserver服务
将kube-apiserver、kube-controller-manager和kube-scheduler文件复制到/usr/bin目录。
设置systemd服务配置文件/usr/lib/systemd/system/kube-apiserver.service，内容如下：
[Unit]
Description=Kubernetes API Server
Decumentation=https://github.com/GoogleCloudPlatform/kubernetes
After=etcd.service
Wants=etcd.service
[Service]
EnvironmentFile=/etc/kubernetes/apiserver
ExecStart=/usr/bin/kube-apiserver $KUBE_API_ARGS
Restart=on-failure
Type=notify
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
配置文件/etc/kubernetes/apiserver的内容包括了kube-apiserver的全部启动参数，主要的配置参数在变量KUBE_API_ARGS中指定。
# cat /etc/kubernetes/apiserver
对启动参数说明如下。
--etcd-servers：指定etcd服务的URL。
--storage-backend：指定etcd的版本，从Kubernetes 1.6开始，默认为etcd 3。
注意，在Kubernetes 1.6之前的版本中没有这个参数，kube-apiserver默认使用etcd 2，
对于正在运行的1.5或旧版本的Kubernetes集群，etcd提供了数据升级方案，详见etcd文档（https://coreos.com/etcd/docs/latest/upgrades/upgrade_3_0.html）。
--insecure-bind-address：API Server绑定主机的非安全IP地址，设置0.0.0.0表示绑定所有IP地址。
--insecure-port：API Server绑定主机的非安全端口号，默认为8080。
--service-cluster-ip-range：Kubernetes集群中Service的虚拟IP地址范围，以CIDR格式表示，例如169.169.0.0/16，该IP范围不能与物理机的IP地址有重合。
--service-node-port-range：Kubernetes集群中Service可使用的物理机端口号范围，默认值为30000～32767。
--enable-admission-plugins：Kubernetes集群的准入控制设置，各控制模块以插件的形式依次生效。
--logtostderr：设置为false表示将日志写入文件，不写入stderr。
--log-dir：日志目录。
--v：日志级别。
3.kube-controller-manager服务
kube-controller-manager服务依赖于kube-apiserver服务，
设置systemd服务配置文件/usr/lib/systemd/system/kube-controller-manager.service，内容如下：
[Unit]
Description=Kubernetes Controller Manager
Decumentation=https://github.com/GoogleCloudPlatform/kubernetes
After=kube-apiserver.service
Requires=kube-apiserver.service
[Service]
EnvironmentFile=/etc/kubernetes/controller-manager
ExecStart=/usr/bin/kube-controller-manager $KUBE_CONTROLLER_MANAGER_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
配置文件/etc/kubernetes/controller-manager的内容包含了kube-controller-manager的全部启动参数，
主要的配置参数在变量KUBE_CONTROLLER_MANAGER_ARGS中指定：
# cat /etc/kubernetes/controller-manager
对启动参数说明如下。
--kubeconfig：设置与API Server连接的相关配置，例如：--kubeconfig=/etc/kubernetes/kubeconfig
--logtostderr：设置为false表示将日志写入文件，不写入stderr。
--log-dir：日志目录。
--v：日志级别。
4.kube-scheduler服务
kube-scheduler服务也依赖于kube-apiserver服务，
设置systemd服务配置文件/usr/lib/systemd/system/kube-scheduler.service，内容如下：
[Unit]
Description=Kubernetes Scheduler
Decumentation=https://github.com/GoogleCloudPlatform/kubernetes
After=kube-apiserver.service
Requires=kube-apiserver.service
[Service]
EnvironmentFile=/etc/kubernetes/scheduler
ExecStart=/usr/bin/kube-scheduler $KUBE_SCHEDULER_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
配置文件/etc/kubernetes/scheduler的内容包括了kube-scheduler的全部启动参数，
主要的配置参数在变量KUBE_SCHEDULER_ARGS中指定：
# cat /etc/kubernetes/scheduler
对启动参数说明如下。
--kubeconfig：设置与API Server连接的相关配置，可以与kube-controller-manager使用的kubeconfig文件相同。
--logtostderr：设置为false表示将日志写入文件，不写入stderr。
--log-dir：日志目录。
--v：日志级别。
配置完成后，执行systemctl start命令按顺序启动这3个服务，同时，使用systemctl enable命令将服务加入开机启动列表中：
# systemctl daemon-reload
# systemctl enable kube-apiserver.service
# systemctl start kube-apiserver.service
# systemctl enable kube-controller-manager
# systemctl start kube-controller-manager
# systemctl enable kube-scheduler
# systemctl start kube-scheduler
通过systemctl status <service_name>验证服务的启动状态，running表示启动成功。
至此，Master上所需的服务就全部启动完成了。
2.3.2 Node上的kubelet、kube-proxy服务
在工作Node上需要预先安装好Docker Daemon并且正常启动。
Docker的安装和启动详见Docker官网http://www.docker.com的说明文档。
1.kubelet服务
kubelet服务依赖于Docker服务，设置systemd服务配置文件/usr/lib/systemd/system/kubelet.service，内容如下：
[Unit]
Description=Kubernetes Kubelet Server
Decumentation=https://github.com/GoogleCloudPlatform/kubernetes
After=docker.service
Requires=docker.service
[Service]
WorkingDirectory=/var/lib/kubelet
EnvironmentFile=/etc/kubernetes/kubelet
ExecStart=/usr/bin/kubelet $KUBELET_ARGS
Restart=on-failure
[Install]
WantedBy=multi-user.target
其中，WorkingDirectory表示kubelet保存数据的目录，需要在启动kubelet服务之前创建。
配置文件/etc/kubernetes/kubelet的内容包括了kubelet的全部启动参数，主要的配置参数在变量KUBELET_ARGS中指定：
# cat /etc/kubernetes/kubelet
对启动参数说明如下。
--kubeconfig：设置与API Server连接的相关配置，可以与kube-controller-manager使用的kubeconfig文件相同。
--hostname-override：设置本Node的名称。
--logtostderr：设置为false表示将日志写入文件，不写入stderr。
--log-dir：日志目录。
--v：日志级别。
2.kube-proxy服务
kube-proxy服务依赖于network服务，设置systemd服务配置文件/usr/lib/systemd/system/kube-proxy.service，内容如下：
[Unit]
Description=Kubernetes Kube-Proxy Server
Decumentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target
Requires=network.service
[Service]
EnvironmentFile=/etc/kubernetes/proxy
ExecStart=/usr/bin/kube-proxy $KUB_PROXY_ARGS
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
配置文件/etc/kubernetes/proxy的内容包括了kube-proxy的全部启动参数，主要的配置参数在变量KUBE_PROXY_ARGS中指定：
# cat /etc/kubernetes/proxy
对启动参数说明如下。
--kubeconfig：设置与API Server连接的相关配置，可以与kube-controller-manager使用的kubeconfig文件相同。
--logtostderr：设置为false表示将日志写入文件，不写入stderr。
--log-dir：日志目录。
--v：日志级别。
配置完成后，通过systemctl启动kubelet和kube-proxy服务：
# systemctl daemon-reload
# systemctl enable kubelet.service
# systemctl start kubelet.service
# systemctl enable kube-proxy
# systemctl start kube-proxy
kubelet默认采用向Master自动注册本Node的机制，在Master上查看各Node的状态，状态为Ready表示Node已经成功注册并且状态为可用：
# kubectl get nodes
等所有Node的状态都为Ready之后，一个Kubernetes集群就启动完成了。
接下来可以创建Pod、Deployment、Service等资源对象来部署容器应用了。
2.4 Kubernetes集群的安全设置
2.4.1 基于CA签名的双向数字证书认证方式
在一个安全的内网环境中，Kubernetes的各个组件与Master之间可以通过kube-apiserver的非安全端口http://<kube-apiserver-ip>:8080进行访问。
但如果API Server需要对外提供服务，或者集群中的某些容器也需要访问API Server以获取集群中的某些信息，则更安全的做法是启用HTTPS安全机制。
Kubernetes提供了基于CA签名的双向数字证书认证方式和简单的基于HTTP Base或Token的认证方式，其中CA证书方式的安全性最高。
本节先介绍如何以CA证书的方式配置Kubernetes集群，
要求Master上的kube-apiserver、kube-controller-manager、kube-scheduler进程及各Node上的kubelet、kube-proxy进程进行CA签名双向数字证书安全设置。
基于CA签名的双向数字证书的生成过程如下:
（1）为kube-apiserver生成一个数字证书，并用CA证书签名。
（2）为kube-apiserver进程配置证书相关的启动参数，包括CA证书（用于验证客户端证书的签名真伪）、自己的经过CA签名后的证书及私钥。
（3）为每个访问Kubernetes API Server的客户端（如kube-controller-manager、kube-scheduler、kubelet、kube-proxy及调用API Server的客户端程序kubectl等）进程
都生成自己的数字证书，也都用CA证书签名，在相关程序的启动参数里增加CA证书、自己的证书等相关参数。
1.设置kube-apiserver的CA证书相关的文件和启动参数
使用OpenSSL工具在Master服务器上创建CA证书和私钥相关的文件：
# openssl genrsa -out ca.key 2048
# openssl req -x509 -new -nodes -key ca.key -subj "/CN=k8s-master" -days 5000 -out ca.crt
# openssl genrsa -out server.key 2048
注意：在生成ca.crt时，-subj参数中“/CN”的值为Master主机名。
准备master_ssl.cnf文件，该文件用于x509 v3版本的证书。在该文件中主要需要设置Master服务器的hostname（k8s-master）、IP地址（192.168.18.3），
以及Kubernetes Master Service的虚拟服务名称（kubernetes.default等）和该虚拟服务的ClusterIP地址（169.169.0.1）。
master_ssl.cnf文件的示例如下：
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
DNS.5 = k8s-master
IP.1 = 169.169.0.1
IP.2 = 192.168.18.3
基于master_ssl.cnf创建server.csr和server.crt文件。在生成server.csr时，-subj参数中“/CN”的值需为Master的主机名：
# openssl req -new -key server.key -subj "/CN=k8s-master" -config master_ssl.cnf -out server.csr
# openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 5000 -extensions v3_req -extfile master_ssl.cnf -out server.crt
在全部执行完后会生成6个文件：ca.crt、ca.key、ca.srl、server.crt、server.csr、server.key。
将这些文件复制到一个目录下（例如/var/run/kubernetes/），然后设置kube-apiserver的三个启动参数“--client-ca-file”“--tls-cert-file”和“--tls-private-key-file”，
分别代表CA根证书文件、服务端证书文件和服务端私钥文件：
--client-ca-file=/var/run/kubernetes/ca.crt
--tls-cert-file=/var/run/kubernetes/server.crt
--tls-private-key-file=/var/run/kubernetes/server.key
同时，可以关闭非安全端口（设置--insecure-port=0），设置安全端口为6443（默认值）：
--insecure-port=0
--secure-port=6443
最后重启kube-apiserver服务。
2.设置kube-controller-manager的客户端证书、私钥和启动参数
代码如下：
# openssl genrsa -out cs_client.key 2048
# openssl req -new -key ca_client.key -subj "/CN=k8s-master" -out cs_client.csr
# openssl x509 -req -in ca_client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out cs_client.crt -days 5000
其中，在生成cs_client.crt时，-CA参数和-CAkey参数使用的是API Server的ca.crt和ca.key文件。
然后将这些文件复制到一个目录下（例如/var/run/kubernetes/）。
接下来创建/etc/kubernetes/kubeconfig文件（kube-controller-manager与kube-scheduler共用），配置客户端证书等相关参数，内容如下。
apiVersion: v1
kind: Config
users:
- name: controllermanager
user:
client-certificate: /var/run/kubernetes/cs_client.crt
client-key: /var/run/kubernetes/cs_client.key
clusters:
- name: local
cluster:
certificate-authority: /var/run/kubernetes/ca.crt
server: https://192.168.18.3:6443
contexts:
- context:
cluster: local
user: controllermanager
name: my-context
current-context: my-context
然后设置kube-controller-manager服务的启动参数：
--service-account-key-file=/var/run/kubernetes/server.key
--root-ca-file=/var/run/kubernetes/ca.crt
--kubeconfig=/etc/kubernetes/kubeconfig
最后重启kube-controller-manager服务。
3.设置kube-scheduler启动参数
kube-scheduler复用上一步kube-controller-manager创建的客户端证书，配置启动参数：
--kubeconfig=/etc/kubernetes/kubeconfig
重启kube-scheduler服务。
4.设置每个Node上kubelet的客户端证书、私钥和启动参数
首先，复制kube-apiserver的ca.crt和ca.key文件到Node上，
在生成kubelet_client.crt时-CA参数和-CAkey参数使用的是API Server的ca.crt和ca.key文件；
在生成kubelet_client.csr时，将-subj参数中的“/CN”设置为本Node的IP地址：
# openssl genrsa -out kubelet_client.key 2048
# openssl req -new -key kubelet_client.key -subj "/CN=本Node的IP地址" -out kubelet_client.csr
# openssl x509 -req -in kubelet_client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out kubelet_client.crt -days 5000
将这些文件复制到一个目录下（例如/etc/kubernetes/ssl_keys/）。
接下来创建/etc/kubernetes/kubeconfig文件（kubelet和kube-proxy进程共用），配置客户端证书等相关参数，内容如下：
apiVersion: v1
kind: Config
users:
- name: kubelet
user:
client-certificate: /etc/kubernetes/ssl_keys/kubelet_client.crt
client-key: /etc/kubernetes/ssl_keys/kubelet_client.key
clusters:
- name: local
cluster:
certificate-authority: /etc/kubernetes/ssl_keys/ca.crt
server: https://192.168.18.3:6443
contexts:
- context:
cluster: local
user: kubelet
name: my-context
current-context: my-context
然后设置kubelet服务的启动参数：
--kubeconfig=/etc/kubernetes/kubeconfig
最后重启kubelet服务。
5.设置kube-proxy的启动参数
kube-proxy复用上一步kubelet创建的客户端证书，配置启动参数：
--kubeconfig=/etc/kubernetes/kubeconfig
重启kube-proxy服务。
至此，一个基于CA的双向数字证书认证的Kubernetes集群环境就搭建完成了。
6.设置kubectl客户端使用安全方式访问API Server
在使用kubectl对Kubernetes集群进行操作时，默认使用非安全端口8080对API Server进行访问，也可以设置为安全访问API Server的模式，
需要设置3个证书相关的参数“—certificate-authority”“--client-certificate”和“--client-key”，分别表示用于CA授权的证书、客户端证书和客户端密钥。
--certificate-authority：使用为kube-apiserver生成的ca.crt文件。
--client-certificate：使用为kube-controller-manager生成的cs_client.crt文件。
--client-key：使用为kube-controller-manager生成的cs_client.key文件。
同时，指定API Server的URL地址为HTTPS安全地址（例如https://k8s-master:443），最后输入需要执行的子命令，即可对API Server进行安全访问了：
# kubectl --server=https://192.168.18.3:6443
--certificate-authority=/etc/kubernetes/ssl_keys/ca.crt
--client-certificate=/etc/kubernetes/ssl_keys/cs_client.crt
--client-key=/etc/kubernetes/ssl_keys/cs_client.key get nodes
2.4.2 基于HTTP Base或Token的简单认证方式
除了提供了基于CA的双向数字证书认证方式，Kubernetes也提供了基于HTTP Base或Token的简单认证方式。
各组件与API Server之间的通信方式仍然采用HTTPS，但不使用CA数字证书。
采用基于HTTP Base或Token的简单认证方式时，API Server对外暴露HTTPS端口，客户端提供用户名、密码或Token来完成认证过程。
需要说明的是，kubectl命令行工具比较特殊，它同时支持CA双向认证和简单认证两种模式与API Server通信，
其他客户端组件只能配置为双向安全认证或非安全模式与API Server通信。
1.基于HTTP Base认证的配置过程
（1）创建包括用户名、密码和UID的文件basic_auth_file，放置在合适的目录下，例如/etc/kuberntes目录。
需要注意的是，这是一个纯文本文件，用户名、密码都是明文。
# vi /etc/kuberntes/basic_auth_file
admin,admin,1
system,system,2
（2）设置kube-apiserver的启动参数“--basic-auth-file”，使用上述文件提供安全认证：
--secure-port=6443
--basic-auth-file=/etc/kuberntes/basic_auth_file
然后，重启API Server服务。
（3）使用kubectl通过指定的用户名和密码来访问API Server：
# kubectl --server=https://192.168.18.3.:6443 --username=admin --password=admin --insecure-skip-tls-verify=true get nodes
2.基于Token认证的配置过程
（1）创建包括用户名、密码和UID的文件token_auth_file，放置在合适的目录下，例如/etc/kuberntes目录。
需要注意的是，这是一个纯文本文件，用户名、密码都是明文。
# vi /etc/kuberntes/token_auth_file
admin,admin,1
system,system,2
（2）设置kube-apiserver的启动参数“--token-auth-file”，使用上述文件提供安全认证：
--secure-port=6443
--token-auth-file=/etc/kuberntes/token_auth_file
然后，重启API Server服务。
（3）用curl验证和访问API Server：
# curl -k --header "Authorization:Bearer admin" https://192.168.18.3:6443/version {}
2.5 Kubernetes集群的网络配置
在多个Node组成的Kubernetes集群内，跨主机的容器间网络互通是Kubernetes集群能够正常工作的前提条件。
Kubernetes本身并不会对跨主机的容器网络进行设置，这需要额外的工具来实现。
除了谷歌公有云GCE平台提供的网络设置，一些开源的工具包括Flannel、Open vSwitch、Weave、Calico等都能够实现跨主机的容器间网络互通。
随着CNI网络模型的逐渐成熟，Kubernetes将优先使用CNI网络插件打通跨主机的容器网络。
具体的网络原理及主流开源网络工具的原理和配置详见第7章的说明。
2.6 内网中的Kubernetes相关配置
Kubernetes在能够访问Internet网络的环境中使用起来非常方便：
一方面，在docker.io和gcr.io网站中已经存在了大量官方制作的Docker镜像；
另一方面，GCE、AWS提供的云平台已经成熟，用户通过租用一定的空间来部署Kubernetes集群也很简便。
但是，许多企业内部由于安全原因无法访问Internet，
需要通过创建一个内部的私有Docker Registry，并修改一些Kubernetes的配置，来启动内网中的Kubernetes集群。
2.6.1 Docker Private Registry（私有Docker镜像库）
使用Docker提供的Registry镜像创建一个私有镜像仓库。
详细的安装步骤请参考Docker的官方文档https://docs.docker.com/registry/deploying/。
2.6.2 kubelet配置
由于在Kubernetes中是以Pod而不是以Docker容器为管理单元的，在kubelet创建Pod时，还通过启动一个名为k8s.gcr.io/pause:3.1的镜像来实现Pod的概念。
该镜像存在于谷歌镜像库k8s.gcr.io中，需要通过一台能够连上Internet的服务器将其下载，导出文件，再push到私有Docker Registry中。
之后，可以给每个Node的kubelet服务都加上启动参数--pod-infra-container-image，指定为私有Docker Registry中pause镜像的地址。
例如：# cat /etc/kubernetes/kubelet
kubelet_args="--kubeconfig=/etc/kubernetes/kubeconfig --hostname-override=192.168.18.3 --log-dir=/var/log/kubernets --v=0 --pod-infra-container-image=myregistry/pause:3.1"
然后重启kubelet服务：
# systemctl restart kubelet
通过以上设置就在内网环境中搭建了一个企业内部的私有容器云平台。
2.7 Kubernetes的版本升级
2.7.1 二进制升级
Kubernetes的版本升级需要考虑到不要让当前集群中正在运行的容器受到影响。
应对集群中的各Node逐个进行隔离，然后等待在其上运行的容器全部执行完成，再更新该Node上的kubelet和kube-proxy服务，将全部Node都更新完成后，再更新Master的服务。
通过官网获取最新版本的二进制包kubernetes.tar.gz，解压后提取服务的二进制文件。
逐个隔离Node，等待在其上运行的全部容器工作完成后，更新kubelet和kube-proxy服务文件，然后重启这两个服务。
更新Master的kube-apiserver、kube-controller-manager、kube-scheduler服务文件并重启。
2.7.2 使用kubeadm进行集群升级
kubeadm提供了upgrade命令用于对kubeadm安装的Kubernetes集群进行升级。
这一功能提供了从1.10到1.11、从1.11到1.12、从1.12到1.13及从1.13到1.14的升级能力，这里试用一下从1.13到1.14的升级。
开始之前需要注意：
虽然kubeadm的升级不会触及工作负载，但还是要在升级之前做好备份。
升级过程可能会因为Pod的变化而造成容器重启。
继续以CentOS 7环境为例，首先需要升级的是kubeadm：
# yum install -y kubeadm-1.14.0 --disableexcludes=kubernetes
查看kubeadm的版本：
# kubeadm version
接下来查看kubeadm的升级计划：
# kubeadm upgrade plan
会出现预备升级的内容描述：
Running pre-flight check.
[upgrade/versions] kubeadm version: v1.14.0
按照任务指引进行升级：
# kubeadm upgrade apply 1.14.0
[upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]
输入“y”，确认之后，开始进行升级。
运行完成之后，再次查询版本：
# kubectl version
可以看到，虽然kubectl还是1.13.2，服务端的控制平面已经升级到了1.14.0，但是查看Node版本，会发现Node版本还是滞后的：
# kubectl get nodes
然后可以对节点配置进行升级：
# kubeadm upgrade node config --kubelet-version 1.14.0
接下来，按照和二进制升级一样的步骤将kubelct升级，这样就完成了集群的整体升级：
# kubectl get nodes
2.8 Kubernetes核心服务配置详解
2.1节对Kubernetes各服务启动进程的关键配置参数进行了简要说明，实际上Kubernetes的每个服务都提供了许多可配置的参数。
这些参数涉及安全性、性能优化及功能扩展（Plugin）等方方面面。
全面理解和掌握这些参数的含义和配置，对Kubernetes的生产部署及日常运维都有很大的帮助。
每个服务的可用参数都可以通过运行“cmd --help”命令进行查看，其中cmd为具体的服务启动命令，
例如kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy等。
另外，可以通过在命令的配置文件（例如/etc/kubernetes/kubelet等）中添加“--参数名=参数取值”语句来完成对某个参数的配置。
本节将对Kubernetes所有服务的参数进行全面介绍，为了方便学习和查阅，对每个服务的参数都用一个小节进行详细说明。
2.8.1 公共配置参数
公共配置参数适用于所有服务，如表2.3所示的参数可用于kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy。
本节对这些参数进行统一说明，不再在每个服务的参数列表中列出。
表2.3 公共配置参数表
2.8.2 kube-apiserver启动参数
对kube-apiserver启动参数的详细说明如表2.4所示。
表2.4 对kube-apiserver启动参数的详细说明
2.8.3 kube-controller-manager启动参数
对kube-controller-manager启动参数的详细说明如表2.5所示。
表2.5 对kube-controller-manager启动参数的详细说明
2.8.4 kube-scheduler启动参数
对kube-scheduler启动参数的详细说明如表2.6所示。
表2.6 对kube-scheduler启动参数的详细说明
2.8.5 kubelet启动参数
对kubelet启动参数的详细说明如表2.7所示。
表2.7 对kubelet启动参数的详细说明
2.8.6 kube-proxy启动参数
对kube-proxy启动参数的详细说明见表2.8。
表2.8 对kube-proxy启动参数的详细说明
2.9 CRI（容器运行时接口）详解
归根结底，Kubernetes Node（kubelet）的主要功能就是启动和停止容器的组件，我们称之为容器运行时（Container Runtime），其中最知名的就是Docker了。
为了更具扩展性，Kubernetes从1.5版本开始就加入了容器运行时插件API，即Container Runtime Interface，简称CRI。
2.9.1 CRI概述
每个容器运行时都有特点，因此不少用户希望Kubernetes能够支持更多的容器运行时。
Kubernetes从1.5版本开始引入了CRI接口规范，通过插件接口模式，Kubernetes无须重新编译就可以使用更多的容器运行时。
CRI包含Protocol Buffers、gRPC API、运行库支持及开发中的标准规范和工具。
Docker的CRI实现在Kubernetes 1.6中被更新为Beta版本，并在kubelet启动时默认启动。
可替代的容器运行时支持是Kubernetes中的新概念。
在Kubernetes 1.3发布时，rktnetes项目同时发布，让rkt容器引擎成为除Docker外的又一选择。
然而，不管是Docker还是rkt，都用到了kubelet的内部接口，同kubelet源码纠缠不清。
这种程度的集成需要对kubelet的内部机制有非常深入的了解，还会给社区带来管理压力，这就给新生代容器运行时造成了难于跨越的集成壁垒。
CRI接口规范试图用定义清晰的抽象层清除这一壁垒，让开发者能够专注于容器运行时本身。
在通向插件式容器支持及建设健康生态环境的路上，这是一小步，也是很重要的一步。
2.9.2 CRI的主要组件
kubelet使用gRPC框架通过UNIX Socket与容器运行时（或CRI代理）进行通信。
在这个过程中kubelet是客户端，CRI代理（shim）是服务端，如图2.3所示。
Protocol Buffers API包含两个gRPC服务：ImageService和RuntimeService。
ImageService提供了从仓库拉取镜像、查看和移除镜像的功能。
RuntimeService负责Pod和容器的生命周期管理，以及与容器的交互（exec/attach/port-forward）。
rkt和Docker这样的容器运行时可以使用一个Socket同时提供两个服务，
在kubelet中可以用--container-runtime-endpoint和--image-service-endpoint参数设置这个Socket。
2.9.3 Pod和容器的生命周期管理
Pod由一组应用容器组成，其中包含共有的环境和资源约束。在CRI里，这个环境被称为PodSandbox。
Kubernetes有意为容器运行时留下一些发挥空间，它们可以根据自己的内部实现来解释PodSandbox。
对于Hypervisor类的运行时，PodSandbox会具体化为一个虚拟机。其他例如Docker，会是一个Linux命名空间。
在v1alpha1 API中，kubelet会创建Pod级别的cgroup传递给容器运行时，并以此运行所有进程来满足PodSandbox对Pod的资源保障。
在启动Pod之前，kubelet调用RuntimeService.RunPodSandbox来创建环境。这一过程包括为Pod设置网络资源（分配IP等操作）。
PodSandbox被激活之后，就可以独立地创建、启动、停止和删除不同的容器了。
kubelet会在停止和删除PodSandbox之前首先停止和删除其中的容器。
kubelet的职责在于通过RPC管理容器的生命周期，实现容器生命周期的钩子，存活和健康监测，以及执行Pod的重启策略等。
RuntimeService服务包括对Sandbox和Container操作的方法，下面的伪代码展示了主要的RPC方法。
2.9.4 面向容器级别的设计思路
众所周知，Kubernetes的最小调度单元是Pod，它曾经可能采用的一个CRI设计就是复用Pod对象，使得容器运行时可以自行实现控制逻辑和状态转换，
这样一来，就能极大地简化API，让CRI能够更广泛地适用于多种容器运行时。但是经过深入讨论之后，Kubernetes放弃了这一想法。
首先，kubelet有很多Pod级别的功能和机制（例如crash-loop backoff机制），如果交给容器运行时去实现，则会造成很重的负担；
其次，且更重要的是，Pod标准还在快速演进中，很多新功能（如初始化容器）都是由kubelet完成管理的，无须交给容器运行时实现。
CRI选择了在容器级别进行实现，使得容器运行时能够共享这些通用特性，以获得更快的开发速度。
这并不意味着设计哲学的改变—kubelet要负责、保证容器应用的实际状态和声明状态的一致性。
Kubernetes为用户提供了与Pod及其中的容器进行交互的功能（kubectl exec/attach/port- forward）。
kubelet目前提供了两种方式来支持这些功能。
（1）调用容器的本地方法。
（2）使用Node上的工具（例如nsenter及socat）。
因为多数工具都假设Pod用Linux namespace做了隔离，因此使用Node上的工具并不是一种容易移植的方案。
在CRI中显式定义了这些调用方法，让容器运行时进行具体实现。
下面的伪代码显示了Exec、Attach、PortForward这几个调用需要实现的RuntimeService方法。
目前还有一个潜在问题是，kubelet处理所有的请求连接，使其有成为Node通信瓶颈的可能。
在设计CRI时，要让容器运行时能够跳过中间过程。
容器运行时可以启动一个单独的流式服务来处理请求（还能对Pod的资源使用情况进行记录），并将服务地址返回给kubelet。
这样kubelet就能反馈信息给API Server，使之可以直接连接到容器运行时提供的服务，并连接到客户端。
2.9.5 尝试使用新的Docker-CRI来创建容器
要尝试新的Kubelet-CRI-Docker集成，只需为kubelet启动参数加上--enable-cri=true开关来启动CRI。
这个选项从Kubernetes 1.6开始已经作为kubelet的默认选项了。
如果不希望使用CRI，则可以设置--enable-cri=false来关闭这个功能。
查看kubelet的日志，可以看到启用CRI和创建gRPC Server的日志。
创建一个Deployment：
# kubectl run nginx --image=nginx
查看Pod的详细信息，可以看到将会创建沙箱（Sandbox）的Event：
# kubectl describe pod nginx
这表明kubelet使用了CRI接口来创建容器。
2.9.6 CRI的进展
目前已经有多款开源CRI项目可用于Kubernetes：Docker、CRI-O、Containerd、frakti（基于Hypervisor的容器运行时），
各CRI运行时的安装手册可参考官网https://kubernetes.io/docs/setup/cri/的说明。
2.10 kubectl命令行工具用法详解
kubectl作为客户端CLI工具，可以让用户通过命令行对Kubernetes集群进行操作。
本节对kubectl的子命令和用法进行详细说明。
2.10.1 kubectl用法概述
kubectl命令行的语法如下：
# kubectl [command] [TYPE] [NAME] [flags]
其中，command、TYPE、NAME、flags的含义如下。
（1）command：子命令，用于操作Kubernetes集群资源对象的命令，例如create、delete、describe、get、apply等。
（2）TYPE：资源对象的类型，区分大小写，能以单数、复数或者简写形式表示。例如以下3种TYPE是等价的。
# kubectl get pod pod1
# kubectl get pods pod1
# kubectl get po pod1
（3）NAME：资源对象的名称，区分大小写。如果不指定名称，系统则将返回属于TYPE的全部对象的列表，例如$ kubectl get pods将返回所有Pod的列表。
（4）flags：kubectl子命令的可选参数，例如使用“-s”指定API Server的URL地址而不用默认值。
kubectl可操作的资源对象类型及其缩写如表2.9所示。
表2.9 kubectl可操作的资源对象类型及其缩写
表2.9-1kubectl可操作的资源对象类型
在一个命令行中也可以同时对多个资源对象进行操作，以多个TYPE和NAME的组合表示，示例如下。
示例1:获取多个Pod的信息：
# kubectl get pods pod1 pod2
示例2:获取多种对象的信息：
# kubectl get pod/pod1 rc/rc1
示例3:同时应用多个YAML文件，以多个-f file参数表示：
# kubectl get pod -f pod1.yaml -f pod2.yaml
# kubectl create -f pod1.yaml -f rc1.yaml -f service1.yaml
2.10.2 kubectl子命令详解
kubectl的子命令非常丰富，涵盖了对Kubernetes集群的主要操作，包括资源对象的创建、删除、查看、修改、配置、运行等。
详细的子命令如表2.10所示。
表2.10 kubectl子命令详解
2.10.3 kubectl参数列表
kubectl命令行的公共启动参数如表2.11所示。
表2.11 kubectl命令行的公共启动参数
每个子命令（如create、delete、get等）还有特定的flags参数，可以通过$ kubectl [command] --help命令进行查看。
2.10.4 kubectl输出格式
kubectl命令可以用多种格式对结果进行显示，输出的格式通过-o参数指定：
# kubectl [command] [TYPE] [NAME] -o=<output_format>
根据不同子命令的输出结果，可选的输出格式如表2.12所示。
表2.12 kubectl命令的可选输出格式列表
常用的输出格式示例如下。
（1）显示Pod的更多信息：
# kubectl get pod <pod-name> -o wide
（2）以YAML格式显示Pod的详细信息：
# kubectl get pod <pod-name> -o yaml
（3）以自定义列名显示Pod的信息：
# kubectl get pod <pod-name> -o=custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
（4）基于文件的自定义列名输出：
# kubectl get pod <pod-name> -o=custom-columns-file=template.txt
template.txt文件的内容为：
NAME RSRC
metadata.name metadata.resourceVersion
输出结果为：
NAME RSRC
pod-name 52305
另外，可以将输出结果按某个字段排序，通过--sort-by参数以jsonpath表达式进行指定：
# kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
例如，按照名称进行排序：
# kubectl get pods --sort-by=.metadata.name
2.10.5 kubectl操作示例
本节将一些常用的kubectl操作作为示例进行说明。
1.创建资源对象
根据YAML配置文件一次性创建Service和RC：
# kubectl create -f my-service.yaml -f my-rc.yaml
根据<directory>目录下所有.yaml、.yml、.json文件的定义进行创建：
# kubectl create -f <directory>
2.查看资源对象
查看所有Pod列表：
# kubectl get pods
查看RC和Service列表：
# kubectl get rc,service
3.描述资源对象
显示Node的详细信息：
# kubectl describe nodes <node-name>
显示Pod的详细信息：
# kubectl describe pods/<pod-name>
显示由RC管理的Pod的信息：
# kubectl describe pods <rc-name>
4.删除资源对象
基于pod.yaml定义的名称删除Pod：
# kubectl delete -f pod.yaml
删除所有包含某个Label的Pod和Service：
# kubectl delete pods,services -l name=<label-name>
删除所有Pod：
# kubectl delete pods --all
5.执行容器的命令
执行Pod的date命令，默认使用Pod中的第1个容器执行：
# kubectl exec <pod-name> date
指定Pod中的某个容器执行date命令：
# kubectl exec <pod-name> -c <container-name> date
通过bash获得Pod中某个容器的TTY，相当于登录容器：
# kubectl exec -it <pod-name> -c <container-name> /bin/bash
6.查看容器的日志
查看容器输出到stdout的日志：
# kubectl logs <pod-name>
跟踪查看容器的日志，相当于tail -f命令的结果：
# kubectl logs -f <pod-name> -c <container-name>
7.创建或更新资源对象
用法和kubectl create类似，逻辑稍有差异：如果目标资源对象不存在，则进行创建；否则进行更新。例如：
# kubectl apply -f app.yaml
8.在线编辑运行中的资源对象
可以使用kubectl edit命令编辑运行中的资源对象，例如使用下面的命令编辑运行中的一个Deployment：
# kubectl edit deploy nginx
在命令执行之后，会通过YAML格式展示该对象的定义和状态，用户可以对代码进行编辑和保存，从而完成对在线资源的直接修改。
9.将Pod的开放端口映射到本地
将集群上Pod的80端口映射到本地的8888端口，在浏览器http://127.0.0.1:8888中就能够访问到容器提供的服务了：
# kubectl port-forward --address 0.0.0.0 pod/nginx-6ddbbc47fb-sfdcv 8888:80
10.在Pod和本地之间复制文件
把Pod上的/etc/fstab复制到本地的/tmp目录：
# kubectl cp nginx-6ddbbc47fb-sfdcv:/etc/fstab /tmp
11.资源对象的标签设置
为default namespace设置testing=true标签：
# kubectl label namespaces default testing=true
12.检查可用的API资源类型列表
该命令经常用于检查特定类型的资源是否已经定义，列出所有资源对象类型：
# kubectl api-resources
13.使用命令行插件
为了扩展kubectl的功能，Kubernetes从1.8版本开始引入插件机制，在1.14版本时达到稳定版。
用户自定义插件的可执行文件名需要以“kubectl-”开头，复制到$PATH中的某个目录（如/usr/local/bin），然后就可以通过kubectl <plugin-name>运行自定义插件了。
例如，实现一个名为hello的插件，其功能为在屏幕上输出字符串“hello world”：
新建名为kubectl-hello的可执行脚本文件，其内容为
echo "hello world"
复制kubectl-hello文件到/usr/local/bin/目录下，就完成了安装插件的工作。
然后在kubectl命令后带上插件名称就能使用这个插件了：
# kubectl hello
使用kubectl plugin list命令可以查看当前系统中已安装的插件列表：
# kubectl plugin list
更完整的插件开发示例可以从https://github.com/kubernetes/sample-cli-plugin找到。