首页 文章 精选 留言 我的

精选列表

搜索[k8s],共3934篇文章
优秀的个人博客,低调大师

树莓派上的 K8S 集群挂了,怎么办?

作者 |Lukasz Raczylo 编译|云原生计算编辑部 昨晚在我的树莓派上进行更新的时候,所有节点突然停止检测网络接口,并且无法恢复!!! 那时我有两个选择,但都很费时: 方法1:提早起床,并按照我自己之前的文章手动重建,也许还会发现一些改进的余地。我已经亲身试验了很多次:这种方法很容易出错,主要是输入错误或跳过一个或两个步骤,然后在接下来的半个小时试图找出到底发生了什么事,再抹去一切并从头开始一遍又一遍。 方法2:及早醒悟并从头开始编码,这样可以让我的最终解决方案实现执行一次并永久使用,使整个集群的重建和生产尽可能容易地进行复制。当然,这将意味着更多的停机时间。但是,它的好处将是长期的,这使我不必担心集群本身,并最终将其视为一个稳定的解决方案,可以向其迁移整个本地基础架构。 自动化传奇开始 在开始任何工作之前,我都非常专注于基础知识,并提出了在整个过程中遵循的一些原则。这样创建的环境各部分之间的代码之间逻辑上有很多分隔,因此亲爱的读者,您可以更容易地更改代码或注释掉整个文件以禁用此处或此处的少量功能。 原则1:在树莓派上设置 Kubernetes 集群可以分为三个部分:设置存储卡,在系统级别上进行节点配置,最后扩展 Kubernetes 资源。 原则2:在我的旧版 Intel NUC 上运行着一个NFS服务,该服务已连接到 DROBO 存储。很适合将它用作所有节点的永久共享存储。 原则3:树莓派的集群在我的家庭网络中的 VLAN 中运行,因此保护它不是我的优先事项,所有服务以及节点都应易于访问,而无需处理 credentials。 要重现结果(或使其发挥作用),您将需要: Mac:当我有空安装Linux VM时,我可能会在脚本中添加平台监测部分 Ansible:我使用的版本为2.10.6 Terraform:用0.13.4编写,也适用于0.14.8 Make:任意版本应该均可使用 树莓派集群:步骤1 树莓派使用存储卡作为其硬盘驱动器。这可能不是最佳选择,并且绝对不会给您最大的读写操作速度,但对于业余爱好项目而言,应该足够了。 步骤1需要注意什么? 格式化存储卡 将存储卡分为两个分区-1GB +其余存储卡 将Alpine Linux镜像复制到存储卡上 创建系统覆盖 系统覆盖负责设置 Promisc 模式下的 eth0(对于MetalLB来说是必需的),并配置 SSH 免密登陆。 重要提示:检查001-prepare-card.sh的来源,请确保刚才插入的存储卡实际上是/dev/disk5,否则可能会丢失数据。 结果:准备6张存储卡大约需要一分钟。 树莓派集群:步骤2 这一步才是真正有趣的开始。我猜你已经把存储卡插入到你的树莓派,连接了所有的电缆(网络和电源),并允许它们启动?你现在需要获取你的设备的 IP 地址——你可以通过连接屏幕到每一个设备并执行ifconfig eth0或者登录到你的路由器并检查来实现。用合适的值调整pi-hosts.txt。 [masters]pi0ansible_host=192.168.50.132#Pi0 [workers]pi1 ansible_host=192.168.50.135 # Pi1pi3 ansible_host=192.168.50.60 # Pi3pi4 ansible_host=192.168.50.36 # Pi4pi2 ansible_host=192.168.50.85 # Pi2pi5 ansible_host=192.168.50.230 # Pi5 重要提示:今后很少有事情需要pi0主机名。 将以下内容添加到~/.ssh/config,强制将所有pi *主机作为根连接。 Host pi? User root Hostname %h.local 因为我们已经准备好了微机,所以我们需要为 Ansible 运行做好准备。使用001-prepare- anable .sh脚本可以轻松完成此操作,该脚本将将 ssh 到 pi-hosts 文件中指定的每个服务器,为NTP配置 chrony 并安装 Python 解释器。 重要提示:您可能需要检查rpi.yaml文件并根据需要调整vars部分。 成功执行此步骤后,您可以执行ansible-playbook rpi.yaml -f 10来运行Ansible,该运行将按以下顺序进行: 常见操作: 安装必要的软件包 分区并格式化 RPI 存储卡 将“更大”的分区设置为系统磁盘 添加所有 fstab 条目 提交更改 重新启动树莓派以从“permanent”分区启动 KUBEMASTER: 使用 kubeadm 设置主节点 将令牌存储在本地(在static/token_file中) root在树莓派上设置可以访问 kubectl 的用户 将 Kubernetes 配置保存在本地(在static/kubectl.conf中) KUBEWORKER: 将 token 复制到 worker 节点 它使 worker 通过 token 文件加入您的主服务器 将kubectl.conf复制到 workers 的root用户 基本操作: 从 Master 上移除污点,使其参与工作负载 在节点上安装py3-pip,PyYaml和helm 如果您还在阅读(恭喜您),您刚刚完成了基本的Kubernetes集群。我相信,这就像执行几个脚本然后等待它们完成一样简单,而且肯定比手动方法更好。 重要提示:您可以任意多次运行它。一旦完成,你的存储卡就不会重新格式化。 结果:安装6节点的基本 Kubernetes 集群大概需要花费几分钟,具体的时间取决于你的网络链接状态。 树莓派集群:步骤3 成功执行前两个步骤后,您应该已经准备好将树莓派的集群用于第一个部署。只需很少的基本设置步骤即可使其按需运行,但是请猜测一下……它们也被自动设置,并由 Terraform 来负责。 首先让我们看一下配置: # Variables used for barebone kubernetes setupnetwork_subnet = "192.168.50" net_hosts = { adguard = "240" adguard_catchall = "249" traefik = "234" torrent_rpc = "245"} nfs_storage = { general = "/media/nfs" torrent = "/mnt/drobo-storage/docker-volumes/torrent" adguard = "/mnt/drobo-storage/docker-volumes/adguard"} # ENV variable: TRAEFIK_API_KEY sets traefik_api_key# ENV variable: GH_USER, GH_PAT for authentication with private containers 您可以看到我正在192.168.50.0/24网络中运行集群,但是默认情况下,MetalLB 将使用地址200-250作为网络地址池的“end”。当我有了我的家庭 torrent 服务器和来自Adguard 的 DNS 时,我希望它们具有特定的地址,连同 Traefik 平衡器为仪表板提供“东西”。 重要提示: nfs_*_path值应与您在步骤2中更新的设置兼容。 确保您的 Kubernetes 配置文件~/.kube/config更新了static/kubernetes.conf的访问细节,我正在使用home-k8s作为上下文名称。 Terraforming有什么作用? 网络 安装 flannel和host-gw的配置补丁; 安装metalLB并将网络设置为var.network_subnet200–250; Traefik 安装 Traefik 代理,并通过 metalLB 负载平衡器将其公开到您的家庭网络。Traefik 仪表板本身可以通过以下方式访问traefik.local 在树莓派集群上运行的 Traefik 仪表板 Adguard 使用 NFS 安装具有持久卷声明的 Adguard DNS 服务; 通过 traefik 公开仪表板,并通过家庭网络中的专用IP公开服务本身,如下所示:adguard.local 在树莓派集群上运行的 Adguard Home Prometheus 在所有节点上安装和部署 Prometheus 监控堆栈和 grafana。更新 Prometheus DaemonSet,从而消除了进行卷挂载的必要性。它也通过 traefik 将 grafana 曝光为grafana.local。默认的 grafana 用户/密码组合为admin:admin。Grafana 附带一个预装的插件 devopsprodigi - kubegrafi -app,我认为这是用于集群监控的最佳插件。 在树莓派集群上运行的 Grafana 仪表板 Kubernetes Dashboard 安装 KubernetesDashboard并通过 traefik 将其公开k8s.local 在树莓派集群上运行的 Kubernetes 仪表板 1.Torrent 使用 Flood Web 界面安装和部署torrent服务器(rTorrent)。通过公开仪表板torrent.local。它使用大量的挂载来存储数据和配置。有一个将复制设置为1的理由:-rTorrent的lock file有问题,并且由于它使用共享目录,因此如果检测到lock file件,它就不会启动。(在我的私有配置中)rTorrent被设置为监听端口23340。 2.备份 由于树莓派运行在存储卡上,由于经常读写操作,存储卡可能会磨损,所以我决定在NFS中添加etcd的定期备份。它们每天运行一次,在t erraform 应用的配置下——每个备份“重量”约为32兆字节。 为了使操作更简单,我创建了 Makefile,该文件应该可以帮助您进行设置。您可能需要设置以下环境变量。 TRAEFIK_API_KEY // Traefik API keyGH_USER // Github userGH_PAT // Github Personal Access Token 重要提示:Github 证书现在还没有使用,但我计划很快添加身份验证,以便从 GHCR 提取私有镜像。 ADDITIONAL_ARGS=-var 'traefik_api_key=$(TRAEFIK_API_KEY)' -var "github_user=$(GH_USER)" -var "github_pat=$(GH_TOKEN)" apply: cd infrastructure; terraform apply $(ADDITIONAL_ARGS) -auto-approve -var-file ../variables.tfvars plan: cd infrastructure; terraform plan $(ADDITIONAL_ARGS) -var-file ../variables.tfvars destroy: cd infrastructure; terraform destroy $(ADDITIONAL_ARGS) -var-file ../variables.tfvars destroy-target: cd infrastructure; terraform destroy $(ADDITIONAL_ARGS) -var-file ../variables.tfvars -target $(TARGET) refresh: cd infrastructure; terraform refresh $(ADDITIONAL_ARGS) -var-file ../variables.tfvars init: cd infrastructure; rm -fr .terraform; terraform init import: cd infrastructure; terraform import $(ADDITIONAL_ARGS) -var-file ../variables.tfvars $(ARGS) lint:terraformfmt-recursiveinfrastructure/ 总结 所有代码可在 GitHub 上的 lukaszraczylo / rpi-home-cluster-setup 中使用,任何人均可免费使用和修改)。我还发布了具有支持 ARM64 处理器的多体系结构的定制构建的 docker 映像(rTorrent和Flood)。 自动化可以节省时间,节省精力,而且绝对可以完成工作。我经常清除整个集群,并使用前面提到的存储库从头开始构建,以确保它按预期工作。我将保持这篇文章和存储库的最新功能和特性。 原文链接: https://itnext.io/i-broke-my-kubernetes-cluster-running-on-raspberry-pi-355234a24d 重磅!云原生计算交流群成立 扫码添加小助手即可申请加入,一定要备注:名字-公司/学校-地区,根据格式备注,才能通过且邀请进群。 了解更多微服务、云原生技术的相关信息,请关注我们的微信公众号【云原生计算】!

优秀的个人博客,低调大师

K8S中使用Argo CD做持续部署

作者 | 乔克 持续部署这个词对技术人员来说并不陌生,很多时候我们都将CI和CD揉在一起了,今天我们将他们分开。 什么是ArgoCD Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD是一个基于Kubernetes的声明式的GitOps工具。 在说Argo CD之前,我们先来了解一下什么是GitOps。 什么是GitOps GitOps是以Git为基础,使用CI/CD来更新运行在云原生环境的应用,它秉承了DevOps的核心理念--“构建它并交付它(you built it you ship it)”。 概念说起来有点虚,我画了张图,看了你就明白了。 image.png 当开发人员将开发完成的代码推送到git仓库会触发CI制作镜像并推送到镜像仓库 CI处理完成后,可以手动或者自动修改应用配置,再将其推送到git仓库 GitOps会同时对比目标状态和当前状态,如果两者不一致会触发CD将新的配置部署到集群中 其中,目标状态是Git中的状态,现有状态是集群的里的应用状态。 不用GitOps可以么? 当然可以,我们可以使用kubectl、helm等工具直接发布配置,但这会存在一个很严重的安全问题,那就是密钥共享。 为了让CI系统能够自动的部署应用,我们需要将集群的访问密钥共享给它,这会带来潜在的安全问题。 ArgoCD Argo CD遵循GitOps模式,使用Git存储库存储所需应用程序的配置。 Kubernetes清单可以通过以下几种方式指定: kustomize应用程序 helm图表 ksonnet应用程序 jsonnet文件 基于YAML/json配置 配置管理插件配置的任何自定义配置管理工具 Argo CD实现为kubernetes控制器,它持续监视运行中的应用程序,并将当前的活动状态与期望的目标状态进行比较(如Git repo中指定的那样)。如果已部署的应用程序的活动状态偏离了目标状态,则认为是OutOfSync。Argo CD报告和可视化这些差异,同时提供了方法,可以自动或手动将活动状态同步回所需的目标状态。在Git repo中对所需目标状态所做的任何修改都可以自动应用并反映到指定的目标环境中。 Argo CD就处在如下位置: image.png 它的优势总结如下: 应用定义、配置和环境信息是声明式的,并且可以进行版本控制; 应用部署和生命周期管理是全自动化的,是可审计的,清晰易懂; Argo CD是一个独立的部署工具,支持对多个环境、多个Kubernetes集群上的应用进行统一部署和管理 实践 前提:有一个可用的Kubernetes集群。 实验环境: kubernetes:1.17.2 argo cd:latest 安装Argo CD 安装很简单,不过在实际使用中需要对数据进行持久化。 我这里直接使用官方文档的安装命令: kubectlcreatenamespaceargocdkubectlapply-nargocd-fhttps://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml 执行成功后会在argocd的namespace下创建如下资源。 #kubectlgetall-nargocdNAMEREADYSTATUSRESTARTSAGEpod/argocd-application-controller-01/1Running016hpod/argocd-dex-server-74d9998fdb-mvpmh1/1Running016hpod/argocd-redis-59dbdbb8f9-msxrp1/1Running016hpod/argocd-repo-server-599bdc7cf5-ccv8l1/1Running016hpod/argocd-server-576b4c7ff4-cnp9d1/1Running016hNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGEservice/argocd-dex-serverClusterIP10.105.217.139<none>5556/TCP,5557/TCP,5558/TCP16hservice/argocd-metricsClusterIP10.97.116.36<none>8082/TCP16hservice/argocd-redisClusterIP10.105.63.34<none>6379/TCP16hservice/argocd-repo-serverClusterIP10.111.153.131<none>8081/TCP,8084/TCP16hservice/argocd-serverClusterIP10.105.229.250<none>80/TCP,443/TCP16hservice/argocd-server-metricsClusterIP10.104.8.45<none>8083/TCP16hNAMEREADYUP-TO-DATEAVAILABLEAGEdeployment.apps/argocd-dex-server1/11116hdeployment.apps/argocd-redis1/11116hdeployment.apps/argocd-repo-server1/11116hdeployment.apps/argocd-server1/11116hNAMEDESIREDCURRENTREADYAGEreplicaset.apps/argocd-dex-server-74d9998fdb11116hreplicaset.apps/argocd-redis-59dbdbb8f911116hreplicaset.apps/argocd-repo-server-599bdc7cf511116hreplicaset.apps/argocd-server-576b4c7ff411116hNAMEREADYAGEstatefulset.apps/argocd-application-controller1/116h 访问Argo server的方式有两种: 通过web ui 使用argocd 客户端工具 我这里直接使用web ui进行管理。 通过kubectl edit -n argocd svc argocd-server将service的type类型改为NodePort。改完后通过以下命令查看端口: #kubectlgetsvc-nargocdNAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGEargocd-dex-serverClusterIP10.105.217.139<none>5556/TCP,5557/TCP,5558/TCP17hargocd-metricsClusterIP10.97.116.36<none>8082/TCP17hargocd-redisClusterIP10.105.63.34<none>6379/TCP17hargocd-repo-serverClusterIP10.111.153.131<none>8081/TCP,8084/TCP17hargocd-serverNodePort10.105.229.250<none>80:32109/TCP,443:30149/TCP17hargocd-server-metricsClusterIP10.104.8.45<none>8083/TCP17h 然后通过http://IP:32109访问页面,如下: image.png 登录账号为admin,密码通过以下命令获取。 kubectlgetpods-nargocd-lapp.kubernetes.io/name=argocd-server-oname|cut-d'/'-f2 然后进入如下界面。 image.png 创建应用 这里仅仅是为了测试argo,所以并没有做ci部分。 我在gitlab上准备了一个仓库,仓库里的文件很简单,如下: image.png 其中manifests下就是一个deployment文件,内容如下: apiVersion:apps/v1kind:Deploymentmetadata:labels:app:devops-argocd-testname:devops-argocd-testnamespace:defaultspec:minReadySeconds:60progressDeadlineSeconds:600replicas:1revisionHistoryLimit:10selector:matchLabels:app:devops-argocd-testtemplate:metadata:labels:app:devops-argocd-testspec:containers:-name:devops-argocd-testimage:registry.cn-hangzhou.aliyuncs.com/rookieops/argocd-test-app:v1imagePullPolicy:Alwaysports:-containerPort:8080name:tcp-8080protocol:TCP---apiVersion:v1kind:Servicemetadata:labels:app:devops-argocd-testname:devops-argocd-testnamespace:defaultspec:ports:-name:tcp-8080port:8080protocol:TCPtargetPort:8080selector:app:devops-argocd-testsessionAffinity:Nonetype:NodePort 现在我们在Argo里创建应用,步骤如下: (1)添加仓库地址,Settings → Repositories,点击 Connect Repo using HTTPS 按钮: image.png 填入以下信息。 image.png 验证通过后显示如下: image.png (2)创建应用 image.png image.png 创建完成后如下所示: image.png 由于我设置的是手动SYNC,所以需要点一下下面的SYNC进行同步。 然后可以看到状态都变成正常。 image.png 这时候我们在集群里可以看到创建了v1版本的应用了。 #kubectlgetpod|grepdevops-argocd-testdevops-argocd-test-7f5fdd9fcf-xbzmp1/1Running0118s#kubectlgetsvc|grepdevops-argocd-testdevops-argocd-testNodePort10.97.159.140<none>8080:31980/TCP2m6s 这时候访问应用,如下: image.png 配置变更 接下来我手动进行配置变更,修改manifests下的deploymeny.yaml文件中的镜像为v2版本,如下: image.png 然后提交到仓库。 这是到ArgoCD中可以看到状态变成了OutOfSync image.png 这时候再手动sync一下,直到状态都变正常。再访问上面的应用。 image.png image.png 可以看到应用已经更新部署了。 我们可以看到整个应用的关系状态,如下: image.png 还可以看到部署历史。 image.png 也可以通过这个界面进行回滚。 image.png 不过这个回滚并不会回滚gitlab上的代码哈。 我上面设置的是手动,你可以设置为自动,自己动手测试一番吧。 官方文档:https://argoproj.github.io/argo-cd/#features 进群请扫码加青牛踏雪 本文分享自微信公众号 - Kubernetes技术栈(k8stech)。如有侵权,请联系 support@oschina.cn 删除。本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

优秀的个人博客,低调大师

GitOps入门与实践:如何集成Git和K8S

也许你之前听说过GitOps,但是对其并不了解。在本文中,我将对其进行简单介绍,它其实是一个应用程序开发和管理中的一个术语,其核心思想是将应用系统的声明性基础架构和应用程序存放在Git的版本控制库中。我们将介绍GitOps是什么,它将如何影响组织以及如何与Kubernetes保持同步。 什么是GitOps GitOps是一种实现持续交付的模型,利用Git开发工具对云原生应用程序进行操作和管理。当将应用程序部署到Kubernetes时,Git应该是唯一的事实来源。当开发人员更改应用程序时,Git将自动把它们push到Kubernetes进行部署。而且,如果Kubernetes内的运行状态发生变化但与Git内的状态不一致,则它们会从Git内恢复到已知状态。 GitOps与CI/CD:它们之间有什么联系? GitOps和CI/CD是十分重要的工作伙伴。CI/CD可以让开发人员持续迭代、开发和部署应用程序。而迭代通常通过一个Git配置仓库进行(尽管也会有其他配置仓库)。在部署/交付阶段,构建的基于容器的应用程序被“push”到Kubernetes进行部署。GitOps会通过Kubernetes使用“pull”的方法来增强CI/CD模型,从而将运维层面带入部署/交付中。 但是,如果有人更改了Kubernetes集群中运行的某些内容,会发生什么?我们将使用Git作为声明性部署工具的主要事实来源,并利用其他工具在出现差异时向我们发出警报。此外,通过利用可以识别运行状态和声明状态之间差异的工具,Kubernetes可以修复为已知/声明的运行状态。 注意:持续集成和持续开发是互补但独立的过程。在理想状态下,GitOps会将批处理规模拆分为单件流程,每次只处理一个单元。但是,由于CI和CD流程发生在不同的组中,因此组织之间的流程可能会有所不同。 GitOps和应用程序生命周期 让我们从应用程序生命周期的视角来看一下GitOps的作用。在典型的生命周期中,应用程序会经历多个状态,包括: 代码 构建 创建镜像 测试 发布 而使用GitOps,这些状态将会扩展为: 部署 在Git仓库中监控更改 日志更改和事件 发生更改时发出警报,并于现有的监控/告警系统集成 更新 在GitOps操作模型下,当应用程序发布时,Kubernetes需要确保其按预期运行。同时,Kubernetes通过确保其稳定性和可用性来管理应用程序的运维工作。如果一个开发人员通过Git更改了该应用程序,Kubernetes将会接受声明并根据需要应用它。 GitOps带来了什么? GitOps为应用程序提供一个操作模型,它可以确保Git提供一个框架来统一应用程序的运行、操作和持续开发。 作为CI/CD流水线的一部分,GitOps为应用程序构建/交付与运行它的位置之间提供了粘合剂。 在Kubernetes平台中,Git为应用程序的开发和运维提供了唯一的事实来源。 应用程序交付和平台管理都是声明式的,同时还能通过Git进行版本控制 Git可以控制回滚、升级以及更改 开发人员不需要知道如何操作运维平台(如Kubernetes),无需了解复杂的部署交付流程,仅需使用熟悉的工具发布新功能即可。极大提升开发者体验。 Git控制并修证差异或“漂移” GitOps利用审核、监控以及回滚功能来增加应用程序发布的可靠性和稳定性 最后,尽管在GitOps模式下还有很多工作要做,但是GitOps、DevOps以及现有CI/CD模式之间存在十分明显的协同作用。GitOps提供了一种用于将应用程序交付到Kubernetes平台的模型,该模型确保了Git是唯一的事实来源并且充分利用Kubernetes平台上的功能。但值得注意的是,GitOps不能替代工具。恰恰相反,GitOps通过声明性的流程和工具来强化流程、提高其成熟度并帮助团队交付应用程序。 GitOps实践:FluxCD Demo FluxCD(或Flux)是一个很棒的工具,它可以将Git和Kubernetes集成起来。Flux本质上是一个Kubernetes Operator,这意味着,你作为一个管理员可以将其安装到Kubernetes 以管理Git和原生Kubernetes之间的集成。 在Kubernetes中,Operator是Kubernetes原生平台的扩展,是一种自定义资源的模式,该自定义资源主要用于管理应用程序及其组件。这意味着,在Kubernetes内部Operator的帮助下,所需状态(如运行状态)将不断检查和调整以符合Git仓库声明的内容。Flux可以集成到你现有的CI/CD工具集中,以进行其他工作流程、权限批准和审核。在Kubernetes中,Flux会监控你通过配置声明的Git仓库是否发生更改,并且如果 Kubernetes Pod上在本地发生了不应发生的更改,Flux将会把Kubernetes更新到所需的运行状态。请记住,Git是事实来源。Flux Operator会检测到这一点,并将正在运行的配置更改回声明的状态。 以下demo,我将会展示如何安装和实现Flux。 前期准备 你将需要: 一个Docker Hub镜像仓库,你可以将Flaskapp docker镜像上传到此处 一个Git Repo并连接它,然后你可以在整个演示过程中根据需要用你的设置替换“< >”中的任何内容 具体步骤 安装Kubernetes 安装并配置fluxctl,Flux部署的原生安装程序 配置Flux以连接到Git Repo 在Git Repo中升级deployment manifest 升级容器镜像并同步 配置漂移(drift)并同步 你可以使用以下配置进行测试或演示。它包括Flask应用程序的Docker file以及Kubernetes deployment/配置文件。在演示中,你会需要它们,此外你还可以将它们上传到你指定的Git仓库中。 Docker File FROM python:3 RUN pip install flask RUN mkdir -p /corp/app WORKDIR /corp/app COPY main.py . ENV FLASK_APP=/corp/app/main.py ENV APP_NAME=MyApp.DevOps ENV APP_VERSION=v1.0.0 CMD ["flask", "run", "--host=127.0.0.1"] main.py Python 脚本文件 import os from flask import Flask app = Flask(__name__) @app.route('/') def index(): appname = os.environ['APP_NAME'] appversion = os.environ['APP_VERSION'] response = "%s - %s.%s\n" %('Hello World', appname, appversion) return response Kubernetes Deployment文件 apiVersion: v1 kind: Namespace metadata: name: my-demo --- apiVersion: apps/v1 kind: Deployment metadata: name: fluxdemo namespace: my-demo annotations: flux.weave.works/tag.flask: glob:develop-v* flux.weave.works/automated: 'true' labels: role: fluxdemo env: demo app: flux spec: replicas: 1 selector: matchLabels: role: fluxdemo template: metadata: labels: role: fluxdemo spec: containers: - name: nginx image: nginx:1.16-perl imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 volumeMounts: - name: nginx-proxy-config mountPath: /etc/nginx/conf.d/default.conf subPath: nginx.conf - name: flask image: docker.io/<your docker repo>/flaskapp:develop-v1.8.0 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 5000 env: - name: APP_NAME value: myfluxdemo.K8s.GitOps - name: APP_VERSION value: v1.0.5 volumes: - name: nginx-proxy-config configMap: name: nginx-conf --- apiVersion: v1 kind: ConfigMap metadata: name: nginx-conf namespace: my-demo data: nginx.conf: |- #CODE1.0: #add the nginx.conf configuration - this will be referenced within the deployment.yaml server { listen 80; server_name localhost; location / { proxy_pass http://localhost:5000/; proxy_set_header Host "localhost"; } } 安装Flux 安装Fluxctl https://docs.fluxcd.io/en/1.18.0/references/fluxctl.html 安装Fluxcd https://docs.fluxcd.io/en/1.18.0/tutorials/get-started.html 为Repo配置Flux 创建一个命名空间 kubectl create ns <namespace> export FLUX_FORWARD_NAMESPACE= <namespace> fluxctl list-workloads 安装Fluxcd以建立与你的Git Repo的连接 export GHUSER="" export REPO="gitops-demo" export NS="flux" fluxctl install \ --git-user=${GHUSER} \ --git-email=${GHUSER}@users.noreply.github.com \ --git-url=git@github.com: Image download failed. {REPO} \ --namespace=${NS} | kubectl apply -f - 创建SSH密钥以添加到Github仓库 在你的terminal中输入以下命令,以获取下一步所需的密钥: fluxctl identity 打开Github,导航到安装Fluxcd时添加的仓库,转到设置-部署密钥,单击【添加部署密钥】,为其指定title,选中【允许write access】,粘贴公共密钥,然后单击【添加密钥】。 在Git Repo中升级Deployment Manifest 打开你的Git Repo,里面应该有deployment.yaml文件,向下滑动直到如下所示部分,然后更改APP_VERSION号码 env: - name: APP_NAME value: myfluxdemo.K8s.GitOps - name: APP_VERSION value: v1.0.5 保存并Commit更改到你的Repo。 Flux将在5分钟之内升级你的deployment 要从localhost进行测试,请在Kubernetes中使用“Port-forward”命令: kubectl get pods -n copy the pod name kubectl port-forward 8080:80 -n 打开其他terminal: curl -s -i http://localhost:8080 升级容器镜像并同步 现在让我们对Docker镜像进行修改并将其上传到我们的Docker Hub镜像仓库中。为此,我们将修改flaskapp目录中的main.py文件。 升级main.py文件。将Hello World更改为其他内容 response = "%s - %s.%s\n" %('Flux World', appname, appversion) 创建一个新的Docker文件并上传到Docker(以及另一个增量版本号)。 等待5分钟,Flux将会自动部署新镜像 配置漂移并同步 现在,我们来测试一下手动更改正在运行的配置会发生什么。 kubectl scale deployment/fluxdemo --replicas=4 -n 现在,我们花几分钟来看看pod并观察发生了什么。我们将会在短时间内(5分钟以内)看到其他的pod,此外我们还将看到许多pod终止。因此,Flux已使配置恢复到当前在Git中保留的已声明的部署状态。 kubectl get po -n --watch 重新运行相同的命令,并且你会看到目前仅有一个正在运行的pod。 别忘了清理和移除deployment和Git连接(如果你想移除它)。否则,你需要开始添加更多的仓库并继续进行构建。 总 结 本文中我们简单介绍了GitOps概念、它与CI/CD的关系以及它对应用程序的生命周期的改变。最后我们还demo了GitOps中的一个小工具Flux,它可以帮助把Kubernetes和Git集成起来,从而优化CI/CD流程。 本文仅仅是一个GitOps的引子,希望你可以通过它更好地入门GitOps,进而提升你的开发部署体验。

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册