Kubernetes 部署自动化：无缝安装和管理 (kubernetes)

Kubernetes 已成为容器编排的首选工具，它提供了一个可扩展、高可用和灵活的平台，用于管理容器化应用程序。

手动安装和管理 Kubernetes 集群可能是一项耗时且容易出错的任务。部署自动化工具，例如 Terraform、Ansible 和 Helm，可以简化这一过程，从而提高效率和可靠性。

部署自动化工具

Terraform

Terraform 是一个基础设施即代码 (IaC) 工具，用于定义和管理基础设施。它使用声明式语法，其中您声明所需的基础设施，而无需指定具体实现细节。

对于 Kubernetes，Terraform 可用于自动化集群安装、节点配置和存储卷创建。

Ansible

<应用程序。

版本控制： 自动化脚本可以存储在版本控制系统中，从而允许审计、回滚和协作。

选择部署自动化工具

选择最适合您需求的部署自动化工具需要考虑以下因素：

• 团队技能： 考虑团队对特定工具的熟悉程度。
• 复杂性： 评估您需要自动化的任务的复杂性。
• 可扩展性： 确保所选工具能够满足当前和未来的可扩展性需求。
• 社区支持： 选择拥有活跃社区支持的工具，以获得帮助和文档。

示例自动化用例

Terraform```resource "kubernetes_cluster" "my-cluster" {name = "my-cluster"version = "1.24.2"node_pools = [{name = "my-node-pool"nodes = 3version = "1.24.2"}]}```Ansible```- hosts: alltasks:- name: Install Kubernetes componentsshell: kubeadm init --pod-network-cidr=10.244.0.0/16- name: Join worker nodesshell: kubeadm join 10.0.0.1:6443 --token $kubeadm_token```Helm```helm install my-chart my-chart --namespace my-namespace```

结论

Kubernetes 部署自动化工具可以大大简化和改进 Kubernetes 集群的安装和管理。通过利用 Terraform、Ansible 和 Helm 等工具，组织可以提高效率、增强可靠性、提高可重复性和增强可扩展性。仔细选择并使用这些工具对于成功实现 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端口以开始，测试环境以开始，且一一对应。

Master数据目录

K8s-Master下的data目录下为k8s-cd-config， k8s-cd-config目录存放各业务的yaml配置，二级目录为域名，三级目录划分Master（正式），Develop（测试），目录下以 版本号-构建 命名文件，时间最后一个即为当前线上的使用配置文件，为了运维方便，在二级目录同级内，生成一个软链连接到最新的正式与测试配置文件。注意，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目录存放构建内容，二级目录为域名，三级目录为版本号（以开发部版本号为准），三级目录下存放，四级目录为构建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目录下。

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

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

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

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

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

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

容器资源监控

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

福利

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

推荐阅读：

喜欢就点击“好看”吧

保姆级k8s集群安装教程

保姆级Kubernetes集群安装教程

想快速搭建一个高效、稳定的Kubernetes集群？本文将带你一步步走过关键环节，从基础环境部署到高级配置，确保每个步骤清晰易懂。

1. 准备工作

2. 集群搭建

3. 高级配置

4. 高级功能扩展

详细步骤和链接已删除，但以上概述了关键步骤。完整教程与详细操作可参考原文链接/92c2s，并请关注Golang技术实验室获取更多内容。

本文由mdnice发布，版权所有，未经授权请勿复制。

使用Kubernetes管理Kubernetes集群

Kubernetes 1.0版本发布已经过去了4年，繁荣的社区和广泛用户群体使得Kubernetes的成熟度超出了预期，大部分用户常用的功能性需求都得到了满足。 但是，根据CNCF的调查，很多非功能性的需求尚待完善，比如，用户所面临的最困难的挑战之一仍然是管理多个Kubernetes集群的生命周期，包括集群部署、升级和变更等。 Kubernetes社区未来的一个阶段的重点就是帮助用户更好的部署和维护Kubernetes，使其无缝的融入和对接现有的企业环境。 Kubernetes现在已经可以支持超大规模的集群，单集群可以支撑5000个节点，15万个POD。 但是由于大规模集群的维护和调度过于复杂，比如，有些企业应用需要分级，不同级别的应用需要使用不同的资源池，有些业务应用需要带有GPU支持的集群，有些应用需要Windows container的支持，甚至不同应用依赖不同版本的Kubernetes，所以在企业环境中通过多集群的方式实现多租户和资源调度已经成为了最佳实践。 当你需要管理多个集群，每个集群都有不同的规模、版本、升级计划、硬件资源池，自动化的管理工具和理念就必不可少了。 我们知道，Kubernetes的很多原则和理念改变了传统资源管理和交付的模式，其中声明式API和自愈机制的引入提升了用户部署和管理应用的效率。 它允许用户通过yaml文件描述对象部署的期望状态（比如部署3个POD实例），并持续观测当前状态，如果和预期不一致（只剩2个POD实例），就通过控制器使其达到期望状态（添加1个POD实例，使总数为预期的3个）。 既然这种模式如此的成功，能不能把它适用到更多的场景中呢？比如，能不能用Kubernetes的思想来管理Kubernetes的集群呢？ 实际上社区中已经有人这么做了，Cluster API 就是在这个背景下，由google，vmware等公司共同发起的项目。 Cluster API是一个Kubernetes项目，它将声明式的、Kubernetes风格的API用于集群创建、配置和管理。 通过利用Kubernetes API的结构化和可扩展的特性，构建更高级别的云环境无关的工具，声明式的、自动化的改善用户体验。 当前，Cluster API已经可以支持AWS, Azure, GCP, Openstack, VMware, Bare metal等绝大多数基础设施环境。 在目前的版本中，该API包含五个customresourcedefinition（CRD）：Cluster、Machine、MachineSet、MachineDeployment和MachineClass。 将这几个CRD和大家熟悉的Kubernetes的对象类比一下， 说明：以下的几个CRD yaml文件都可以自动生成模板，在创建cluster的时候，并不都是必须的。 Cluster这个CRD是全新的Kubernetes集群的抽象。 它可以定义Kubernetes集群配置，例如POD网络CIDR和service网络CIDR，以及集群是运行在何种云平台之上。 Machine类似于POD，它负责描述单个Kubernetes节点（虚拟机）。 只需很少的配置(主要是Kubernetes版本信息)，其他配置通过嵌入云环境相关的ProviderSpec。 MachineDeloyment 类似于Deployment。 它允许对节点配置进行更新，定义工作节点的升级方式（rolling，recreate），它还允许回滚到以前的某个版本的配置。 用户可以修改yaml文件来动态调整集群节点的数量。 MachineSet类似于ReplicaSet，管理一组Machine的扩缩容。 与ReplicaSet类似，实践中尽量使用MachineDeloyment来管理一组资源的部署而不应该直接操作ReplicaSet。 MachineClass和StorageClass很像，定义Machine的规格。 所有节点都会从指定规格的虚拟机模板中clone出来。 Cluster API的工作原理非常简单，用户通过以上的几个CRD定义需要的Kubernetes集群的规格。 通过熟悉的kubectlapply命令把yaml传递给management cluster，managerment cluster会根据需要驱动不同的云平台创建虚拟机安装部署Kubernetes binary，并交付集群给用户。 那么management cluster是怎么来的？是否后续的运维工作也需要依赖它呢？实际上，初始的management cluster一般是一个单机版的Kubernetes，比如minikube或者Kind。 当置备出第一个workload cluster以后，可以将management cluster的功能转移到任何一个workload cluster，这样后续的工作就不在依赖单机版的Kubernetes。 一个有意思的地方是，你会发现，某一个workload cluster同时也是management cluster，在管理和监控着它自己。 下面是一个在vsphere环境使用Cluster API的例子。 首先，使用Cluster API项目提供的工具生成一组部署的yaml模板。 根据需求调整yaml文件中的内容，比如虚拟机模板的名称、集群节点的数量等。 然后依次创建这些资源对象， 这时可以在vcenter中看到Kubernetes集群的虚拟机陆续被创建出来。 大约几分钟后，workload cluster就可以交付给用户使用了。 我们可以关闭或者删除一个workload cluster的节点的虚拟机来模拟故障场景。 Cluster API会自动检测所有节点的状态，并且驱动vsphere重新生成一个虚拟机进行替代，使得Kubernetes集群的状态与预期描述的一致。 像不像Kubernetes管理POD的功能？ 以上实验的具体的细节可参考官方文档，解决多集群生命周期的管理只是企业环境使用Kubernetes的第一步，后续还有什么问题是需要考虑的？

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！