目录
1.云原生
2.kubernetes
2.1 Overview
2.2 Core Concept
2.2.1 pods
2.2.2 replication Controllers
2.2.3 services
2.2.4 volumes： attaching disk storage to containers
2.2.5 ConfigMaps and Secrets: configuring applications
2.2.6 Access pod metadata and other resources from applicaion
2.2.7 Deployments:updating applications declaratively
2.2.8 StatefulSets: deploying replicated stateful applications
1.云原生
云原生没有明确的定义，从技术的角度主要包括下面7大部分
微服务：服务和服务之间通过高内聚低耦合的方式交互
容器：作为微服务的承载载体
容器编排：解决微服务在生产环境中的部署问题
服务网格：解决了服务之间的通信
声明式API：让系统更加健壮
命令式API：可以直接发出服务器执行的命令，如运行容器，停止容器
声明式API：可以声明期望状态，系统将不断的调整到期望状态
不可变基础设施：方便快速扩展升级新系统
DevOps：缩短研发周期，增加部署频率和速度
2.kubernetes
容器编排是一个重要的技术，其中kubernetes（k8s）截至发稿日已经成为主导的容器编排技术。
2.1 Overview
k8s可以方便管理项目，将一个大项目拆成若干小项目，便于管理，而且屏蔽了底层的物理机器，让不是专业的人也可以轻松部署自己的应用，并且支持回滚，重启等多种机智。
k8s集群
分为control（master）和worker
master node
K8s API:你和以及其他的控制平台交互
Scheduler:管理APP的时间表
Manager:管理集群功能的，如复制，追踪和处理节点失败
Etcd:：一个可信的分布式数据库，永久存储集群配置
Worker node:
Docker：容器
Kubelet：和API Server交互，管理节点内容器
Kube-proxy：处理应用之间的网络流量负载平衡
2.2 Core Concept
2.2.1 pods
pod管理container，容器是微服务的载体，然后pod可以管理容器
因为container的设计是通常里面是单线程（有些程序线程里有子线程），所以需要pod组织起多个线程，也就是容器，
通常一个pod里是功能相似或者相互辅佐的容器。为了区分pod，可以打label等
2.2.2 replication Controllers
因为单纯起了一个pod，无法管理，挂掉了也不知道怎么重启，但有replication controllers，pod挂掉后可以重启。这个是管理pod的。
Liveness probes：检查pod是否正常运行，3种方式
1.Http get
2.Tcp socket
3.Exec pod
RC：管理pod，让其run healthy，譬如挂掉重启，相比于pod本身的重启，其可以跨worker node重启部署
但其缺点是只能管理一种label select的pod
RS：replicaSet：可以管理多个label的pod（现在用RS的比较多）
DaemonSet：实现在每个node（or指定的node，通过给node打label来实现区分不同的node）部署一个pod（像抓取log这种通用的每个节点都需要的node）。
特点：关心node（RS，RC不关心）；每个node上只部署一个pod，而不是多个
Job resource：到pod进程结束后，就结束这个pod（RC，RS，DS并不具备这种特性）
2.2.3 services
services：是客户端和pod间交流通信
service的类型有四种:
1. ExternalName: 用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取服务。
它的值必须是 FQDN, 此FQDN为集群内部的FQDN, 即: ServiceName.Namespace.Domain.LTD.
然后CoreDNS接受到该FQDN后，能解析出一个CNAME记录, 该别名记录为真正互联网上的域名.
如: www.test.com,
2. ClusterIP： 用于为集群内Pod访问时,提供的固定访问地址,默认是自动分配地址,可使用ClusterIP关键字指定固定IP.
3. NodePort: 用于为集群外部访问Service后面Pod提供访问接入端口.
这种类型的service工作流程为:
Client----->NodeIP:NodePort----->ClusterIP:ServicePort----->PodIP:ContainerPort
4. LoadBalancer: 用于当K8s运行在一个云环境内时,若该云环境支持LBaaS,则此类型可自动触发创建
一个软件负载均衡器用于对Service做负载均衡调度.
因为外部所有Client都访问一个NodeIP,该节点的压力将会很大, 而LoadBalancer则可解决这个问题。
而且它还直接动态监测后端Node是否被移除或新增了，然后动态更新调度的节点数。
上图的访问：回复是任意pod，而不是某个确定的pod。sessionaffinity解决这个事情
上图的load balancer的设计主要是为了云
endpoint有点类似于注册表
PS：探针的两种类型
Living probes探测不存在就消灭
Readness probes单纯的探测
DNS返回一个单一IP-cluster IP，但是如果不想返回则会返回全部pods ip
2.2.4 volumes： attaching disk storage to containers
volunmes给容器提供存储的：不是单独于kubernetes的项目，不能自己删除和创建
2.2.5 ConfigMaps and Secrets: configuring applications
configMap和secrets的作用：解耦配置和容器，这个配置可以用到别的pod上
不同：secrets存放机密信息，configmap存放普通信息
2.2.6 Access pod metadata and other resources from applicaion
通过downward API去和pod交互，有两种方式，一种env，一种是挂载volumn
ambassador可以放在pod内负责和API server通信，example，ambassador可以将pod内的http通信，和pod外的https通信连接起来
2.2.7 Deployments:updating applications declaratively
1.通过replicationController控制update，全部删除，全部更新，有短暂间隔
2.全部替换
3.通过2个controller
deployment（现在的常用方式）,
比controller更高级,之前的方法需要打开终端操作等待，现在的deployment就不用了,而且稍微修改一下模板就可以修改了，之前controller就不行了
2.2.8 StatefulSets: deploying replicated stateful applications
什么叫stateful，存储网络编号都是固定的，如创建pod，其编号是从开始，而stateless是随机生成一个数字作为pod的名字。如果stateful的pod消失，恢复的话pod名字，网络存储均不变
