阿里云kubernetes（阿里云kubernetes贵吗）

本文目录一览：

• 1、基于Kubernetes的持续部署方案
• 2、云计算时代操作系统Kubernetes之PV，PVC存储体系
• 3、kubernetes cloud-provider for aliyun
• 4、Windows安装Kubernetes

基于Kubernetes的持续部署方案

文章转载自Docker

方案概述

本技术方案为基于Kubernetes为核心的持续部署（下文简称CD）方案，可以满足开发方的程序级日志查看分析，运维方的快速扩容与日常运维分析，并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升，在不降低服务可靠性的前提下降低资源使用成本。

使用场景分析

本方案适用于以Tomcat为容器的JavaWeb项目的持续部署过程，在Kubernetes方案中，所有的Node节点均采用统一配置，根据业务环境的需求进行节点数量的控制。

技术架构与选型

Kubernetes集群部署模式：Stacked etcd topology

Kubernetes的安装使用kubeadm安装为高可用集群，并选用Stacked etcd topology 模式。

详情参考。

Kubernetes生态技术选型：网络层面选型Weave

容器网络解决方案。Weave创建的虚拟网络可以将部署在多个主机上的容器连接起来。对容器来说，Weave就像一个巨大的以太网交换机，所有容器都被接入这个交换机，容器可以直接通信，无需 NAT 和端口映射。

原理详解：

Kubernetes生态技术选型：对外服务选型NodePort

Kubernetes目前支持NodePort、LoadBanlace、Ingress三种对外提供服务的模式，其中LoadBanlace需要云平台的支持，阿里云提供了解决方案，但腾讯云未找到，Ingress技术为新出技术。整体评估采用NodePort方式更为灵活，每个服务一个唯一的对外IP地址，并且使用Nginx进行负载均衡（采用Nginx主要为日志分析）。

介绍与使用方法：。

持续部署过程

各组件业务配置

Kubernetes业务配置

命名空间

在业务上，Kubernetes默认配置两套Namespace，分别为Master存放正式环境，Develop配置测试环境。

对外端口

正式环境Web端口以32001开始，测试环境以31001开始，且一一对应。

Master数据目录

K8s-Master下的data目录下为k8s-cd-config， k8s-cd-config目录存放各业务的yaml配置，二级目录为域名，三级目录划分Master（正式），Develop（测试），目录下以 版本号-构建ID-GITID.yaml 命名文件，时间最后一个即为当前线上的使用配置文件，为了运维方便，在二级目录同级内，生成一个软链连接到最新的正式与测试配置文件。注意，k8s-cd-config仅在其中一台Master中存在。

Node数据目录

节点下的/data一级目录下分Filebeat、Dockerlibs、Nodelogs，其中Dockerlibs存放Docker相关数据，Nodelogs目录通过volume的方式挂载入Kubernetes的Pod， Nodelogs下分Develop与Master目录，区分正式环境与测试环境，每个Master与Develop下分为accesslogs、devlogs、tomcatlogs分别存放访问日志，开发部日志，Tomcat日志，日志目录下为项目（域名），域名下为Pod名称目录。

注意事项 ： 节点加入集群后，一定要下载手工下载kubernetes-dashboard-amd64镜像，防止dashboard所在节点挂掉以后dashboard无法在其他节点启动。

Harbor业务配置

业务分组

Harbor重定义其Registry的存储路径直接使用docker-compose安装。template 存放基础进项，各域名分组存放业务镜像。

镜像命名

分组下镜像以站点域名:版本号-类型-CDGITLAB为名称，并基于版本号确定不同的站点版本。

数据目录

Harbor数据目录统一存放在/data下。

备份策略

Harbor默认不设置备份，对于业务镜像无需进行备份，每次进行构建即可，对于模板类镜像，在Jenkins机器上均可以找到，若Harbor出现问题，则直接重建，并将Jenkins上的模板镜像进行重新push。

注意：为了业务的稳定性，Harbor由独立的服务运行（基于Docker），并不运行在Kubernetes内。

Jenkins业务配置

数据目录

Jenkins下的data目录分为dockerlibs、thinbackups、gitlab-files 、jks-cd-config。

Dockerlibs存放Docker相关文件，thinbackups存放每日的Jenkins备份，gitlab-files存放构建GitLab的文件（运维可以在此操作pull，push），jks-cd-config为jks构建目录。

Jenkins机使用/data/jks-cd-config目录存放构建内容，二级目录为域名，三级目录为版本号（以开发部版本号为准），三级目录下存放ROOT.war，四级目录为构建ID_GITID，目录下存放构建的原始数据。

节点每天进行images清理工作。

业务分组

Jenkins的分组分为template与各domain，template存放模板，domain以域名的形式存放正式项目：

新项目由运维手工创建，后续的秩序构建过程由开发部调用API完成。

构建参数

Jenkins构建时，需要传递三参数，1：程序版本号，2：类型：apply与delete，3：正式环境还是测试环境，正式环境为Master，测试环境为Develop，对应Kubernetes的Namespace。

此部分功能后期将通过开发部的构建凭条调用JenkinsAPI实现。

JenkinsAPI

APIDoc：

Token：

备份策略

Jenins安装ThinBackup插件，配置每小时进行一次全局备份，且最多保留10份，备份后数据传至异地。

注意：为了业务的稳定性，Jenkins由独立的服务运行，并不运行在Kubernetes内。

GitLab业务配置

业务分组

CD GitLab项目下分两个组template与各domain，template存放模板文件。例如：

Git分支

default下以域名划分项目，每个项目划分Master与Develop两个分支，分别存放正式环境与测试环境CD文件。

CD文件树

备份策略

GitLab使用gitlab-rake gitlab:backup:create进行每日定期备份，并传送至异地。

EFK与日志管理

Elasticsearch

ES数据通过索引仅保留近10天的数据，每日通过脚本方式进行数据删除。ES的数据保存在/data/elasticsearch目录下。

Filebeat

在每个Node节点启动一个Filebeat进程，用于日志的采集工作，filebeat分别监控：

其中，tomcatlogs日志需要进行特殊处理，进行多行合并，数据写入ES时，使用processors. Dissect进行目录名称截取，并使用域名作为ES的索引使用。

截取gy. wtype ( master或develop) , ltype(accesslogs 、tomcatlogs、devlogs),domain(xxx.gyyx.cn)。

Kibana

Kibana目前我们仅使用其discover节点，用于日志数据的查询，在配置方面。

Kibana配置使用“域名-*”方式进行配置，每次新增域名，需要在此进行手工配置。

Kibana使用discover查看时，默认展示一个域名下所有的日志，可以通过gy.wtype筛选选择查看测试环境还是正式环境，或者通过gy.ltype哪种日志类型。

容器资源监控

容器资源使用WeaveScope进行资源消耗监控。

福利

扫描添加我微信，备注“ 姓名+公司职位 ”，加入【 云计算学习交流群 】，和志同道合的朋友们共同打卡学习！

推荐阅读：

喜欢就点击“好看”吧

云计算时代操作系统Kubernetes之PV，PVC存储体系

我们前边的关于存储卷的讨论，都是在讲如何将网络存储设备挂载到我们的应用程序POD中，而在实际项目上，我们必须对集群所提供存储技术和类型有深入的理解，才能顺利完成将支持类型的volume挂载到容器中，供应用程序来持久化数据。

举个例子，如果你使用的是托管的阿里巴巴ACK集群，需要使用OSS存储类型，那么你就必须定义对应的Persistent Volume，当我们将应用迁移到自己数据中心后，就需要定义数据中心Kubernetes环境支持的Persistent Volume对象，因此这种直接定义PV的方式，灵活性太差了。为了能在其他云平台上使用PV，我们就必须修改YAML文件，以适配新的环境。

我们一直强调Kubernetes标准化了应用程序的部署，特别是在多个云平台之间的跨云部署场景，每次都修改PV才能完成部署很明显有悖于我们介绍的Kubernetes理念。幸运的是，Kubernetes已经考虑了这个问题，并且提供了一种更加便利的机制来给POD增加存储资源。而我们通常把这种机制叫做PV/PVC体系。

理想情况下对于开发人员而言，部署应用程序到Kubernetes集群就不应该关心具体的存储技术和细节，就如同Kubernetes将工作节点进行抽象类型，开发人员面对的只有POD，而基础设施相关的部分应该让专业人士来处理，比如集群的运维人员和专业的devops团队。

正因为如此，我们在部署应用到Kuberntes集群的时候，我们很少直接设置具体存储的细节，而是通过一种间接的方式来使用PV提供的存储能力，如下图所示，这就把POD和底层具体的存储系统进行了解耦，POD的定义中不用在包含和具体基础设施相关的配置信息：

很多公司内部都会自己搭建NFS文件存储服务器，我们来举个例子，假设在POD中我们要使用NFS文件服务来共享数据，那么在volume的定义中就需要包含NFS文件服务器的IP地址和要挂载的目录路径，如下图所示：

注：网络文件系统（NFS）是文件系统之上的一个网络抽象，允许远程客户端以和本地文件系统类似的方式来通过网络进行数据访问。NFS允许在多个用户之间共享公共文件系统，并提供数据集中的优势，来最小化所需的存储空间。

这样做的结果是，我们将POD和具体的集群存储细节进行了耦合，从而降低了灵活性。如果我们要将如上这个POD部署到另外一个集群中，那么我们就需要修改NFS文件服务器的IP地址，修改YAML文件可能会产生错误，因此这种方式本质上说明POD跨Kubernetes集群部署的灵活性不足。如下图所示：

由于这个原因，我们需要将环境相关的配置信息抽取到另外一个叫PV的对象中，来解耦POD和具体存储信息，提升POD的兼容性。Kubernetes平台用PersistentVolume对象来代表集群中可以用来存储数据的volume，如下图所示，PersistentVolume对象将底层存储机制的详细信息从POD的YAML文件中解耦：

由于POD中不再包含基础设施相关的配置信息，兼容性得到了极大的提升。当然这些配置信息还是需要的，只是被转移到PV对象上而已。本上上来看，这其实并不是什么新技术。但是计算机从发展之初，通过增加一层来解决问题的方法，可以说是屡试不爽，我们应该在自己的架构设计中，多多考虑这样的思想，当然需要考虑复杂性和合理性，并不是说中间层越多越好。

笔者在上篇文章中介绍过使用阿里云OSS存储卷类型的例子，如果你还有印象的话，应该记得我们的配置文件中使用persistentVolumeClaim对象来定义数据卷，如下图所示。在Kubernetes平台中，通常POD间接的通过PVC映射到PV对象，这就让PV从POD的生命周期中进一步解耦。

如上图所示，PersistentVolumeClaim对象表示用户对存储资源的需求，由于用户在使用存储资源的时候，并不清楚集群中有哪些类型的Volume，因此Kubernetes就引入了这个PVC对象，来简化使用PV的复杂度。这样的话我们只需要在定义POD的时候，使用PVC对象即可，而在PVC对象的定义中，我们需要声明存储的需求，比如存储空间大小，访问模式等。

当POD运行完成退出的时候，会删除PVC，底层的PV会被释放，释放后的PV就可以被其他的PVC使用。接下来我们通过一个实际的例子看看如何定义PCV和PV存储模式。

比如我们现在已经在集群中创建了一个PV对象，指向NFS文件存储服务器；有一个PVC对象绑定到PV对象，这样我们就可以直接在POD的YAML中，数据卷定义部分直接指定PVC对象，不用设置详细的NFS文件服务器IP地址等。

如下图所示，当POD被调度到具体的工作节点时，Kubernetes负责通过PVC引用到PV对象，然后使用PV对象中配置的NFS文件服务器的信息将对应的目录挂载到容器中。

如上图所示，POD在创建的时候，会通过PVC引用的PV对象来定位到存储资源的具体信息，并将指定的目录挂载到容器实例上。表面看，通过三个对象来挂载存储资源很明显比一个要复杂，但是你有没有深入思考过Kubernetes为什么要如此设计？

其实这里最大的好处就是“解耦”，或者叫消除依赖。通过增加PV和PVC这两个对象，基础设施相关的信息和应用的部署YAML解耦了，让专业的人，集群管理员来负责PV的创建，开发人员的时间就可以放在更具价值的开发上，如果要部署，只需要使用PCV来声明自己的需求就可以了。如下图所示，我们来看看集群管理员开发人员是如何配合在一起，各司其职，成功将应用部署到Kubernetes集群上：

如上图所示，开发人员不用再面对具体底层的存储资源配置细节，集群管理员统一负责配置和管理所有的存储资源，并且在Kubernetes平台上通过创建PV对象来提供给应用程序使用。当开发人员在部署应用的时候，通过创建PVC来声明具体要使用的资源需求，比如直接指定PV对象的名称，或者指定请求的存储空间大小和访问模式，Kubernetes基于这些信息完成绑定。

接下来我们就可以在POD中定义volume的时候使用PCV，当POD被创建的时候，POD中运行的容器实例就可以将存储设备attach到工作节点，并将指定的目录挂载到容器的文件目录树中。大家需要特别注意的是，在PVC/PV模式下，开发人员不需要了解底层具体的存储设备信息，这部分工作属于专业人士集群管理员，开发人员只需要通过PVC来声明应用的存储资源需求。

进一步讲，如果我们的集群是托管实例，那么管理员甚至都不需要自己手动来进行PV的创建和管理，我们可以通过云平台提供的自动化volume提供机制，在有需要的时候，自动创建PersistentVolume和PersistentVolumeClaim对象，提供给应用程序使用。

通过上边的内容，相信读者对PVC/PV有全面的了解了，接下来我们来通过实际的例子来验证一下。由于笔者使用的Kubernetes环境支持的存储资源非常有限，但是又需要通过具体的例子来说明这些对象如何使用，笔者决定暂缓这部分内容到后续专门介绍如何在阿里云ACK上使用PV/PCV。

好了，今天的内容就这么多了，我们下篇文章会介绍云原生模式中一个非常重要的概念，如何让应用无状态，或者说如何管理应用程序的配置信息，敬请期待！

kubernetes cloud-provider for aliyun

CloudProvider 提供kubernetes与云厂商基础服务的对接能力，由 cloud-controller-manager组件实现(lb,云盘，安全组等等)。

aliyun-cloud-provider这个组件主要是aliyun平台的对接插件，可以让用户在创建k8s LoadBalancer 类型的service的时候自动的为用户创建一个阿里云SLB，同时动态的绑定与解绑SLB后端，并且提供了丰富的配置允许用户自定义生成的LoadBalancer.

其他cloud-provider比如aws可提供elb，ebs，安全组等能力，阿里云这里实现了service_controller和route_controller，所以暂时只提供了对接slb资源，其他资源需要单独插件在cloud-provider上层实现，比如cluster-autoscaler需依赖cloud-provider完成node初始化.

所以cloud-provider的能力仅仅对接云厂商基础服务给kubernetes集群使用,我们使用aliyun-cloud-provider 主要也是对接aliyun ess资源，使用cluster-autoscaler动态/定时伸缩kubernetes node节点。

集群环境：

kubele 启动参数添加--cloud-provider=external --hostname override= instance id--provider id= instance id参数并重启kubelet。格式为 Instance。

以下命令可找到REGION_ID 和INSTANCE_ID

然后重启kubelet kubectl get node 查看hostname是否生效，也可以delete node,重新注册到集群。

cloud-provider需要一定的权限才能访问阿里云，需要为ECS实例创建一些RAM策略，或者直接使用accesskeyidsecret，由于我们容器部署cloud-provider所以这里采用AK。

1.配置aliyun-cloud-provider AK(access key) 权限

创建自定义策略，然后将策略绑定到k8s-cloud-provider用户，创建其AK提供给aliyun-cloud-provider使用，保证只能访问我们授权的资源。或者参考地址:

创建cloud-config configmap 为cloud-provider提供配置，主要存放AK信息

替换$CA_DATA 为cat /etc/kubernetes/pki/ca.crt|base64 -w 0输出结果或者kubectl config view --flatten=true可查看CA data ,以及将apiserver替换自己kubernetes apiserver的服务器地址. 我们通过configmap 挂载到cloud-provider容器中.

一旦云控制器管理器启动并运行，运行一个示例nginx部署：

然后使用以下类型创建服务：LoadBalancer:

其他SLB相关创建annotation参考：

cloud-provider注意事项 :

通过cloud-provider动态管理SLB最佳实践：

FAQ:

参考链接:

Windows安装Kubernetes

学习Kubernetes的第一步就需要搭建一个可用的Kubernetes环境，这里针对Windows的安装过程做简要记录

事先安装 Docker Desktop

安装过程中可能会出现错误需要我们及时查看日志来排查问题，日志目录:C:\ProgramData\DockerDesktop

首先确认当前需要安装的版本，从下图中可以看到需要安装的版本为v1.22.4

确认镜像源配置为阿里云镜像加速

由于国内的网络问题，直接启用Kubernetes会无法正常启动，如下图所示

进入目录C:\Windows\System32\drivers\etc编辑文件hosts添加一行

否则执行命令会出现如下错误

把勾勾上，等待一段时间，就会发现下发那个kubernetes的点变绿了，代表kubernetes启动成功

由于启动较慢，这里可以通过命令查看容器的启动状态

此时即可以说明环境安装正常

使用kubectl proxy命令访问

打开浏览器访问网址

填入Token并信息登录

进入后可以看到如下页面

清理旧提权

创建集群用户

查token用于登录

登录看板

此时这里可以看到多有的命令空间，且右侧不会再有报错通知消息

此时查看Pod等待正常运行即可

打开浏览器访问