Overview

k8s让开发者可以自主部署应用并控制部署频率，让运维团队从监管应用转移到了监管kubernetes以及剩余的系统资源。

k8s抽象了数据中心的硬件基础设施，只对外暴露了一个巨大的资源池，使用其部署多组件应用的时候会为每一个组件选择一个合适的服务器，同时部署后保证每个组件可以轻易的发现其他组件，并彼此之间实现通信。

• k8s出现所面临的需求：

  • 从单体应用到微服务
  • 为应用程序提供一个一致的环境
  • 迈向持续交付：DevOps和无运维

• 容器：同一台机器上运行的不同组件可能会需要不同的、可能存在冲突的依赖库版本

  • 比起虚拟机，容器更加轻量级，因为每个虚拟机需要运行自己的一组系统进程，产生了除了组件进程消耗意外的额外计算资源损耗，容器只是运行在宿主机上被隔离的单个进程。
  • 虚拟机钟的应用程序执行虚拟机操作系统的系统调用，然后虚拟机内核通过管理程序来在宿主机上的物理CPU执行x86指令。容器则是完全执行运行在宿主机上的同一个内核的系统调用，这个内核时唯一一个能在宿主机上执行x86指令的内核。
  • 容器的隔离机制有两种：
    • 用Linux命名空间隔离，让每个进程只看到自己的系统视图（文件，进程，网络接口，主机名等）
    • 用Linux控制组隔离，限制了进程能使用的资源量（CPU，内存，网络带宽等），用cgroups实现
  • Docker
    • 镜像：包含了打包的应用程序与所依赖的环境，包含了应用程序可用的文件系统和其他元数据比如镜像运行时的可执行文件路径
    • 镜像仓库：镜像仓库用于存放docker镜像，以及促进不同人和电脑之间共享
    • 容器：通常是一个Linux容器，基于Docker镜像被创建，一个运行中的容器是一个运行在docker主机上的进程。
    • docker镜像由多层构成，不同镜像可能包含完全相同的层，镜像在网络上传输时如果相同的层已经被传输，那么这些层就不用再次运输。在读的时候是共享文件的，但是如果发生写操作，另一个是看不到文件变更的，因为容器镜像层是只读的，容器运行时，一个新的可写层在镜像层之上被创建，容器中进程写入底层一个文件，这个文件的拷贝在顶层被创建，进程写的是拷贝
  • rkt （读作 rock it）是docker的一个替代方案，docker本身并不提供进程隔离，实际上容器隔离是在Linux内核之上使用Linux命名空间和cgroups之类的内核特性完成，docker只是简化了这种特性的使用。rkt也是一个运行容器的平台，强调安全性，可构建性并遵从开放标准 。和Docker一样都是开放容器计划（OCI）的一部分。

k8s依赖于Linux容器的特性来运行异构应用，而无需知道这些应用的内部详情。 k8s是的在数以千计的电脑节点上运行软件时就像所有这些节点是单个大节点一样。开发者把一个应用列表提交到主节点，k8s会将他们部署到集群的工作节点，组件部署在哪个节点对于开发者和系统管理员都不用关心。

k8s的集群架构就是多个节点组成，类型分为主节点和工作节点，主节点是k8s控制和管理整个集群系统的控制系统，工作节点运行用户实际部署的应用。

• 控制面板，包含多个组件，组件运行在单个主节点或者通过副本分别部署在多个主节点上保证高可用性
  • k8s API服务器，与其他控制面板组件都要和他通信
  • Scheculer：调度应用（为每个可部署部件分配一个工作节点）
  • Controller Manager：执行集群级别的功能，比如复制组件，持续跟踪工作节点，处理节点失败等。
  • etcd：一个可靠的分布式数据存储，持久化存储集群配置
• 工作节点
  • docker，rtk或其他的容器类型
  • Kubelet：与API服务器通信，并管理它所在节点的容器
  • Kubernetes Service Porxy（kube-proxy）：负责组件之间的负载均衡网络流量

要在k8s中运行应用，先将应用打包成一个或多个容器镜像，再将镜像推送到镜像曾库，然后将应用描述发布到k8s API服务器。这个描述包括了比如容器镜像或者包含应用程序组件的容器镜像、这些组件如何相互关联，以及哪些组件需要同时运行在同一个节点上和哪些组件不需要同时运行等信息。还包括哪些组件为内部或外部客户提供服务且应该通过单个IP地址暴露。