kubectl使用基础与示例
Kubernetes API 是管理其各种资源对象的唯一入口，它提供了一个 RESTful 风格的 CRUD (Create 、 Read 、 Update 和 Delete)接口用于查询和修改集群状态，并将结果存储于集群状态存储系统 etcd 中 。 事实上，API server 也是用于更新 etcd 中资源对象状态的唯一途径， Kubernetes 的其他所有组件和客户端都要通过它来完成查询或修改操作，如下图所示，它们都算得上是 API server 的客户端。
任何 RESTful 风格 API 中的核心概念都是“资源”（ resource ），它是具有类型、API Server 通过认证（ Authentication ）、 授权（ Authorization ）和准入控制（ Admission Control ）等来管理对资源的访问请求，因此，来自于任何客户端（如 kubectl、kubelet、kube-proxy 等）的访问请求都必须事先完成认证之后方可进行后面的其他操作。 API Server 支持多种认证方式，客户端可以使用命令行选项或专用的配置文件（称为 kube-config ）提供认证信息。 相关的内容将在后面的章节中给予详细说明。
kubectl 的核心功能在于通过 API Server 操作 Kubernetes 的各种资源对象，它支持三种 操作方式，其中直接命令式（ Imperative commands ）的使用最为简便，是了解 Kubernetes 集 群管理的一种有效途径。
控制平面系统组件介绍
1.apiserver
apiserver默认监听在主机的6443端口，6443是https协议（早期的apiserver提供两个端口，一个http的8080和https的6443，考虑到8080 http协议不安全所以给去掉了），apiserver的6443是唯一接入master的端口，apiserver默认情况下它要做用户认证(双向认证)，如果认证不通过的，则没有权限在kubernetes之上做任何操作。
2.scheduler
如果我们要创建一个Pod，就要被scheduler所调度到它评估后的Node上进行创建。
3.Controller-manager
运行中的Pod，如果有需要扩容缩容等其它操作，都依靠自Controller控制器，Controller还能进行Pod的故障自愈。
kubernetes集群重要组件
Pod：用来运行容器的Pod。
Pod Controller：Pod控制器，包含多种ReplicationController、ReplicaSet、Deployment、StatefulSet、Job等。
Service：用来代理Pod的中间层。
数据平面核心工作
数据平面即为Node，在Node上最核心的两件事情如下：
- 1.运行Pod
- 2.把Pod相关的Service转换为当前节点上的iptables或则ipvs（由kube-proxy组件来完成，kube-proxy也是控制平面apiserver的客户端，kube-proxy也是始终监视watch着apiserver的资源变动(尤其是service的变动，它会把每一个service上每一个跟当前Pod有关的资源变动转换为iptables或则ipvs规则)）。
Pod的创建方式：
- 1.直接创建Pod（自己负责Pod的健康状态）。
- 2.通过Pod Controller创建，Pod Controller将负责Pod的健康状态监测及故障自愈。