学习如逆水行舟,不进则退。所以又来给各位读者送书了,这次送45本技术书,内容涉及深度学习、Python、Dubbo、Flutter等。
感谢本次活动的赞助商『电子工业出版社博文视点』
另外!急于购书的朋友也可以点击文末阅读原文直接购买。满减后的金额输入下方优惠码还能享受叠加优惠!
接下来小编给大家划重点!!!
全品类200减30优惠码,优惠码:BESKAJ (长按优惠码复制)
有效期截止8.4号, 数量有限,手慢无!
扫码关注公众号回复『福利』弹出小程序后点击参与。
注意:全部关注中奖几率翻8倍,仅需20s!
『马哥Linux运维』
《漫画算法:小灰的算法之旅》
魏梦舒 (@程序员小灰) 著
小灰的算法故事给算法这颗“炮弹”包上了“糖衣”,带你轻松入门算法与数据结构,开发岗面试不再慌。
用漫画的形式讲述了算法和数据结构的基础知识、复杂多变的算法面试题目及算法的实际应用场景。从基本数据结构,到各类排序算法,再到面试算法,再到职场应用,书中的主角小灰和大黄带领大家逐个破解。
《深度学习理论与实战:基础篇》
深述理论,跳出公式看深度学习
注重实战,跨越从知道到做到的鸿沟
本书不仅包含人工智能、机器学习及深度学习的基础知识,而且也囊括了学会使用 TensorFlow、PyTorch 和 Keras 这三个主流的深度学习框架的最小知识量;不仅有针对相关理论的深入解释,而且也有实用的技巧,包括常见的优化技巧、使用多 GPU 训练、调试程序及将模型上线到生产系统中。
兼顾理论和实战,使读者既能深入理解理论知识,又能把理论知识用于实战,因此本书每介绍完一个模型都会介绍其实现,读者阅读完一个模型的介绍之后就可以运行、阅读和修改相关代码,从而可以更加深刻地理解理论知识。
《编码:隐匿在计算机软硬件背后的语言》
用最简单的语言讲述最专业的知识
畅销20年,永不过时的计算机科学经典著作
Charles Petzold是Windows编程界的一位大师,当今世界项级技术作家。这本书是一本讲述计算机工作原理的书。不过,你千万不要因为“工作原理”之类的字眼就武断地认为,它是晦涩而难懂的。作者用丰富的想象和清晰的笔墨将看似繁杂的理论阐述得通俗易懂,你丝毫不会感到枯燥和生硬。更重要的是,你会因此而获得对计算机工作原理较深刻的理解。
《Python机器学习手册:从数据预处理到深度学习》
用近200个小任务的解决方案以及代码,教你解决机器学习日常开发中的细节问题
本书采用基于任务的方式来介绍如何在机器学习中使用Python。书中有近200个独立的解决方案,针对的都是数据科学家或机器学习工程师在构建模型时可能遇到的常见任务,涵盖从简 单的矩阵和向量运算到特征工程以及神经网络的构建。所有方案都提供了相关代码,读者可以 复制并粘贴这些代码,用在自己的程序中。
《混沌工程:Netflix系统稳定性之道》
Netflix官方出品,保障系统稳定性、确保架构弹性可伸缩的新方法!
在一个由很多微服务组成的分布式系统中,我们永远难以全面掌握发生什么事件会 导致系统局部不可用,甚至全面崩溃。但我们却可以尽可能地在这些不可用的情况发生 之前找出系统中的脆弱点。本书介绍了 Netflix 的工程师团队是如何根据多年实践经验 主动发现系统中脆弱点的一整套方法。这套方法现在已经逐渐演变成计算机科学的一门 新兴学科,即“混沌工程”。通过一系列可控的实验和执行实验的原则,混沌工程将揭 示出分布式系统中随时发生的各类事件是如何逐步导致系统整体不可用的。
《大型网站技术架构:核心原理与案例分析》
销量突破10W+的网站架构开山之作
网站生存技术心得,最接地气的网站架构经验
作者李智慧,曾在阿里巴巴担任技术专家,参与阿里巴巴基础技术平台开发和架构设计,本书通过梳理大型网站技术发展历程,剖析大型网站技术架构模式,深入讲述大型互联网架构设计的核心原理,并通过一组典型网站技术架构设计案例,为读者呈现一幅包括技术选型、架构设计、性能优化、Web安全、系统发布、运维监控等在内的大型网站开发全景视图。
详细解读Dubbo框架工作原理和底层机制
展示动手扩展Dubbo特性的实战场景
本书是由Apache Dubbo PMC参与编写的书籍,其内容的权威性具有指标性意义。与官方文档不同,官方文档侧重讲解使用方法,本书主要侧重于详细解读Dubbo框架工作原理和底层机制,并结合少量核心源码进行讲解。在原理的基础上,展示一些动手扩展Dubbo特性的实战场景,并对Dubbo的发展方向Dubbo Mesh做了一些探索。对于想系统掌握Dubbo的读者来说,本书会是一本颇具参考价值的案头图书。
《Flutter:从0到1构建大前端应用》
谷歌全平台框架,Flutter技术入门、进阶实战
本书是Flutter从基础入门到进阶实战的教程书,也是一本面向大前端的新技术书。本书共10章,内容包括Flutter简介、Dart语言入门、一切皆组件、事件处理、动画、使用网络技术与异步编程、路由、持久化、插件与混合工程和项目实战。本书不仅介绍了Flutter的基本原理、特性,而且在实战章节全面展示了打造一个完整的基于Flutter的App的流程,包含具体细节、思想流程和代码实操。
《狼书(卷1):更了不起的Node.js》
狼书力作,历经千日打磨隆重问世
通过新的Node.js和npm编写更具前端特色、更具工程化优势的代码
本书以Node.js为主,讲解了Node.js的基础知识、开发调试方法、源码原理和应用场景,旨在向读者展示如何通过新的Node.js和npm编写出更具前端特色、更具工程化优势的代码。本书还讲解了Node.js中相当核心且复杂的异步流程控制,展望了未来异步流程的发展方向,非常适合大前端领域及后端领域的测试、运维及软件开发从业者阅读、学习。
英特尔亚太研发有限公司 编著
多方位深层次,Linux开源网络技术大图谱
内容主要围绕各个项目的起源与发展、实现原理与框架、要解决的网络问题等方面展开讨论,致力于帮助读者对Linux开源网络技术的实现与发展形成完整、清晰的认识。本书语言通俗易懂,能够带领读者快速走入Linux开源网络的世界并做出自己的贡献。
全书分为3篇。第壹篇详细讲解Kubernetes系统基础架构及核心概述,并提供一个Kubernetes快速部署和应用的入门指南。第二篇剖析分Kubernetes系统的核心组件,对Pod、Controller、Service、Network Policy、Volume、ConfigMap和Secret等都有着深入讲解。第三篇主要关注实际应用,以DevOps为主线讲解Kubernetes在企业落地应用的解决方案示例。
感谢号主『马哥Linux运维』赞助!
etcd 是 CoreOS 团队发起的开源项目,是一个管理配置信息和服务发现(service discovery)的项目,它的目标是构建一个高可用的分布式键值(key-value)数据库,基于 Go 语言实现。
etcd基于其优秀的特点,可广泛的应用于以下场景:
服务发现主要解决在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听udp或tcp端口,并且通过名字就可以查找和连接。
在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。
在分布式系统中,为了保证服务的高可用以及数据的一致性,通常都会把数据和服务部署多份,以此达到对等服务,即使其中的某一个服务失效了,也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后,每个etcd的核心节点都可以处理用户的请求。所以,把数据量小但是访问频繁的消息数据直接存储到etcd中也可以实现负载均衡的效果。
分布式通知与协调:与消息发布和订阅类似,都用到了etcd中的Watcher机制,通过注册与异步通知机制,实现分布式环境下不同系统之间的通知与协调,从而对数据变更做到实时处理。
因为etcd使用Raft算法保持了数据的强一致性,某次操作存储到集群中的值必然是全局一致的,所以很容易实现分布式锁。锁服务有两种使用方式,一是保持独占,二是控制时序。
通过etcd来进行监控实现起来非常简单并且实时性强。
Heartbeat是Linux-HA项目中的一个组件,它提供了心跳检测和资源接管、集群中服务的监测、失效切换等功能。heartbeat最核心的功能包括两个部分,心跳监测和资源接管。心跳监测可以通过网络链路和串口进行,而且支持冗余链路,它们之间相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的报文,那么就认为对方失效,这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。
Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案,可以解决静态路由出现的单点故障问题。
在一个LVS服务集群中通常有主服务器(MASTER)和备份服务器(BACKUP)两种角色的服务器,但是对外表现为一个虚拟IP,主服务器会发送VRRP通告信息给备份服务器,当备份服务器收不到VRRP消息的时候,即主服务器异常的时候,备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。
1、core模块为keepalived的核心,负责主进程的启动、维护及全局配置文件的加载和解析
2、vrrp模块是来实现VRRP协议的
3、check负责健康检查,常见的方式有端口检查及URL检查
Keepalived工作在TCP/IP模型的第三、四和五层,即网络层、传输层和应用层。
Keepalived采用ICMP协议向服务器集群中的每个节点发送一个ICMP的数据包,如果某个节点没有返回响应数据包,则认为此节点发生了故障,Keepalived将报告次节点失效,并从服务器集群中剔除故障节点。
Keepalived利用TCP的端口连接和扫描技术来判断集群节点是否正常。如常见的web服务默认端口80,ssh默认端口22等。Keepalived一旦在传输层探测到相应端口没用响应数据返回,则认为此端口发生异常,从而将此端口对应的节点从服务器集群中剔除。
可以运行FTP、telnet、smtp、dns等各种不同类型的高层协议,Keepalived的运行方式也更加全面化和复杂化,用户可以通过自定义Keepalived的工作方式,来设定监测各种程序或服务是否正常,若监测结果与设定的正常结果不一致,将此服务对应的节点从服务器集群中剔除。
Keepalived通过完整的健康检查机制,保证集群中的所有节点均有效从而实现高可用。
LVS是linux virtual server的简写linux虚拟服务器,是一个虚拟的服务器集群系统,可以在unix/linux平台下实现负载均衡集群功能。
LVS的主要作用是通过LVS提供的负载均衡技术实现一个高性能、高可用的服务器群集。因此LVS主要可以实现:
LVS 有三种负载均衡的模式,分别是VS/NAT(nat 模式)、VS/DR(路由模式)、VS/TUN(隧道模式)。
LVS调度器用的调度方法基本分为两类:
代理服务器是一个位于客户端和原始(资源)服务器之间的服务器,为了从原始服务器取得内容,客户端向代理服务器发送一个请求并指定目标原始服务器,然后代理服务器向原始服务器转交请求并将获得的内容返回给客户端。
RTO指服务恢复的时间,最佳的情况是 0,即服务立即恢复;最坏是无穷大,即服务永远无法恢复;
RPO 指指当灾难发生时允许丢失的数据量,0 意味着使用同步的数据,大于 0 意味着有数据丢失,如“RPO=1 d”指恢复时使用一天前的数据,那么一天之内的数据就丢失了。因此,恢复的最佳情况是 RTO = RPO = 0,几乎无法实现。
CAP理论指出了在分布式系统中需要满足的三个条件,主要包括:
CAP 理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。
HAProxy是可提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,是免费、快速并且可靠的一种解决方案。HAProxy非常适用于并发大(并发达1w以上)web站点,这些站点通常又需要会话保持或七层处理。HAProxy的运行模式使得它可以很简单安全的整合至当前的架构中,同时可以保护web服务器不被暴露到网络上。
HAProxy负载均衡策略非常多,常见的有如下8种:
主要通过分析IP层及TCP/UDP层的流量实现基于IP加端口的负载均衡,如常见的LVS、F5等
位于OSI的最高层,即应用层,此负载均衡器支持多种协议,如HTTP、FTP、SMTP等。7层负载均衡器可根据报文内容,配合一定的负载均衡算法来选择后端服务器,即“内容交换器”。如常见的HAProxy、Nginx
相同:三者都是软件负载均衡产品。
1、LVS基于Linux操作系统实现软负载均衡,而HAProxy和Nginx是基于第三方应用实现的软负载均衡;
2、LVS是可实现4层的IP负载均衡技术,无法实现基于目录、URL的转发。而HAProxy和Nginx都可以实现4层和7层技术, HAProxy可提供TCP和HTTP应用的负载均衡综合解决方案;
3、LVS因为工作在ISO模型的第四层,其状态监测功能单一,而HAProxy在状监测方面功能更丰富、强大,可支持端口、URL、脚本等多种状态检测方式;
4、HAProxy功能强大,但整体性能低于4层模式的LVS负载均衡。Nginx主要用于Web服务器或缓存服务器。
Kubernetes是一个全新的基于容器技术的分布式系统支撑平台。是Google开源的容器集群管理系统(谷歌内部:Borg)。在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力,多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。
Docker 提供容器的生命周期管理和,Docker 镜像构建运行时容器。它的主要优点是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中,从而实现了可移植性等优点。
Kubernetes 用于关联和编排在多个主机上运行的容器。
在集群管理方面,Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中,在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler,这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力,并且都是全自动完成的。
Kubernetes当前存在的缺点(不足)如下:
k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。拥有Etcd存储服务(可选),运行Api Server进程,Controller Manager服务进程及Scheduler服务进程。
运行于Node节点上,若干相关容器的组合。Pod内包含的容器运行在同一宿主机上,使用相同的网络命名空间、IP地址和端口,能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位,它提供了比容器更高层次的抽象,使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。
Kubernetes中的Label实质是一系列的Key/Value键值对,其中key与value可自定义。Label可以附加到各种资源对象上,如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector(标签选择器)查询和筛选资源对象。
Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量,则会停止指定数量之外的多余容器数量。反之,则会启动少于指定数量个数的容器,保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。
Deployment在内部使用了RS来实现目的,Deployment相当于RC的一次升级,其最大的特色为可以随时获知当前Pod的部署进度。
Pod的横向自动扩容,也是Kubernetes的一种资源,通过追踪分析RC控制的所有Pod目标的负载变化情况,来确定是否需要针对性的调整Pod副本数量。
Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制,关联多个相同Label的Pod,用户不需要了解后台Pod是如何运行。
Volume是Pod中能够被多个容器访问的共享目录,Kubernetes中的Volume是定义在Pod上,可以被一个或多个Pod中的容器挂载到某个目录下。
Namespace用于实现多租户的资源隔离,可将集群内部的资源对象分配到不同的Namespace中,形成逻辑上的不同项目、小组或用户组,便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。
Kubernetes Master控制组件,调度管理整个系统(集群),包含如下组件:
作为Kubernetes系统的入口,其封装了核心对象的增删改查操作,以RESTful API接口方式提供给外部客户和内部组件调用,集群内各个功能模块之间数据交互和通信的中心枢纽。
为新建立的Pod进行节点(node)选择(即分配机器),负责集群的资源调度。
负责执行各种控制器,目前已经提供了很多控制器来保证Kubernetes的正常运行。
管理维护Node,定期检查Node的健康状态,标识出(失效|未失效)的Node节点。
管理维护Service,提供负载以及服务代理。
管理维护Job,为Jod创建一次性任务Pod,保证完成Job指定完成的任务数目
实现Pod的自动伸缩,定时获取监控数据,进行策略匹配,当满足条件时执行Pod的伸缩动作。
Manager组件获悉,并同时巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好等于此RC的期望值,若存在过多的Pod副本在运行,系统会停止一些Pod,反之则自动创建一些Pod。
kube-proxy 运行在所有节点上,它监听 apiserver 中 service 和 endpoint 的变化情况,创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器,其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张,因此被kube-proxy采纳为最新模式。
在IPVS模式下,使用iptables的扩展ipset,而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构,ipset则引入了带索引的数据结构,因此当规则很多时,也可以很高效地查找和匹配。
可以将ipset简单理解为一个IP(段)的集合,这个集合的内容可以是IP地址、IP网段、端口等,iptables可以直接添加规则对这个“可变的集合”进行操作,这样做的好处在于可以大大减少iptables规则的数量,从而减少性能损耗。
iptables与IPVS都是基于Netfilter实现的,但因为定位不同,二者有着本质的差别:iptables是为防火墙而设计的;IPVS则专门用于高性能负载均衡,并使用更高效的数据结构(Hash表),允许几乎无限的规模扩张。
与iptables相比,IPVS拥有以下明显优势:
Kubernetes中创建一个Pod涉及多个组件之间联动,主要流程如下:
Pod重启策略(RestartPolicy)应用于Pod内的所有容器,并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时,kubelet将根据RestartPolicy的设置来进行相应操作。
不同控制器的重启策略限制如下:
kubelet定期执行LivenessProbe探针来诊断容器的健康状态,通常有以下三种方式:
Kubernetes中,Pod通常是容器的载体,主要有如下常见调度方式:
该调度策略主要功能就是自动部署一个容器应用的多份副本,以及持续监控副本的数量,在集群内始终维持用户指定的副本数量。
定向调度,当需要手动指定将Pod调度到特定Node上,可以通过Node的标签(Label)和Pod的nodeSelector属性相匹配。
亲和性调度机制极大的扩展了Pod的调度能力,目前有两种节点亲和力表达:
硬规则,必须满足指定的规则,调度器才可以调度Pod至Node上(类似nodeSelector,语法不同)。
软规则,优先调度至满足的Node的节点,但不强求,多个优先级规则还可以设置权重值。
init container的运行方式与应用容器不同,它们必须先于应用容器执行完成,当设置了多个init container时,将按顺序逐个运行,并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后,Kubernetes才会初始化Pod的各种信息,并开始创建和运行应用容器。
DaemonSet资源对象会在每个Kubernetes集群中的节点上运行,并且每个节点只能运行一个pod,这是它和deployment资源对象的最大也是唯一的区别。因此,在定义yaml文件中,不支持定义replicas。
它的一般使用场景如下:
Kubernetes使用Horizontal Pod Autoscaler(HPA)的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标,并与HPA资源对象中的扩缩容条件进行对比,在满足条件时对Pod副本数量进行调整。
当目标Pod副本数量与当前副本数量不同时,HPA控制器就向Pod的副本控制器(Deployment、RC或ReplicaSet)发起scale操作,调整Pod的副本数量,完成扩缩容操作。
通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求负载分发到后端的各个容器应用上。
在某些应用场景中,若需要人为指定负载均衡器,不使用Service提供的默认负载均衡的功能,或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功能,即不为Service设置ClusterIP(入口IP地址),仅通过Label Selector将后端的Pod列表返回给调用的客户端。
对于Kubernetes,集群外的客户端默认情况,无法通过Pod的IP地址或者Service的虚拟IP地址:虚拟端口号进行访问。
通常可以通过以下方式进行访问Kubernetes集群内的服务:
Kubernetes的Ingress资源对象,用于将不同URL的访问请求转发到后端不同的Service,以实现HTTP层的业务路由机制。
同时当Ingress Controller提供的是对外服务,则实际上实现的是边缘路由器的功能。
负载均衡器是暴露服务的最常见和标准方式之一。
根据工作环境使用两种类型的负载均衡器,即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器,而外部负载均衡器将流量从外部负载引导至后端容器。
Kubernetes API Server作为集群的核心,负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd,当需要获取和操作这些数据时,则通过API Server提供的REST接口(用GET、LIST或WATCH方法)来实现,从而实现各模块之间的信息交互。
如kubelet进程与API Server的交互:每个Node上的kubelet每隔一个时间周期,就会调用一次API Server的REST接口报告自身状态,API Server在接收到这些信息后,会将节点状态信息更新到etcd中。
Kubernetes Scheduler是负责Pod调度的重要功能模块,Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能,“承上”是指它负责接收Controller Manager创建的新Pod,为其调度至目标Node;“启下”是指调度完成后,目标Node上的kubelet服务进程接管后继工作,负责Pod接下来生命周期。
在整个调度过程中涉及三个对象,分别是待调度Pod列表、可用Node列表,以及调度算法和策略。
输入是所有节点,输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node的label必须与Pod的Selector一致”
输入是预选阶段筛选出的节点,优选会根据优先策略为通过预选的Nodes进行打分排名,选择得分最高的Node。例如,资源越富裕、负载越小的Node可能具有越高的排名
在Kubernetes集群中,在每个Node(又称Worker)上都会启动一个kubelet服务进程。该进程用于处理Master下发到本节点的任务,管理Pod及Pod中的容器。每个kubelet进程都会在API Server上注册节点自身的信息,定期向Master汇报节点资源的使用情况,并通过cAdvisor监控容器和节点资源。
Kubernetes通过一系列机制来实现集群的安全控制,主要有如下不同的维度:
在对集群进行请求时,每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求,那么整个请求的结果将会立即返回,并提示用户相应的error信息。
准入控制(AdmissionControl)准入控制本质上为一段准入代码,在对kubernetes api的请求过程中,顺序为:先经过认证 & 授权,然后执行准入操作,最后对目标对象进行操作。常用组件(控制代码)如下:
RBAC是基于角色的访问控制,是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。
相对于其他授权模式,RBAC具有如下优势:
Secret对象,主要作用是保管私密数据,比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全,也更便于使用和分发。
创建完secret之后,可通过如下三种方式使用:
在PodSecurityPolicy对象中可以设置不同字段来控制Pod运行时的各种安全策略,常见的有:
Kubernetes网络模型中每个Pod都拥有一个独立的IP地址,并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node(宿主机)中,都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是,用户不需要额外考虑如何建立Pod之间的连接,也不需要考虑如何将容器端口映射到主机端口等问题
同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间,也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口
在Kubernetes的集群里,IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈(相当于一个网络命名空间,它们的IP地址、网络设备、配置等都是共享的)
CNI提供了一种应用容器的插件化网络解决方案,定义对容器网络进行操作和配置的规范,通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源,和在销毁容器时删除网络资源。在CNI模型中只涉及两个概念:容器和网络。
Network Policy的主要功能是对Pod间的网络通信进行限制和准入控制,设置允许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略,配合策略控制器(Policy Controller)进行策略的实现。
Flannel可以用于Kubernetes底层网络的实现,主要作用有:
Calico在每个计算节点都利用Linux Kernel实现了一个高效的vRouter来负责数据转发。每个vRouter都通过BGP协议把在本节点上运行的容器的路由信息向整个Calico网络广播,并自动设置到达其他节点的路由转发规则。
Calico保证所有容器之间的数据流量都是通过IP路由的方式完成互联互通的。Calico节点组网时可以直接利用数据中心的网络结构(L2或者L3),不需要额外的NAT、隧道或者Overlay Network,没有额外的封包解包,能够节约CPU运算,提高网络效率。
Kubernetes对于有状态的容器应用或者对数据需要持久化的应用,因此需要更加可靠的存储来保存应用产生的重要数据,以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储。
Kubernetes通过数据持久化来持久化保存重要数据,常见的方式有:
PersistentVolume(简称PV):如基于NFS服务的PV,也可以基于GFS的PV。它的作用是统一数据持久化目录,方便管理。
某个PV在生命周期中可能处于以下4个阶段(Phaes)之一。
Kubernetes支持两种资源的存储供应模式:静态模式(Static)和动态模式(Dynamic)。
CSI是Kubernetes推出与容器对接的存储接口标准,存储提供方只需要基于标准接口进行存储插件的实现,就能使用Kubernetes的原生存储机制为容器提供存储服务。CSI使得存储提供方的代码能和Kubernetes代码彻底解耦,部署也与Kubernetes核心组件分离,显然,存储插件的开发由提供方自行维护,就能为Kubernetes用户提供更多的存储功能,也更加安全可靠。
通常需要对Worker节点进行扩容,从而将应用系统进行水平扩展。主要过程如下:
Kubernetes集群里的节点提供的资源主要是计算资源,计算资源是可计量的能被申请、分配和使用的基础资源。当前Kubernetes集群中的计算资源主要包括CPU、GPU及Memory。CPU与Memory是被Pod使用的,因此在配置Pod时可以通过参数CPU Request及Memory
通常,一个程序所使用的CPU与Memory是一个动态的量,确切地说,是一个范围,跟它的负载密切相关:负载增加时,CPU和Memory的使用量也会增加。
当一个Pod创建成功时,Kubernetes调度器(Scheduler)会为该Pod选择一个节点来执行。对于每种计算资源(CPU和Memory)而言,每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时,首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和,不超过该节点能提供给Pod使用的CPU和Memory的最大容量值。
在Kubernetes集群环境中,通常一个完整的应用或服务涉及组件过多,建议对日志系统进行集中化管理,通常采用EFK实现。
由于Kubernetes节点运行大量Pod,因此在进行关机维护之前,建议先使用kubectl drain将该节点的Pod进行驱逐,然后进行关机维护
Kubernetes集群联邦可以将多个Kubernetes集群作为一个集群进行管理。因此,可以在一个数据中心/云中创建多个Kubernetes集群,并使用集群联邦在一个地方控制/管理所有集群
Helm能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
Helm中通常每个包称为一个Chart,一个Chart是一个目录(一般情况下会将目录进行打包压缩,形成name-version.tgz格式的单一文件,方便传输和存储)。
中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。通常位于客户机/服务器的操作系统中间,是连接两个独立应用程序或独立系统的软件。
通过中间件实现两个不同系统之间的信息交换。