Browsed by
标签:Kubernetes

UCloud优刻得容器Cube入选2020年度十大云原生创新技术方案

UCloud优刻得容器Cube入选2020年度十大云原生创新技术方案

閱讀本文約花費: 4 (分鐘)近日,由极客邦科技、InfoQ主办的首个年度榜单“2020中国技术力量年度榜单评选”结果揭晓,UCloud优刻得 Serverless容器实例Cube成功入选“2020年度十大云原生创新技术方案”。 顶尖专家阵容 优质项目交锋 UCloud云原生实力获得认可 此次极客邦科技、InfoQ主办的“2020中国技术力量年度榜单评选”,历经数月打磨,共有300+参评项目,100+入围项目,10000+开发者公开票选,20+顶尖专家评审,10+主编团打分。“2020 年度十大云原生创新技术方案”作为评选出的四大榜单之一,聚焦IT圈最炙手可热的“云原生”领域及优质技术方案,从研发实力、技术创新性、落地案例、市场潜力几方面综合评估,最终筛选出UCloud优刻得、华为云、腾讯云等10家入选方案。 轻量级Cube 秒级启动、最短1天完成部署 伴随云计算2.0时代的到来,越来越多企业开始拥抱云原生,容器作为云原生最基础的技术,在短时间也实现了快速普及,据权威机构的调查数据显示,2019年已有43.9%的用户采用了容器技术,另外有40.8%的用户计划采用容器技术。 UCloud作为云计算领域的核心玩家,持续关注云原生发展和用户需要,进行了多项技术、产品研发。在Kubernetes作为容器编排的事实标准在企业服务中被大量采用后,UCloud也于2018年推出了基于Kubern…

Read More Read More

从基础设施到云原生应用,全方位解读阿里云原生新锐开源项目

从基础设施到云原生应用,全方位解读阿里云原生新锐开源项目

閱讀本文約花費: 11 (分鐘)简介: 2020年11月19日,由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开,阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”,阿里云原生拿了一个分量十足的“大满贯”。 2020年11月19日,由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开,并正式揭晓了“开源杰出贡献人物”、“开源新锐项目”和“云原生行业落地典范”三大重量级奖项。在此前的入围赛中,仅“开源新锐项目”单项,阿里云原生就入围了10多个开源项目,在创新能力、社区成就和用户反馈等多项指标中一骑绝尘,占据了参评项目整体近五分之一。而在本次揭晓的“2020中国技术力量年度榜单”决赛结果中,最终阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”,阿里云原生拿了一个分量十足的“大满贯”。 在 2020 年,阿里不仅实现了双十一核心系统全面云原生化,一举成为全球规模最大、实力最硬核的云原生实践,并首次实现自研、开源、商业“三位一体…

Read More Read More

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

閱讀本文約花費: 10 (分鐘)生产关系能否决定生产力?为什么这个社会需要管理?Kubernetes 是如此的成功,它的开源治理和技术架构是有着非常密切的关系的。 Tue Feb 6, 2018 | 3000 Words | 大约需要阅读 6 分钟 | | 康威定律(Conway’s Law) 随着信息技术的发展,以及现实的IT公司的成功,如Amazon、Netflix,以及云计算的普及,微服务的实践正在走向很多传统用户,然而,实施微服务的过程中,和DevOps的理念一样,人们发现并非仅仅是技术所能够解决的。还要涉及到组织架构。于是,伴随着微服务的发展,一位很少被人提及的科学家被推到了前端,也是被人忽视而尘封的科学家。 时间要拨回到1967年,Melvin Conway 以独特的视角观察到一个组织的组织结构会对其开发的系统有很大的影响。并撰写了“How Do Committees Invent” 这样一篇影响深远的论文,其中被人们广为知道的结论: 设计系统【这里也不仅仅是指信息系统】的组织,其产生的设计和架构等价于组织间的沟通结构。 该定律基于这样一个推理:为了能够让软件之间的模块相互作用,软件的撰写者们必须相互频繁的进行沟通,因此,系统的软件界面结构将会反映出打造此系统的组织的社会边界,要知道跨边界的沟通是比较困难的。Conway 定律的目的是试图说明这是蛮常见的社会学…

Read More Read More

Kubernetes 社区是如何运作的系列之一——哲学及治理

Kubernetes 社区是如何运作的系列之一——哲学及治理

閱讀本文約花費: 6 (分鐘)开源社区治理,正在逐渐的成熟,Linux、CNCF、OpenStack、Apache基金会等俨然成为软件业的中流砥柱,本土是不是应该潜心学习这些先进的管理/治理方式?精英制还是完全民主化?是不是应该以实际行动和理性思考来作出正确的判断? Mon Feb 5, 2018 | 1900 Words | 大约需要阅读 4 分钟 | | 引子 在2017年,关于容器的管理和调度平台,战火的硝烟渐渐的平息,Kubernetes 以压倒性的优势占据了这个细分领域的霸主,如下图来自 thenewstack 的调查: 如果仅仅从纯技术的角度而言,Kubernetes 和其它平台是半斤八两,处于伯仲之间,那么在社区的运营和赢得人们信任的方面,Kubernetes绝对是No.1,没有哪家能够相提并论。即使是Docker本身拥有无数拥泵的情况下,是容器的默认事实标准,也无法抵挡透明、开放、协作的Kubernetes社区的魅力。开源之道在Kubernetes 之所以成功的背后神秘力量 进行过专门的表述。 在上个月的中旬,Software Engineering Daily 的Jeff 撰写了一篇非常棒的文章:Kubernetes 的“下沉”,意指Kubernetes已经像Linux在单机操作系统的地位一样,成为分布式系统平台的默认选择。成为了分布式系统事实…

Read More Read More

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

閱讀本文約花費: 16 (分鐘)微服务国内发展背景: 2014年,Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内,2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地,2016-2017年,微服务的概念被越来越多的人认可,带动了一大批公司以微服务和容器为核心开始技术架构的全面革新。 至今微服务已经历了两代发展,第一代以Spring Cloud为代表的微服务开发框架,该框架在微服务发展的前几年一度独领风骚,甚至在部分人群中成为微服务的代名词,但事实上该微服务框架并不是唯一实现微服务的方式;第二代微服务技术为服务网格(Service Mesh),它的出现解决了大部分开发人员在使用Spring Cloud中遇到的不足和痛点。 Service Mesh是如何解决这些问题的,又是何以赢得众多开发者的支持呢?笔者就这些问题给大家分享一篇以Istio为代表的第二代微服务实践。 一、微服务和Istio Service Mesh基本概念 服务网格是一个基础设施层,主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传递。在实践中,服务网格通常实现为一组轻量级网络代理,它们与应用程序部署在一起,而对应用程序透明。 图1展示了服务网格的拓扑,当微服务数量增多达到几十上…

Read More Read More

如何在Kubernetes中管理有状态应用

如何在Kubernetes中管理有状态应用

閱讀本文約花費: 7 (分鐘)在Kubernetes中,StatefulSet被用来管理有状态应用的API对象。StatefulSets在Kubernetes 1.9版本才稳定。StatefulSet管理Pod部署和扩容,并为这些Pod提供顺序和唯一性的保证。与Deployment相似的地方是,StatefulSet基于spec规格管理Pod;与Deployment不同的地方是,StatefulSet需要维护每一个Pod的唯一身份标识。这些Pod基于同样的spec创建,但互相之间不能替换,每一个Pod都保留自己的持久化标识。 ———- 1、使用StatefulSet的场景 对于下面的应用场景,StatefulSets是有价值的: 稳定、唯一的网络标识 稳定、持久的存储 按照顺序、优雅的部署和扩容 按照顺序、优雅的删除和终止 按照顺序、自动滚动更新 上述的稳定是持久的同义词,如果应用不需要稳定的标识或者顺序的部署、删除、扩容,则应该使用无状态的副本集。Deployment或者ReplicaSet的控制器更加适合无状态业务场景。 2、StatefulSet的限制 在Kubernetes 1.9版本之前是beta版本,在Kubernetes 1.5版本之前是不提供的。 Pod存储由PersistentVolume(storage类或者管理员预先创建)提…

Read More Read More

Kubernetes集群搭建:基于Kubeadm

Kubernetes集群搭建:基于Kubeadm

閱讀本文約花費: 16 (分鐘)一,环境准备 * K8S版本为15.1 * Docker版本最高支持18.06.1 二,Docker环境构建及替换 1,清除原Docker环境,原版本为最新版 yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \docker-engine rm -rf /etc/systemd/system/docker.service.d rm -rf /var/lib/docker rm -rf /var/run/docker 2,如果清除后依旧包冲突错误 file /usr/share/man/man1/docker-manifest-annotate.1.gz from install of docker-ce-18.06.1.ce-3.el7.x86_64 conflicts with file from package docker-ce-cli-1:18.09.6-3.el7.x86_64 通过yum命令手动移除冲突包 yum erase docker-common-2:1…

Read More Read More

使用Istio治理微服务入门

使用Istio治理微服务入门

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄,服务治理难搞! 一、微服务的“痛点” 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。 微服务治理是头疼的事,也是微服务架构中的痛点。治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面: 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(…

Read More Read More

kubernetes实践:Istio之策略与遥测

kubernetes实践:Istio之策略与遥测

閱讀本文約花費: 9 (分鐘)一:Istio简介 1.Istio定义 一个用来连接,管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络,具备负载均衡,服务间认证和监控等功能。 而不需要改变任何服务代码。想要为服务增加对Istio的支持,只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。 2.为什么需要Istio 随着微服务出现,微服务的连接,管理和监控成为难题。Kubernetes可以处理多个容器的工作负载,但当涉及更复杂的需求时,需要像Istio这样的服务网格。 3.Istio的主要功能 a.流量管理(Pilot): 控制服务之间的流量和API调用的流向,使得调用更灵活可靠,并使网络在恶劣情况下更加健壮。 b.可观察性: 通过集成zipkin等服务,快速了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。 c.策略执行(mixer): 将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 d.服务身份和安全(Istio-auth): 为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。 4.Envoy架构 a.svcA服务作为客户端点用服务端svcB,svc…

Read More Read More

Serverless 与容器决战在即?有了弹性伸缩就不一样了

Serverless 与容器决战在即?有了弹性伸缩就不一样了

閱讀本文約花費: 16 (分鐘)导读:Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0,终有一天容器会和 Serverless 进行一场决战,分出胜负。实际上,容器和 Serverless 是可以共存并且互补的,特别是在 Autoscaling 相关的场景下,Serverless 可以与容器完美兼容,弥补容器场景在使用简单、速度、成本的缺欠。 当我们在谈论”弹性伸缩”的时候 当我们在谈论”弹性伸缩”的时候,我们在谈论什么?”弹性伸缩”对于团队中不同的角色有不同的意义,而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图,表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量,因为应用的资源申请量相比节点而言会小很多,因此曲线相对比较平滑; 而绿色的折线表示的是集群的实际资源容量,折线的拐点表明此时进行了手动的容量调整,例如增加节点或者移除节点,因为单个节点的资源容量固定且相对较大,因此以折线为主。 首先,我们先看左侧第一块黄色栅格的区域,这个区域表示集群的容量无法满足业务的容量所需,在实际的场景中,通常会伴随出现由于资源不足而无法调度的 Pod 等现…

Read More Read More

Service Mesh Is Still Hard

Service Mesh Is Still Hard

閱讀本文約花費: 5 (分鐘)KubeCon + CloudNativeCon NA Virtual sponsor guest post from Lin Sun, Senior Technical Staff Member at IBM At ServiceMeshCon EU this August, William Morgan from Linkerd and I gave a joint talk entitled service mesh is still hard.  William detailed the improvements to Linkerd, while I covered the improvements to Istio.  It’s clear both projects are working hard to make it easier for users to adopt service mesh. Service mesh is more mature than it was one or two years ago, however, it’s still hard for users.  There are two types of …

Read More Read More

深入解读Service Mesh背后的技术细节

深入解读Service Mesh背后的技术细节

閱讀本文約花費: 14 (分鐘)一、Service Mesh是Kubernetes支撑微服务能力拼图的最后一块 在上一篇文章为什么 kubernetes 天然适合微服务中我们提到,Kubernetes是一个奇葩所在,他的组件复杂,概念复杂,在没有实施微服务之前,你可能会觉得为什么Kubernetes要设计的这么复杂,但是一旦你要实施微服务,你会发现Kubernetes中的所有概念,都是有用的。 在我们微服务设计的是个要点中,我们会发现Kubernetes都能够有相应的组件和概念,提供相应的支持。 其中最后的一块拼图就是服务发现,与熔断限流降级。 众所周知,Kubernetes的服务发现是通过Service来实现的,服务之间的转发是通过kube-proxy下发iptables规则来实现的,这个只能实现最基本的服务发现和转发能力,不能满足高并发应用下的高级的服务特性,比较SpringCloud和Dubbo有一定的差距,于是Service Mesh诞生了,他期望讲熔断,限流,降级等特性,从应用层,下沉到基础设施层去实现,从而使得Kubernetes和容器全面接管微服务。 二、以Istio为例讲述Service Mesh中的技术关键点 就如SDN一样,Service Mesh将服务请求的转发分为控制面和数据面,因而分析他,也是从数据面先分析转发的能力,然后再分析控制面如何下发命令。今天这篇…

Read More Read More

云原生架构概述

云原生架构概述

閱讀本文約花費: 9 (分鐘)1. 什么是云原生 1.1 CNCF组织 在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。 目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。 1.2 云原生 CNCF给出了云原生应用的三大特征: 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。 动态管理:通过集中式的编排调度系统来动态的管理和调度。 面向微服务:明确服务间的依赖,互相解耦。 云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。 这边引用网上关于云原生所需要的能力和特征总结,如下图。 云原生所需要的能力和特征 1.3 The Twelve Factors 12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下: 基准代码 显式声明依赖关…

Read More Read More

蚂蚁金服 Service Mesh 实践探索

蚂蚁金服 Service Mesh 实践探索

閱讀本文約花費: 50 (分鐘)摘要 在勇敢的选择了Service Mesh作为未来技术方向之后,蚂蚁金服率先开始了Service Mesh大规模落地探索。在此过程中,我们遇到很多问题,面临各种挑战,也有了一些思路和方法。今天我们将这些实践分享出来,并结合我们开源的SOFAMesh项目,和大家一起探讨:如何更好的将Service Mesh这样的新兴技术落地于实际生产环境。 大家好,我是来自蚂蚁金服中间件团队的敖小剑,目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人,是 Service Mesh 技术在国内最早的布道师。我今天给大家带来的主题是”长路漫漫踏歌而行:蚂蚁金服Service Mesh实践探索”。 今天我们的内容不是继续做 Service Mesh 的布道,今年要好好讲一讲实践。所以今天我不会像去年那样给大家详细解释 Service Mesh 是什么,能做什么,有什么优势。而是结合过去一年中蚂蚁金服的实践经验,结合蚂蚁金服的 SOFAMesh 产品,帮助大家更深刻的理解 Service Mesh 技术。 在开始今天的内容分享之前,我们先来热个身,温习一下去年的内容。去年我是来布道的,而布道的核心内容就是告诉大家:Service Mesh 是什么? 为了帮忙大家回答,我给出一个提示图片,了解 Service M…

Read More Read More

Service Mesh (服务网格) 入门

Service Mesh (服务网格) 入门

閱讀本文約花費: 11 (分鐘)现在最火的后端架构无疑是微服务了,微服务将之前的单体应用拆分成了许多独立的服务应用,每个微服务都是独立的。 微服务基本组件包括服务注册和发现、服务通信和治理、故障熔断恢复、配置、安全、监控等等,这些微服务组件和功能在业界已经深入人心,在各大互联网公司开花结果,业界知名开源的微服务框架有 Netflix OSS、Spring Cloud 及其国内的阿里 Dubbo 等等,各种框架百花齐放。 微服务好处自然很多,但是随着应用的越来越大,微服务暴露出来的问题也就随之而来了,微服务越来越多,管理越来越麻烦。特别是要你部署一套新环境的时候,随之而来的服务发现、负载均衡、Trace跟踪、流量管理、安全认证等等问题。 当然随着微服务的不断发展,微服务的生态的不断完善,新的微服务框架 Service Mesh 的出现就是为了解决这一系列问题。 什么是 Service Mesh Service Mesh 是一个非常新的名词,最早是 2016 年由开发 Linkerd 的 Buoyant 公司提出的,伴随着 Linkerd 的传入,Service Mesh 的概念也慢慢进入国内技术社区。 Service Mesh 是一个基础设施层,其独立运行在应用服务之外,提供应用服务之间安全、可靠、高效的通信,并为服务通信实现了微服务运行所需的基本组件功能,包括服务注册发现、负载均…

Read More Read More

Docker不香吗,为啥还要K8s?

Docker不香吗,为啥还要K8s?

閱讀本文約花費: 16 (分鐘)上一篇文章我们着重讲解了 Docker,其实遗留了一个大问题。Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 K8s 的基本概念,后面再介绍实践,由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开: Docker 的管理痛点 什么是 K8s? 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。 于是,我们迫切需要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。 image Google 在 2014 年开源了 Kubernetes 项目,建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文我们将使用简称。 什么是 K8s ? image K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 …

Read More Read More

Scroll Up