应该是去年在摸索servicemesh时,看过些关于Kubernetes资料(主要是ppt载体的信息),也部署并体验了一番Openshift,同时留下过两篇关于servicemesh和Kubernetes的两篇文章。
但个人感觉以前的了解是有点片面和零散(其实网上大多分享都是如此哈)。这次组里需要评估分析下Dubbo在云原生的思路,所以这几天我就花了些时间温习了这块的知识,看了《Docker实践》《Kubernetes实战》两本书,希望能够全面而分层次地做一些记录。
为了说清楚云原生,先从三个问题开始,希望大家能自己思考下。
这里主要是阅读《Docker实践》的记录。
Docker是一种Linux容器工具集,它是为构建(Build)、交付(Ship)和运行(Run)分布式应用而设计的。容器化保证应用的独立可重复性;虚拟化来保证物理主机安全的功能模式。
Docker与开发: 开发环境的一致,进程即环境;传统配置工具(make,chef,puppet等)与Docker协作;构建更小的镜像;Docker对于开发的友好性,最好隐藏dockerfile,使得source到Image自动化。
Docker与Devops:从Git到Docker Hub到Jecksin的自动化工作流;从持续提交(source)-》持续集成(test) -》持续部署(蓝布发布,灰度发布等)-》持续交付(版本管理,基础环境的整体搭建,资源按需伸缩);
Docker与生产环境:其实就是swarm,Kubernetes等PaaS层的东东的用武之地。
前面说了有了Docker化后的应用后,需要一平台级的东东来管理这些Docker容器。以下是阅读《Kubernetes实战》的一些点。
Kubernetes的流行跟Docker是息息相关:Docker的流行激活了一直不温不火的PaaS。Kubernetes可以说是Google借助着容器领域的爆发,对于其巨大规模数据中心管理的丰富经验的一次实践,旨在建立新的技术业界标准。Google从2004年起就已经开始使用容器技术了,于2006年发布了Cgroup,而且内部开发了强大的集群资源管理平台Borg和Omega,这些都已经广泛使用在Google的各个基础设施中,而Kubernetes的灵感来源于Google的内部Borg系统,更是吸收了包括Omega在内的容器管理器的经验和教训。
抛个问题吧。为什么Kubernetes在最早的compose,swarm,甚至mesos中能够脱颖而出? 这个跟它的模型抽象(也对应了核心概念)是有很大关系。
持续集成与持续部署(Continuous Integration & Deployment)应该是最能体现PaaS平的特色之处,各家云厂商都在基于Kubernetes提供PaaS服务,在CI/CD上的产品特性和用户使用体验是区分这一服务的重要之处。 下图是从别处Copy来的简单对比。个人理解,广义上的CI/CD应该包含从创建项目开始,囊括了需求管理,设计管理,到代码管理,到环境配置,到代码(镜像)构建,最后到日常/测试/预发/灰度/线上等环境的部署,这可能也算是核心切入点之一吧,也就是发挥集成优势,打通相关环节,提供一站式应用服务。
可以花点时间了解以下主流的CI/CD,取长补短:
无论是pod,Service,还是Node,Endpoint,PV等等都是Kubernetes的基本对象,有三种方式来访问和操作这些对象。
API对象的元数据用来定义API对象的基本信息,体现在定义中的metadata字段,包含以下属性。
•namespace:指定API对象所在的Namespace。
•name:指定API对象的名称。
•labels:设置API对象的Label。
•annotations:设置API对象的Annotation。
Namespace是Kubernetes提供的多租户,不同的项目、团队或者用户可以通过Namespace进行区分管理,并且设置安全控制和其他策略。绝大部分API对象(除了Node)归属于Namespace,API对象通过.metadata.namespace指定Namespace,如果没有指定Namespace,那么就是归属于默认Namespace default。
名称是一个重要的属性,是人类可读的,元数据中的.metadata.name用于指定API对象的名称。Kubernetes系统中的API对象必须能够通过名称唯一标识,Kubernetes包含Namespace的逻辑层级,大部分API对象必须归属于Namespace,所以这些API对象的名称必须在Namespace内唯一。而另外对于Node和Namespace来说,需要在Kubernetes系统中唯一。
Label用于区分API对象的Key/Value对,Label存放的应该是具有标识性的数据,Kubernetes通过Label可以对API对象进行选择。ReplicationController和Service都是通过Label关联Pod,而Pod也可以通过Label选择Node。
Annotation用于存放用户的自定义数据,Annotation存放的是非标识的数据,所以不能像Label一样进行对象选择。但是Annotation的数据可以是长数据,可以有结构或者无结构,作为Label的一种补充,Annotation也是Key/Value对。
这部分不谈sidecar,也不谈Envoy和Dubbo的区别,具体可以看上面提到的两篇文章。个人认为,ServiceMesh最核心的点还是控制面的能力,也就是Istio相关的事情。Istio如果model定义得足够标准且可扩展,以至于成为像Kubernetes成为事实上的容器应用的PaaS标准,那么无论Dubbo,还是envoy,还是Nginx,还是Conduit都会作为一种可选的方式来接入,就像用户(一般是开发者)只看到的是Kubernetes,而无需关注Docker还是其他CRI的实现。
所以,下面着重把istio定义的一些model来做个记录。
一句话理解就是先做service的基本模型抽象,继而允许适配到具体的容器调度平台上,无论pilot还是mixer。
Istio Services Model Introduction |
|
Services Model: Services |
|
Services Model: Instances |
Each service has one or more instances, i.e., actual manifestations of the service.
|
Services Model: Service Versions |
|
Services Model: Labels |
|
Services Model: Routing |
• Services have no knowledge of different versions of the Service being accessed. • Services are simply accessed using the Network Endpoint of the Service. • The proxy is responsible for routing the connection/request to the appropriate Versionbased on the routing rules set up by the user and pushed to Istio-Manager. |
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。
前面一个问题估计就是个人云亦云,很可能被人带着走的,走入被人牵着鼻子的境地。云原生首先是一种思想,而Kubernetes是提出这套思想的CNCF所推崇的最佳实践和核心,无论是CNCF的Landscape还是Trail Map都能看出Kubernetes的无处不在,所以在我们无法准确表述云原生思想和没有自己的服务云原生的实现情况下,从狭义上理解Kubernetes≈≈云原生,通过应用和实践Kubernetes来慢慢理云原生思想无疑是最合适。
传统意义上的微服务方案Dubbo/HSF融合到CNCF Landscape,成为其一等公民,从而享受到这个生态的服务红利,同时也要展示出自己的特色,有其独特的吸引力来立足,说白了让大家知道Dubbo也是先进的“时髦”的微服务方案,这个问题才是核心,但回答这个问题,好难!期待有人能答疑解惑。
简单说来,云原生(Cloud Native)是伴随的容器技术发展出现的的一个词,需要应用符合一些特质如无状态、可持续交付、微服务化等。Kubernetes与云原生概念两者互相成就,一起推波助澜,基本上形成了当前新一代PaaS的基石。云原生的流行本质上是开放开源的流行:开放意外着可扩展且共建,开源意味着可控且快速迭代。
从一定角度看,以Kubernetes为基石来落ServiceMesh最终拥抱云原生这条路应该是比较切实际。