k8s是什么
Kubernetes一个用于容器集群的自动化部署、扩容以及运维的开源平台。通过Kubernetes，你可以快速有效地响应用户需求;快速而有预期地部署你的应用;极速地扩展你的应用;无缝对接新应用功能;节省并优化硬件资源的使用。为容器编排管理提供了完整的开源方案。
几个关键词:
快速有效地响应
个人理解为两个方面：一方面、新增或者修改需求时，可以快速进行部署测试(CICD)；另一方面、kubernetes可以根据不同条件进行动态扩缩容，kubernetes会自动将用户服务模块增加更多实例以保证当前的系统访问量。
快速而有预期地
Kubernetes在更新升级的时候支持滚动升级、蓝绿发布等机制；同时配合Istio服务网格还能够实现A/B测试，根据发布者的需求进行应用发布。
急速的扩展
Kubernetes内部有完善的服务注册发现机制，当某个服务的实例增加时，kubernetes会自动将其加入服务列表中，免除在传统运维中需要人工维护服务列表的问题。
对接新应用
kubernetes是一个通用的容器编排框架，支持不同类型的语言，或者是语言无关的，新增加的应用都会以一个新的对象进行接入。
节省并优化硬件资源
kubernetes在部署应用时会自动检查各个服务器的cpu与内存使用量，同时会根据服务申请的cpu与内存资源，将服务部署到最合适的服务器。
因kubernetes名字过长，一般简称为k8s，因为k与s之间有8个字母，故而称之。
诞生原因
通过之前的章节我们了解到：一个正在运行的 Linux 容器，其实可以被“一分为二，动静分离”地看待：
一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分我们称为“容器镜像”（Container Image），是容器的静态视图；
一个由 Namespace+Cgroups 构成的隔离环境，这一部分我们称为“容器运行时”（Container Runtime），是容器的动态视图。
从一个开发者和单一的容器镜像，到无数开发者和庞大的容器集群，容器技术实现了从“容器”到“容器云”的飞跃，标志着它真正得到了市场和生态的认可。
这其中，最具代表性的容器编排工具，当属 Docker 公司的 Compose+Swarm 组合，以及 Google 与 RedHat 公司共同主导的 Kubernetes 项目。
k8s整体架构
Kubernetes主要由以下几个核心组件组成：
- etcd保存了整个集群的状态；
- apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
- controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
- scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
- kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
- Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
- kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；
除了核心组件，还有一些推荐的Add-ons：
- kube-dns负责为整个集群提供DNS服务
- Ingress Controller为服务提供外网入口
- Heapster提供资源监控
- Dashboard提供GUI
- Federation提供跨可用区的集群
- Fluentd-elasticsearch提供集群日志采集、存储与查询
基于docker的流程
基于k8s的流程
master节点(控制节点)
master节点由三个紧密协作的独立组件组合而成，它们分别是：
- 负责 API 服务的 kube-apiserver
- 负责调度的 kube-scheduler
- 负责容器编排的 kube-controller-manager。
整个集群的持久化数据，则由 kube-apiserver 处理后保存在 Etcd 中。
node节点(计算节点)
node节点上最核心的部分，则是一个叫作 kubelet 的组件。
kubelet 一方面负责同Docker打交道，另一方面负责调用网络插件和存储插件为容器配置网络和持久化存储。
k8s设计理念
所以，Kubernetes 项目最主要的设计思想是，从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。
比如，Kubernetes 项目对容器间的“访问”进行了分类，首先总结出了一类非常常见的“紧密交互”的关系，即：这些应用之间需要非常频繁的交互和访问；又或者，它们会直接通过本地文件进行信息交换。
在常规环境下，这些应用往往会被直接部署在同一台机器上，通过 Localhost 通信，通过本地磁盘目录交换文件。而在 Kubernetes 项目中，这些容器则会被划分为一个“Pod”，Pod 里的容器共享同一个 Network Namespace、同一组数据卷，从而达到高效率交换信息的目的。
而对于另外一种更为常见的需求，比如 Web 应用与数据库之间的访问关系，Kubernetes 项目则提供了一种叫作“Service”的服务。像这样的两个应用，往往故意不部署在同一台机器上，这样即使 Web 应用所在的机器宕机了，数据库也完全不受影响。可是，我们知道，对于一个容器来说，它的 IP 地址等信息不是固定的，那么 Web 应用又怎么找到数据库容器的 Pod 呢？
所以，Kubernetes 项目的做法是给 Pod 绑定一个 Service 服务，而 Service 服务声明的 IP 地址等信息是“终生不变”的。这个Service 服务的主要作用，就是作为 Pod 的代理入口（Portal），从而代替 Pod 对外暴露一个固定的网络地址。
这样，对于 Web 应用的 Pod 来说，它需要关心的就是数据库 Pod 的 Service 信息。不难想象，Service 后端真正代理的 Pod 的 IP 地址、端口等信息的自动更新、维护，则是 Kubernetes 项目的职责。
像这样，围绕着容器和 Pod 不断向真实的技术场景扩展，我们就能够摸索出一幅如下所示的 Kubernetes 项目核心功能的“全景图”。
Kubernetes 项目如何启动一个容器化任务呢？
比如，我现在已经制作好了一个 Nginx 容器镜像，希望让平台帮我启动这个镜像。并且，我要求平台帮我运行两个完全相同的 Nginx 副本，以负载均衡的方式共同对外提供服务。
如果没有 Kubernetes 的话，可能需要启动两台虚拟机，分别安装两个 Nginx，然后使用一个类lb应用为这两个虚拟机做一个虚拟 IP。
而如果使用 Kubernetes 项目呢？你需要做的则是编写如下这样一个 YAML 文件（比如名叫 nginx-deployment.yaml）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
在上面这个 YAML 文件中，我们定义了一个 Deployment 对象，它的主体部分（spec.template 部分）是一个使用 Nginx 镜像的 Pod，而这个 Pod 的副本数是 2（replicas=2）。
kubectl create -f nginx-deployment.yaml
搭建k8s集群
- kubeadm
- minikube
- kops
- tectonic
- play-with-k8s.com
