一、什么是K8S？
Kubernetes是用于自动部署，扩展，管理容器化应用程序的开源系统，他将组成应用程序的容器组合成逻辑单元，便于管理和服务发现
二、为什么要学习K8S？
其实K8S的概念也概括了为什么要学习K8S，在当今互联网流量爆发的时代，继续服务器业务量的扩展，纵向的扩展服务器节点的性能（cpu、mem和存储）显然不太现实，所以横向的通过多节点支持并发协作的方式来实现业务的扩展便成了大家容易接受的方法，但是横向的扩展又会带来一个巨大的问题，就是各节点任务的管理和协作，这就是编排引擎之所以火的原因。
三、下面看下K8S整体架构：
基本概念：
API Server（kube-apiserver）
API Server 提供 HTTP/HTTPS RESTful API，即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口，各种客户端工具（CLI 或 UI）以及 Kubernetes 其他组件可以通过它管理 Cluster 的各种资源。
Scheduler（kube-scheduler）
Scheduler 负责决定将 Pod 放在哪个 Node 上运行。Scheduler 在调度时会充分考虑 Cluster 的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。
Controller Manager（kube-controller-manager）
Controller Manager 负责管理 Cluster 各种资源，保证资源处于预期的状态。Controller Manager 由多种 controller 组成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。
不同的 controller 管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。
etcd
etcd 负责保存 Kubernetes Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会快速地通知 Kubernetes 相关组件。
Pod 网络
Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。
下面是node上才有的服务：
kubelet
kubelet 是 Node 的 agent，当 Scheduler 确定在某个 Node 上运行 Pod 后，会将 Pod 的具体配置信息（image、volume 等）发送给该节点的 kubelet，kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。
kube-proxy
service 在逻辑上代表了后端的多个 Pod，外界通过 service 访问 Pod。service 接收到的请求是如何转发到 Pod 的呢？这就是 kube-proxy 要完成的工作。
每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。
Pod 网络
Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。
四、K8S应用的部署流程：
① kubectl 发送部署请求到 API Server。
② API Server 通知 Controller Manager 创建一个 deployment 资源。
③ Scheduler 执行调度任务，将两个副本 Pod 分发到 k8s-node1 和 k8s-node2。
④ k8s-node1 和 k8s-node2 上的 kubelet 在各自的节点上创建并运行 Pod。
五、部署应用的两种方式：
1、一个直接通过命令：
kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
2、一个通过yaml文件和kubectl apply命令：
kubectl apply -f nginx.yml
Nginx.yml文件展示如下：
六、K8s的网络模型：
Kubernetes 采用的是基于扁平地址空间的网络模型，集群中的每个 Pod 都有自己的 IP 地址，Pod 之间不需要配置 NAT 就能直接通信。另外，同一个 Pod 中的容器共享 Pod 的 IP，能够通过 localhost 通信。
这种网络模型对应用开发者和管理员相当友好，应用可以非常方便地从传统网络迁移到 Kubernetes。每个 Pod 可被看作是一个个独立的系统，而 Pod 中的容器则可被看做同一系统中的不同进程。
下面讨论在这个网络模型下集群中的各种实体如何通信。知识点前面都已经涉及，这里可当做复习和总结。
1、Pod 内容器之间的通信
当 Pod 被调度到某个节点，Pod 中的所有容器都在这个节点上运行，这些容器共享相同的本地文件系统、IPC 和网络命名空间。
不同 Pod 之间不存在端口冲突的问题，因为每个 Pod 都有自己的 IP 地址。当某个容器使用 localhost 时，意味着使用的是容器所属 Pod 的地址空间。
比如 Pod A 有两个容器 container-A1 和 container-A2，container-A1 在端口 1234 上监听，当 container-A2 连接到 localhost:1234，实际上就是在访问 container-A1。这不会与同一个节点上的 Pod B 冲突，即使 Pod B 中的容器 container-B1 也在监听 1234 端口。
2、Pod 之间的通信
Pod 的 IP 是集群可见的，即集群中的任何其他 Pod 和节点都可以通过 IP 直接与 Pod 通信，这种通信不需要借助任何的网络地址转换、隧道或代理技术。Pod 内部和外部使用的是同一个 IP，这也意味着标准的命名服务和发现机制，比如 DNS 可以直接使用。
3、Pod 与 Service 的通信
Pod 间可以直接通过 IP 地址通信，但前提是 Pod 得知道对方的 IP。在 Kubernetes 集群中， Pod 可能会频繁的销毁和创建，也就是说 Pod 的 IP 不是固定的。为了解决这个问题，Service 提供了访问 Pod 的抽象层。无论后端的 Pod 如何变化，Service 都作为稳定的前端对外提供服务。同时，Service 还提供了高可用和负载均衡功能，Service 负责将请求转发给正确的 Pod。
4、外部访问
无论是 Pod 的 IP 还是 Service 的 Cluster IP，它们只能在 Kubernetes 集群中可见，对集群之外的世界，这些 IP 都是私有的。
Kubernetes 提供了两种方式让外界能够与 Pod 通信：
a、NodePort
Service 通过 Cluster 节点的静态端口对外提供服务。外部可以通过 <NodeIP>:<NodePort> 访问 Service。
b、LoadBalancer
Service 利用 cloud provider 提供的 load balancer 对外提供服务，cloud provider 负责将 load balancer 的流量导向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
七、deployment、pod和service区别：
- 首先pod是k8s中运行的最小单元，一个pod中可能包含多个docker，一个pod中的docker共用资源和网络栈
- Deployment是对pod副本的管理工具，将pod的状态运行在pod的定义状态，负责pod的创建升级更新回滚等
- Service是对外提供统一的服务并将外来的消息分布给pod
八、下面来理解下几个容易混淆的概念：
- Deployment 、Daemonset、 Cronjob 、statefulset 为控制器(controller)部署完成称为应用
- service ,endpoint, ingress 为服务类型的应用
