K8S学习笔记（二）

• K8S集群把所有节点上的资源整合到一个大的虚拟资源池，以Pod为原子单位，从虚拟池里动态分配资源，类似物理机池化分出一个个虚拟机；
• 把K8S集群看做一个系统，则Master就好像操作系统内核，pod就是抽象出来的一个个运行在user ns中的进程；
• API Server是负责接收客户端提交任务的接口，一般使用kubectl或web gui。

理解K8S最重要的一个词就是抽象，一切事物都可以抽象成一个资源对象。

最常见的核心对象：

• pod：

  • 原子运行单位，一个应用程序的单一运行实例，由共享资源且关系紧密的一个或多个应用容器构成。
  • 同一个pod中的所有容器使用lo通信，与pod外其他组件通信使用service资源中的cluster ip及其相应的端口完成（expose映射到外部，使集群外部客户端可以访问pod中的应用）。
  • 存储卷由pod中的所有容器共享，类似线程共享内存空间的概念。
  • 众多pod对象可以有控制器创建管理，例如创建副本，多个pod运行同一应用，每个pod完全一致。
  • master会将pod调度到基于期望状态和资源可用的节点运行，期间指向镜像仓库（网络或者harbor），并在node本地启动容器，master会将整个集群状态保存在etcd中，并通过apiserver共享给集群的各组件和客户端。

• Controller：

  • pod本身不具备自愈功能，需要控制器资源帮助实现，充分反映了用户的期望状态。
  • 通过deployment，replicaset，statefulset，daemonset，jobs等控制器，实现了例如pods期望数量无限接近（失败自愈），副本数量控制，动态扩缩容，守护进程控制，预处理任务等多种pod自身无法实现的功能。

• service：

  • pod可以拥有ip地址，但当pods crash之后，根据控制器规则生成的新的pods ip地址一定会发生变化。
  • service资源就是被用于被访问的pod对象中添加一个固定ip地址的中间层，无论下方pod ip如何变化，或删除或新增或改变，这个中间层都可以将外部流量准去引入后端pods中。
  • ClusterIP：属于私有网络，仅在集群内部可达，直接转发到pods，引入外部流量则需要NodePort并将其代理至相应的service对象的clusterip上的服务端口。
  • NodePort：相当于转发两次才会到达pods，流量->NodePort(<node ip>:3xxxx)–service->pods
  • LoadBalancer类型：转发三次了，流量->LB->NodePort(<node ip>:3xxxx)–service->pods
  • 上述三种service类型，下面都是建立在上面基础上完成的调度转发。

集群部署：
详见之前的博文，使用breeze进行部署很简单，kubeadm已经GA了，所以保证所有节点都安装kubelet，docker，kube-proxy ，部署节点安装kubeadm就可以了进行一个简单集群部署了，一般习惯把kubectl安装在master上。

基本命令，用于部署完成后检测：

#kubectl version --short=true                   //查询C/S版本分别为什么
#kubectl cluster-info                           //master的接口和CoreDNS