Browsed by
标签:Kubernetes

Kubernetes(k8s)容器运行时(CRI)简介

Kubernetes(k8s)容器运行时(CRI)简介

閱讀本文約花費: 11 (分鐘)Kubernetes节点的底层由一个叫做“容器运行时”的软件进行支撑,它负责比如启停容器这样的事情。最广为人知的容器运行时当属Docker,但它不是唯一的。事实上,容器运行时这个领域发展迅速。为了使Kubernetes的扩展变得更容易,我们一直在打磨支持容器运行时的K8s插件API:容器运行时接口(Container Runtime Interface, CRI)。 CRI是什么? 每种容器运行时各有所长,许多用户都希望Kubernetes支持更多的运行时。在Kubernetes 1.5发布版里,我们引入了CRI–一个能让kubelet无需编译就可以支持多种容器运行时的插件接口。CRI包含了一组protocol buffers,gRPC API,相关的库,以及在活跃开发下的额外规范和工具。CRI目前是Alpha版本。 支持可替换的容器运行时在Kubernetes中概念中并非首次。在1.3发布版里,我们介绍了rktnetes项目,它可以让rkt容器引擎作为Docker容器运行时的一个备选。然而,不管是Docker还是Rkt都需要通过内部、不太稳定的接口直接集成到kubelet的源码中。这样的集成过程要求十分熟悉kubelet内部原理,并且还会在Kubernetes社区引发巨大的维护反响。这些因素都在为容器运行时的初期造成了巨大的困难。我们通过提供一个清…

Read More Read More

个推微服务网关架构实践

个推微服务网关架构实践

閱讀本文約花費: 9 (分鐘) 文章主要介绍了个推微服务体系的架构,以及个推微服务网关提供的主要功能等,希望能对您有所帮助。 在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。因此,在客户端和服务端之间增加一个API网关成为多数微服务架构的必然选择。 在个推的微服务实践中,API网关也起着至关重要的作用。一方面, API网关是个推微服务体系对外的唯一入口 ;另一方面, API网关中实现了很多后端服务的共性需求,避免了重复建设 。 个推微服务网关的设计与实现 个推微服务主要是基于Docker和Kubernetes进行实践的。 在整个微服务架构中,最底层的是个推私有部署的Kubernetes集群,在集群之上,部署了应用服务。 个推的应用服务体系共分为三层,最上一层是网关层,接着是业务层,最下面是基础层服务。 在部署应用服务时,我们使用了Kubernetes的命名空间对不同产品线的产品进行隔离。除了应用服务外, Kubernetes集群上还部署了Consul来实现配置的管理、Kube-DNS实现服务注册与发现,以及一些辅助系统来进行应用和集群的管理。 下图是个推微服务体系的架构图。 个推对API网关的功能需求主要有以下几方面: 1. 要支持配置多个产品,为不同的产品提供不同的端口; 2. 动态路由…

Read More Read More

微服务网关

微服务网关

閱讀本文約花費: 14 (分鐘) 本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 一、前言 随着微服务的兴起,基于其业务耦合性低、负载能力强、服务边界清晰等优点,大家纷纷使用微服务架构来实现新系统或进行老系统的改造。微服务在带来诸多好处的同时,也有一些问题需要解决,比如:如何做到有效拆分、减少服务间调用,如何统一管理所有服务的接口,如何进行自动化部署等。本文阐述微服务的API网关的一些主要功能,并例举了几种常用的网关,最后结合spring cloud微服务框架对网关做一些简要的论述。 二、API网关简介 API网关,顾名思义,是统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。下图为微服务架构的简单示意图,网关起到的作用一目了然。 三、API网关的作用 为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可承担认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。 所以实现或者选择一个好的API网关,是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署,要尽可能的减少接触面…

Read More Read More

云原生计算基金会宣布Harbor项目正式毕业

云原生计算基金会宣布Harbor项目正式毕业

閱讀本文約花費: 7 (分鐘)专门为云原生软件构建可持续生态系统的云原生计算基金会(简称CNCF)于本月23日(当地时间)正式宣布,Harbor已经成为第11个正式毕业的项目。从孵化阶段、发展成熟一路走向正式毕业,Harbor项目不仅获得更高的采用率、更加开放的治理流程与成熟的功能,同时也在社区发展、可持续性及项目包容性方面做出坚定的承诺。Harbor是一种开源代码注册表,可通过策略与基于角色的访问控制实现工件保护,扫描镜像内容使其免受漏洞侵害,最后对镜像进行可信签名。作为云原生计算基金会下辖的孵化项目,Harbor成为保障合规性、性能与互操作性的好帮手,可帮助用户跨Kubernetes与Docker等云原生计算平台,持续安全地管理各类工件。目前,Harbor已经被引入众多知名企业的生产体系当中,包括CaiCloud、中国移动、Hyland Software、京东、Mulesoft、三星SDS、Trend Micro以及VMware等等。就在上个月,Harbor 2.0版本全面推出。此版本增加了对开放容器计划(OCI)工件的支持,允许用户在其中存储大量云原生工件,例如容器镜像、Helm图表、OPA以及Singularity等。开发人员可以使用OCI索引中的OCI工件或打包工件,轻松享受Harbor项目带来的策略选项、复制功能以及基于角色的访问控制等成果。云原生计算基金会CTO/CO…

Read More Read More

微服务与网关技术(SIA-GateWay)

微服务与网关技术(SIA-GateWay)

閱讀本文約花費: 18 (分鐘) 编辑推荐:文章主要介绍了微服务架构特性,微服务网关的分类以及作用,SIA-GateWay等,希望能对您有所帮助。 一. 背景 软件架构,总是在不断的演进中… 把时间退回到二十年之前,当时企业级领域研发主要推崇的还是 C/S 模式,PB、Delphi 这样的开发软件是企业应用开发的主流。随着时间不断的推移,基于浏览器的的 B/S 架构开始渐渐流行了起来。初期,Web 开发 ASP 还占据了不少优势,但 JSP 的预编译模式让性能有了很大的提升,随后基于 JAVA 语言的 J2EE 架构变的越来越流行。 早期软件架构基本都是单体架构,系统之间往往不需要进行交互,这也导致数据孤岛和 ETL 工具的发展。随着企业应用越来多,相互的关系也越来密切。应用之间也迫切需要进行实时交互访问,随后基于 XML 的异构系统集成和数据交互技术开始被很多公司采用,SOA 的概念被提了出来,web service 逐渐流行起来。 互联网时代,很多公司为了适应更加灵活的业务需求,基于 HTTP 协议和 Restful 的架构风格及简洁和结构清晰的 JSON 语言成为企业开发的最佳实践,在 SOA 架构中,企业服务总线技术 ESB 所暴露的集中式架构的劣势让开发者明白基于注册和发现的分布式架构才是解决问题的关键办法。由此,微服务架构逐渐流行起来。 在《微服务设计》中如…

Read More Read More

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境(环境搭建篇)

閱讀本文約花費: 51 (分鐘)环境搭建概述 1.K8S是什么? K8S全称是Kubernetes,是一个全新的基于容器技术的分布式架构领先方案,基于容器技术,目的是实现资源管理的自动化,以及跨多个数据中心的资源利用率的最大化。 如果我们的系统设计遵循了kubernetes的设计思想,那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块,都可以使用K8S来管理,我们不必再费心于负载均衡的选型和部署实施问题,不必再考虑引入或自己开发一个复杂的服务治理框架,不必再头疼与服务监控和故障处理模块的开发。总之,使用kubernetes提供的解决方案,会大大减少开发成本,同时可以将精力更加集中于业务本身,而且由于kubernetes提供了强大的自动化机制,所以系统后期的运维难度和运维成本大幅降低。 2.为什么要用K8S? Docker 这个新兴的容器化技术当前已经被很多公司所采用,其从单机走向集群已成必然,而云计算的蓬勃发展正在加速这一进程。Kubernetes 作为当前唯一被业界广泛认可和看好的 Docker 分布式系统解决方案。可以预见,在未来几年内,会有大量的新系统选择它,不管是运行在企业本地服务器上还是被托管到公有云上。 3.使用K8S有哪些好处? 使用Kubernetes就是在全面部署微服务架构。微服务架构的核心就是将一个巨大的单体应用分解为很多小的互相连接的微服务,一个微服…

Read More Read More

微服务写的最全的一篇文章

微服务写的最全的一篇文章

閱讀本文約花費: 14 (分鐘) 本文来自于网络,本文主要讲解的是微服务,详细阐述了微服务的利弊、服务分层、微服务的服务发现的三种方式微服务的路由发现体系等相关知识。 今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。 1.什么是微服务 1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可) 2)独立的进程(java的tomcat,nodejs等) 3)轻量级的通信(不是soap,是http协议) 4)基于业务能力(类似用户服务,商品服务等等) 5)独立部署(迭代速度快) 6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择) ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。 2. 怎么权衡微服务的利于弊 利: 强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活) 可独立部署。 技术多样性。 弊: 分布式复杂性。 最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题) 运维复杂性。 测试复杂性。 3. 企业在什么时候考虑引入微服务 从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的…

Read More Read More

K8S基础概念

K8S基础概念

閱讀本文約花費: 9 (分鐘)一、核心概念 1、Node Node作为集群中的工作节点,运行真正的应用程序,在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kube-proxy服务进程,这些服务进程负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。 Node包含的信息: Node地址:主机的IP地址,或Node ID。 Node的运行状态:Pending、Running、Terminated三种状态。 Node Condition:… Node系统容量:描述Node可用的系统资源,包括CPU、内存、最大可调度Pod数量等。 其他:内核版本号、Kubernetes版本等。 查看Node信息: 2、Pod Pod是Kubernetes最基本的操作单元,包含一个或多个紧密相关的容器,一个Pod可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个Pod中的多个容器应用通常是紧密耦合的,Pod在Node上被创建、启动或者销毁;每个Pod里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。 同一个Pod里的容器之间仅需通过l…

Read More Read More

k8s常用命令实操

k8s常用命令实操

閱讀本文約花費: 12 (分鐘)查看集群信息: [[email protected] pods]# kubectl cluster-infoKubernetes master is running at http://localhost:8080KubeDNS is running at http://localhost:8080/api/v1/proxy/namespaces/kube-system/services/kube-dns To further debug and diagnose cluster problems, use ‘kubectl cluster-info dump’. 查看更详细的可以用kubectl cluster-info dump 查看各组件状态 [[email protected] pods]# kubectl -s http://localhost:8080 get componentstatusesNAME                              STATUS           &n…

Read More Read More

基于 Docker 和 Kubernetes 的微服务实践

基于 Docker 和 Kubernetes 的微服务实践

閱讀本文約花費: 12 (分鐘) 本文来自微信公众号,本文介绍基于Docker和Kubernetes的整个微服务实践过程,我们在实践微服务过程中做了9件重要的事情, 简化了操作流程,提高了工作效率。 一、微服务化 微服务架构 微服务 是将单一的应用程序拆分成多个微小的服务,各个小服务之间松耦合,高内聚,每个小的服务可以单独进行开发,不依赖于具体的编程语言,也可以使用不同的数据存储技术,各个服务可以独立部署,拥有各自的进程,相互之间通过轻量化的机制进行通信(如基于HTTP的API接口),所有的服务共同实现具体的业务功能。 客户端与服务端通信有2种方式,第一种是客户端直接与各个微服务进行通信,这样的架构有4个缺点: (1)多次服务请求,效率低; (2)对外暴露服务接口; (3)接口协议无法统一; (4)客户端代码复杂,服务端升级困难。 第二种方式是由API网关统一代理各个服务,对外提供统一的接口协议,该架构有3 个优势: (1)封装服务接口细节,减少通信次数; (2)统一通信协议,减少客户端代码耦合; (3)统一鉴权,流控,防攻击; 在该架构下,网关也有可能成为系统瓶颈。 相应地,这2种架构也带来了2种服务注册发现的方式,第一种是客户端通过向服务的注册中心查询微服务的地址与其通信,第二种是增加统一的API网关来查询。前者会增加客户端的复杂度,开发成本高,第二种操作会显得更加简洁,因此我…

Read More Read More