Kubernetes技术分享
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
●
Kubernetes主要功能
● ● ●
● ● ● ●
k8s能方便地管理跨机器运行容器化的应用 提供应用部署、维护、扩展机制 集群管理、安全防护、准入机制、多应用支撑、服务注册、服务 发现、智能负载均衡、故障发现、自我修复、服务滚动升级、在 线扩容、资源配额管理 使用Docker对应用程序包装、实例化、运行 以集群的方式运行、管理跨机器的容器 解决Docker跨机器容器之间的通讯问题 k8s的自我修复机制使得容器集群总是运行在用户期望的状态
Kubernetes技术分享
架构简介 集群搭建 常用命令 应用实例
Kubernetes简介
Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个 开源版本，是一个全新的基于容器技术的分布式架构领先方案。 ● Borg是谷歌内部使用的大规模集群管理系统，基于容器技术，目 的是实现资源管理的自动化，以及跨多个数据中心的资源利用率 的最大化； ● K8s是第一个将”一切以服务为中心，一切围绕服务运转”作为指 导思想的创新型产品 ● K8s是Go语言开发，是Docker的上层架构，就好像Java与J2EE的 关系一样 ● K8s是一个开放的开发平台，不局限于任何语言
Pod
Pod、容器与Node关系
Endpoint、Event
• Endpoint（IP+Port） 标识服务进程的访问点 • Event 是一个事件记录，记录了事件最早产生的时间、最后重复时间、重复次数、发起 者、类型，以及导致此事件的原因等信息。Event通常关联到具体资源对象上，式排查 故障的重要参考信息；
为什么使用Kubernetes?
● ● ● ● ●
K8s不仅仅支持Docker，还支持Rocket，这是另一种容器技术。 全面拥抱微服务架构 使用k8s我们系统可以随时的整体迁移 k8s系统具备了超强的横向扩容能力 k8s提供完善的管理工具，涵盖了包括开发、部署测试、运维监 控在内的各个环节
K8s集群
Node
பைடு நூலகம்
Pod
• Pod是最小部署单元，一个Pod由一个或多个容器组成，Pod中容器共享存储和 网络，在同一台Docker主机上运行。 • 同一个Pod里的容器共享同一个网络命名空间，可以使用localhost互相通信
1. 每个Pod都有一个特殊的被称为“根容器”的Pause容器，还包含一个或多个紧密相关的用户业务容 器； 2. 一个Pod里的容器与另外主机上的Pod容器能够直接通信； 3. 如果Pod所在的Node宕机，会将这个Node上的所有Pod重新调度到其他节点上； 4. 普通Pod及静态Pod，前者存放在etcd中，后者存放在具体Node上的一个具体文件中，并且只能在 此Node上启动运行； 5.Docker Volume对应Kubernetes中的Pod Volume； 6. 每个Pod可以设置限额的计算机资源有CPU和Memory； Requests，资源的最小申请量； Limits，资源最大允许使用的量；
Service
• Node IP Node节点的IP地址，是Kubernetes集群中每个节点的物理网卡的IP地址，是真 是存在的物理网络，所有属于这个网络的服务器之间都能通过这个网络直接通信； • Pod IP Pod的IP地址，是Docker Engine根据docker0网桥的IP地址段进行分配的，通常 是一个虚拟的二层网络，位于不同Node上的Pod能够彼此通信，需要通过Pod IP所在 的虚拟二层网络进行通信，而真实的TCP流量则是通过Node IP所在的物理网卡流出的 ； • Cluster IP Service的IP地址。特性如下： 仅仅作用于Kubernetes Servcie这个对象，并由Kubernetes管理和分配IP地址； 无法被Ping，因为没有一个“实体网络对象”来响应；只能结合Service Port组成一个具 体的通信端口； Node IP网、Pod IP网域Cluster IP网之间的通信，采用的是Kubernetes自己设计 的一种编程方式的特殊的路由规则，与IP路由有很大的不同；
1.kubelet，负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现 集群管理的基本功能。一旦Node被纳入集群管理范围，kubelet进程就会向Master汇报 自身的情报，这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调 度策略。而某个Node超过指定时间不上报信息，会被Master判定为“失联”，Node状态 被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程； 2.kube-proxy，实现Kubernetes Service的通信与负载均衡机制的重要组件； 3.Docker Engine（docker），Docker引擎，负责本机的容器创建和管理工作；
Service
• Service一个应用服务抽象，定义了Pod逻辑集合和访问这个Pod集合的策略。 • Service代理Pod集合对外表现是为一个访问入口，分配一个集群IP地址，来自这个 IP的请求将负载均衡转发后端Pod中的容器。 • Service通过LableSelector选择一组Pod提供服务。 • 在K8s集群中微服务的负载均衡是由Kube-proxy实现的，在K8s的每个节点上都有 一个 Service其实就是我们经常提起的微服务架构中的一个“微服务”，kubernetes中的核心 。通过分析、识别并建模系统中的所有服务为微服务——Kubernetes Service，最终 我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通 过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网络，拥有了强大的分布 式能力、弹性扩展能力、容错能力
1.
etcd
• • 简单: 支持curl方式的用户API（HTTP+JSON） 安全: 可选的SSL客户端证书认证
•
•
快速: 单实例每秒 1000 次读写能力
可靠: 使用Raft保证强一致性
Etcd的应用场景包括服务发现（Service Discovery）、消息发布与订阅、负载均衡、分布 式通知与协调、分布式锁、分布式队列。如果你熟悉ZooKeeper, 你会发现etcd实现了 ZooKeeper的功能
Replication Controller（RC）
部署和升级Pod，声明某种Pod的副本数量在任意时刻都符 合某个预期值； • Pod期待的副本数； • 用于筛选目标Pod的Label Selector； • 当Pod副本数量小于预期数量的时候，用于创建新Pod的 Pod模板（template）；
Label
Label可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label。 给某个资源定义一个Label，相当于给他打一个标签，随后可以通过Label Selector（ 标签选择器）查询和筛选拥有某些Label的资源对象。我们可以通过给指定的资源对象 捆绑一个或多个Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资 源分配、调度、配置、部署等管理工作； Label Selector示例：select * from pod where pod’s name=’XXX’,env=’YYY’，支持操 作符有=、!=、in、not in；
Service
Service
Service
如上图示，每个Pod都提供了一个独立的Endpoint（Pod IP+ContainerPort）以被客户端访问，多个Pod副本组成了一个集群来 提供服务，一般的做法是部署一个负载均衡器来访问它们，为这组Pod 开启一个对外的服务端口如8000，并且将这些Pod的Endpoint列表加入 8000端口的转发列表中，客户端可以通过负载均衡器的对外IP地址+服 务端口来访问此服务。运行在Node上的kube-proxy其实就是一个智能 的软件负载均衡器，它负责把对Service的请求转发到后端的某个Pod 实例上，并且在内部实现服务的负载均衡与会话保持机制。Service不 是共用一个负载均衡器的IP地址，而是每个Servcie分配一个全局唯一 的虚拟IP地址，这个虚拟IP被称为Cluster IP。
Replica Set
下一代的Replication Controlle，RC与RS唯一区别就是 lableselector支持不同，RS支持新的基于集合的标签，RC仅支持 基于等式的标签。Replication Controlle只支持基于等式的selector （env=dev或environment!=qa）但Replica Set还支持新的、基于 集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）， 这对复杂的运维管理带来很大方便。
Deployment
拥有更加灵活强大的升级、回滚功能。在新的版本中，官方推荐使用Replica Set 和Deployment来代替RC，两者相似度>90%，相对于RC一个最大升级是我们随时指 导当前Pod“部署”的进度。Deployment使用了Replica Set，除非需要自定义升级功能 或根本不需要升级Pod，一般情况下，我们推荐使用Deployment而不直接使用 Replica Set； 典型使用场景： • 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程； • 检查更新Deployment的状态来查看部署动作是否完成（Pod副本的数量是否达到预 期的值）； • 更新Deployment以创建新的Pod；（比如镜像升级） • 如果当前Deployment不稳定，则回滚到一个早先的Deployment版本； • 挂起或者恢复一个Deployment；
Master
Master
etcd
● ●
etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。 对比与ZooKeeper，etcd更轻量级
etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，提供了与 ZooKeeper相似的功能，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强 一致性。Raft是一个新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式 来实现一致性。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和 CoreOS的Fleet都广泛使用了etcd。在分布式系统中，如何管理节点间的状态一直是一个难 题，etcd像是专门为集群环境的服务发现和注册而设计，它提供了数据TTL失效、数据改变 监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态
Node
●
●
除了Master，Kubernetes集群中的其他机器被称为Node节点， 早 期版本也称为Minion节点 Node节点才是Kubernetes集群中的工作负载节点，每个Node都会 被Master分配一些工作负载（Docker容器），当某个Node宕机， 其上的工作负载会被Master自动转移到其他节点上去
K8s架构
K8s体系结构
Master
● ●
集群控制管理节点，所有的命令都经由master处理 负责整个集群的管理和控制，基本上Kubernetes所有的控制命令都 是发给它，它来负责具体的执行过程，我们后面所有执行的命令基 本都是在Master节点上运行的
1.Kubernetes API Server（kube-apiserver），提供Http Rest接口的关键服务进程，是 Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程 2.Kubernetes Controller Manager（kube-controller-manager），Kubernetes里所有资源 对象的自动化控制中心，可以理解为资源对象的“大总管” 3.Kubernetes Scheduler（kube-scheduler），负责资源调度（Pod调度）的进程，相当 于公交公司的“调度室” 4.etcd Server，Kubernetes里所有的资源对象的数据全部是保存在etcd中,(集群部署，不 与master放同一台机器)
Kubernetes主要功能
● ● ●
● ● ● ●
k8s能方便地管理跨机器运行容器化的应用 提供应用部署、维护、扩展机制 集群管理、安全防护、准入机制、多应用支撑、服务注册、服务 发现、智能负载均衡、故障发现、自我修复、服务滚动升级、在 线扩容、资源配额管理 使用Docker对应用程序包装、实例化、运行 以集群的方式运行、管理跨机器的容器 解决Docker跨机器容器之间的通讯问题 k8s的自我修复机制使得容器集群总是运行在用户期望的状态
Kubernetes技术分享
架构简介 集群搭建 常用命令 应用实例
Kubernetes简介
Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个 开源版本，是一个全新的基于容器技术的分布式架构领先方案。 ● Borg是谷歌内部使用的大规模集群管理系统，基于容器技术，目 的是实现资源管理的自动化，以及跨多个数据中心的资源利用率 的最大化； ● K8s是第一个将”一切以服务为中心，一切围绕服务运转”作为指 导思想的创新型产品 ● K8s是Go语言开发，是Docker的上层架构，就好像Java与J2EE的 关系一样 ● K8s是一个开放的开发平台，不局限于任何语言
Pod
Pod、容器与Node关系
Endpoint、Event
• Endpoint（IP+Port） 标识服务进程的访问点 • Event 是一个事件记录，记录了事件最早产生的时间、最后重复时间、重复次数、发起 者、类型，以及导致此事件的原因等信息。Event通常关联到具体资源对象上，式排查 故障的重要参考信息；
为什么使用Kubernetes?
● ● ● ● ●
K8s不仅仅支持Docker，还支持Rocket，这是另一种容器技术。 全面拥抱微服务架构 使用k8s我们系统可以随时的整体迁移 k8s系统具备了超强的横向扩容能力 k8s提供完善的管理工具，涵盖了包括开发、部署测试、运维监 控在内的各个环节
K8s集群
Node
பைடு நூலகம்
Pod
• Pod是最小部署单元，一个Pod由一个或多个容器组成，Pod中容器共享存储和 网络，在同一台Docker主机上运行。 • 同一个Pod里的容器共享同一个网络命名空间，可以使用localhost互相通信
1. 每个Pod都有一个特殊的被称为“根容器”的Pause容器，还包含一个或多个紧密相关的用户业务容 器； 2. 一个Pod里的容器与另外主机上的Pod容器能够直接通信； 3. 如果Pod所在的Node宕机，会将这个Node上的所有Pod重新调度到其他节点上； 4. 普通Pod及静态Pod，前者存放在etcd中，后者存放在具体Node上的一个具体文件中，并且只能在 此Node上启动运行； 5.Docker Volume对应Kubernetes中的Pod Volume； 6. 每个Pod可以设置限额的计算机资源有CPU和Memory； Requests，资源的最小申请量； Limits，资源最大允许使用的量；
Service
• Node IP Node节点的IP地址，是Kubernetes集群中每个节点的物理网卡的IP地址，是真 是存在的物理网络，所有属于这个网络的服务器之间都能通过这个网络直接通信； • Pod IP Pod的IP地址，是Docker Engine根据docker0网桥的IP地址段进行分配的，通常 是一个虚拟的二层网络，位于不同Node上的Pod能够彼此通信，需要通过Pod IP所在 的虚拟二层网络进行通信，而真实的TCP流量则是通过Node IP所在的物理网卡流出的 ； • Cluster IP Service的IP地址。特性如下： 仅仅作用于Kubernetes Servcie这个对象，并由Kubernetes管理和分配IP地址； 无法被Ping，因为没有一个“实体网络对象”来响应；只能结合Service Port组成一个具 体的通信端口； Node IP网、Pod IP网域Cluster IP网之间的通信，采用的是Kubernetes自己设计 的一种编程方式的特殊的路由规则，与IP路由有很大的不同；
1.kubelet，负责Pod对应的容器的创建、启停等任务，同时与Master节点密切协作，实现 集群管理的基本功能。一旦Node被纳入集群管理范围，kubelet进程就会向Master汇报 自身的情报，这样Master可以获知每个Node的资源使用情况，并实现高效均衡的资源调 度策略。而某个Node超过指定时间不上报信息，会被Master判定为“失联”，Node状态 被标记为不可用（Not Ready），随后Master会触发“工作负载大转移”的自动流程； 2.kube-proxy，实现Kubernetes Service的通信与负载均衡机制的重要组件； 3.Docker Engine（docker），Docker引擎，负责本机的容器创建和管理工作；
Service
• Service一个应用服务抽象，定义了Pod逻辑集合和访问这个Pod集合的策略。 • Service代理Pod集合对外表现是为一个访问入口，分配一个集群IP地址，来自这个 IP的请求将负载均衡转发后端Pod中的容器。 • Service通过LableSelector选择一组Pod提供服务。 • 在K8s集群中微服务的负载均衡是由Kube-proxy实现的，在K8s的每个节点上都有 一个 Service其实就是我们经常提起的微服务架构中的一个“微服务”，kubernetes中的核心 。通过分析、识别并建模系统中的所有服务为微服务——Kubernetes Service，最终 我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成，服务之间通 过TCP/IP进行通信，从而形成了我们强大而又灵活的弹性网络，拥有了强大的分布 式能力、弹性扩展能力、容错能力
1.
etcd
• • 简单: 支持curl方式的用户API（HTTP+JSON） 安全: 可选的SSL客户端证书认证
•
•
快速: 单实例每秒 1000 次读写能力
可靠: 使用Raft保证强一致性
Etcd的应用场景包括服务发现（Service Discovery）、消息发布与订阅、负载均衡、分布 式通知与协调、分布式锁、分布式队列。如果你熟悉ZooKeeper, 你会发现etcd实现了 ZooKeeper的功能
Replication Controller（RC）
部署和升级Pod，声明某种Pod的副本数量在任意时刻都符 合某个预期值； • Pod期待的副本数； • 用于筛选目标Pod的Label Selector； • 当Pod副本数量小于预期数量的时候，用于创建新Pod的 Pod模板（template）；
Label
Label可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label。 给某个资源定义一个Label，相当于给他打一个标签，随后可以通过Label Selector（ 标签选择器）查询和筛选拥有某些Label的资源对象。我们可以通过给指定的资源对象 捆绑一个或多个Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资 源分配、调度、配置、部署等管理工作； Label Selector示例：select * from pod where pod’s name=’XXX’,env=’YYY’，支持操 作符有=、!=、in、not in；
Service
Service
Service
如上图示，每个Pod都提供了一个独立的Endpoint（Pod IP+ContainerPort）以被客户端访问，多个Pod副本组成了一个集群来 提供服务，一般的做法是部署一个负载均衡器来访问它们，为这组Pod 开启一个对外的服务端口如8000，并且将这些Pod的Endpoint列表加入 8000端口的转发列表中，客户端可以通过负载均衡器的对外IP地址+服 务端口来访问此服务。运行在Node上的kube-proxy其实就是一个智能 的软件负载均衡器，它负责把对Service的请求转发到后端的某个Pod 实例上，并且在内部实现服务的负载均衡与会话保持机制。Service不 是共用一个负载均衡器的IP地址，而是每个Servcie分配一个全局唯一 的虚拟IP地址，这个虚拟IP被称为Cluster IP。
Replica Set
下一代的Replication Controlle，RC与RS唯一区别就是 lableselector支持不同，RS支持新的基于集合的标签，RC仅支持 基于等式的标签。Replication Controlle只支持基于等式的selector （env=dev或environment!=qa）但Replica Set还支持新的、基于 集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）， 这对复杂的运维管理带来很大方便。
Deployment
拥有更加灵活强大的升级、回滚功能。在新的版本中，官方推荐使用Replica Set 和Deployment来代替RC，两者相似度>90%，相对于RC一个最大升级是我们随时指 导当前Pod“部署”的进度。Deployment使用了Replica Set，除非需要自定义升级功能 或根本不需要升级Pod，一般情况下，我们推荐使用Deployment而不直接使用 Replica Set； 典型使用场景： • 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程； • 检查更新Deployment的状态来查看部署动作是否完成（Pod副本的数量是否达到预 期的值）； • 更新Deployment以创建新的Pod；（比如镜像升级） • 如果当前Deployment不稳定，则回滚到一个早先的Deployment版本； • 挂起或者恢复一个Deployment；
Master
Master
etcd
● ●
etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。 对比与ZooKeeper，etcd更轻量级
etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，提供了与 ZooKeeper相似的功能，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强 一致性。Raft是一个新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式 来实现一致性。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和 CoreOS的Fleet都广泛使用了etcd。在分布式系统中，如何管理节点间的状态一直是一个难 题，etcd像是专门为集群环境的服务发现和注册而设计，它提供了数据TTL失效、数据改变 监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态
Node
●
●
除了Master，Kubernetes集群中的其他机器被称为Node节点， 早 期版本也称为Minion节点 Node节点才是Kubernetes集群中的工作负载节点，每个Node都会 被Master分配一些工作负载（Docker容器），当某个Node宕机， 其上的工作负载会被Master自动转移到其他节点上去
K8s架构
K8s体系结构
Master
● ●
集群控制管理节点，所有的命令都经由master处理 负责整个集群的管理和控制，基本上Kubernetes所有的控制命令都 是发给它，它来负责具体的执行过程，我们后面所有执行的命令基 本都是在Master节点上运行的
1.Kubernetes API Server（kube-apiserver），提供Http Rest接口的关键服务进程，是 Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程 2.Kubernetes Controller Manager（kube-controller-manager），Kubernetes里所有资源 对象的自动化控制中心，可以理解为资源对象的“大总管” 3.Kubernetes Scheduler（kube-scheduler），负责资源调度（Pod调度）的进程，相当 于公交公司的“调度室” 4.etcd Server，Kubernetes里所有的资源对象的数据全部是保存在etcd中,(集群部署，不 与master放同一台机器)