devops

前 这一篇也是基础设施的部署记录。cert-manager用于集群的 ingress https 证书的管理。 他可以自动的完成 证书的签发，然后配合 ingressroute就可以很简单的进行证书的部署。更加适用于K8s 的体系。对比于 nginxproxy manager 这种，虽然也是使用 acme 来进行 https 的证书签发，其无法与集群进行很好的结合。以及证书的管理需要存储在硬盘上，无法很好的兼容 K8 的模式。 完成部署后，可以直接在内网使用 https访问，提升整体的系统美感。后续使用 proxy 进行服务暴露时候也更加的优雅。 这篇记录实际部署以及操作流程。 Cert-manager安装 安装部份直接使用 helm 来进行配置。之前对 helm 还有些抵触，觉得降低了自己的定制性。但是逐渐发现通过 values 也提供了 很好的定制性。而且由于资源是打包的，有更好的整体性。换个方式也可以理解为 K8s 下的 apt apiVersion: v1 kind: Namespace metadata: name: cert-manager 安装过程很简单，导入 charts，安装 CRD，然后安装整个 chart helm repo add jetstack https://charts.jetstack.io helm repo update kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.crds.yaml helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.13.2 --values=values.yaml 这里一些参数需要自定义，values 的内容如下。因为 CRD 已经手动安装，所以fasle，这里的PodDNS 配置比较重要，因为需要让他使用 我们的 resolver 的DNS 直接进行DNS 查询，如果使用 本地网路的 LDNS 可能会出现查询缓存，甚至是 TXT 记录查询不到的问题。...

前 Traefik 不仅仅是作为ingress 这么简单，它在实现了标准的 Ingress API 的同时。所带来CRD才是最重要的功能。 我们通过 kubectl api-resources 可以看到当前的API资源，其中可以看到 Traefik 提供的有： ingressroutes traefik.containo.us/v1alpha1 true IngressRoute ingressroutetcps traefik.containo.us/v1alpha1 true IngressRouteTCP ingressrouteudps traefik.containo.us/v1alpha1 true IngressRouteUDP middlewares traefik.containo.us/v1alpha1 true Middleware middlewaretcps traefik.containo.us/v1alpha1 true MiddlewareTCP serverstransports traefik.containo.us/v1alpha1 true ServersTransport tlsoptions traefik.containo.us/v1alpha1 true TLSOption tlsstores traefik.containo.us/v1alpha1 true TLSStore traefikservices traefik.containo.us/v1alpha1 true TraefikService 所以这里我们使用Traefik 提供的CRD来实现对于ingress 的高级应用。 概念 这里选取这次要使用的 CRD来进行简单的讲解 ingressroutes IngressRoute 和 k8s 本身的 ingress 对比，给我们提供了更强大的功能，这里把配置文件贴出来就可以直接的看到区别。简单的理解一个是进一步控制 Traefik 的功能，一个是单纯的配置 ingress 的转发。CRD多了更多的选项 ： middlewares entryPoints TraefikService apiVersion: traefik....

前 在构思一个项目，把一些需要经常变更的云上配置通过一种可持续的方式管理起来。最终实现的目的是云上用到的配置都可以通过代码来进行定义。不需要手动的控制台点击，同时可以加强IAAS的使用能力 这里使用的技术栈有 Github Action Terrafoem cf-terraforming` The part of Terraform 安装 cf-terraforming 安装 cf-terraforming 用于导出现有的配置生成Terraform 的文件。 brew tap cloudflare/cloudflare brew install cloudflare/cloudflare/cf-terraforming 一路绿灯完成安装。没有什么问题 导出现有的Cloudflare tf内容以及状态导入 Terraform对资源是声明式的管理，存在状态文件和 配置文件两部份。状态是自动生成的我们不需要进行编辑。但是在导入资源的时候也需要进行同步的导入。 使用 cf-terraforming 进行tf文件生成， 这里的 API token 在控制台进行生成 export CLOUDFLARE_API_TOKEN='<SECRET>' export CLOUDFLARE_ZONE_ID='<SECRET>' cf-terraforming generate \ --resource-type "cloudflare_record" \ --zone $CLOUDFLARE_ZONE_ID > cloudflare_record.tf 完成命令后，就得到了母亲该Zone下的所有的域名record，看其中的一条是下面的样子，这样就完成了声明文件部份的导入 resource "cloudflare_record" "terraform_managed_resource_17cf372edb00f60acd922085ccfe4992" { name = "78cbbfaad12b999e" proxied = false ttl = 1 type = "A" value = "43.153.xxx.xxx" zone_id = "secret" } 下面的步骤是进行 状态文件的导入。通过 cf-tf 工具自动生成导入资源的 import 命令。然后使用 terraform 来进行资源的状态导入...

前 在学习阶段，应该减少一键部署类的东西的使用的。但是因为这个算是一个SOP。所以就直接拿来用了。 在部署之后会大概分析下整个yaml的项目。 prometheus-operator/kube-prometheus 部署过程 部署过程非常的简单，仓库Clone 下来直接进行 apply 就可以了。 kubectl apply --server-side -f manifests/setup kubectl wait \ --for condition=Established \ --all CustomResourceDefinition \ --namespace=monitoring kubectl apply -f manifests/ 配置修改

前 k3s部署项目也需要进行持久化存储。但是不希望在节点上进行localpath 的存储。不大优雅且和节点有强相关不利于HA的设计。 所以就需要使用 nfs 的方式来进行持久化的存储。 这里我使用群晖来提供nfs服务偷个懒。使用自建的nfs server 也是可以的。 Workshops 节点准备 需要先在节点上安装nfs-common来提供nfs 的客户端从而有挂载的能力 sudo apt install nfs-common 存储准备 在存储的管理上有两种方法，一个是安装 CSI 使用 NFS 的存储类来进行NFS 的持久化管理。还有一个一种是NFS类型的PV来实现。两种都可以实现NFS挂载为POD 的持久卷。但是第一个种方式对NFS 进行了抽象。不需要在进行更多的配置以及额外的管理。把存储层更加抽象也更符合我们的K8S的思想。这里两种部署的方式都记录一下。 使用存储类（Storagecalss）来进行持久化管理 NFS 的CSI 驱动安装 安装过程十分的简单，参考下面的指引文档 Install NFS CSI driver v4.5.0 version on a kubernetes cluster 直接使用 yaml apply 来进行安装， curl -skSL https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/v4.5.0/deploy/install-driver.sh | bash -s v4.5.0 -- ###### kubectl -n kube-system get pod -o wide -l app=csi-nfs-controller kubectl -n kube-system get pod -o wide -l app=csi-nfs-node NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES csi-nfs-controller-6f5f9cb8f-7n974 4/4 Running 12 (9h ago) 4d10h 192....

前 第N次，和 K3S打上了交道。因为K8S的技术的学习曲线较为陡峭。也因为自己基础不牢。 基础部署都没熟练直攻Helm。 然后导致集群就处于失控状态，从而导致了最终的学习/研究失败。 现在重新捡起来，使用基础的例子一步步的构建K3S homelab体系。 最终的目的是可以把目前所有的 docker-compose 的项目都迁移到K3S下面来。 Workshop 说明 需求背景 因为国内的网络环境问题，拉取Docker的gcr/dockerio 之类的镜像时有失败。而且因为集群的多节点。导致 ImagePullErr 问题时有发生。 所以这里需要建立起一个 在本地提供镜像缓存以及管理功能的 Registry。 选型 官方的Registry镜像中提供了一个 remote_porxy 的配置，可以直接实现对某一个远程仓库的 代理和 缓存功能。 不过这里有一个进行二次打包的版本 yangchuansheng/registry-proxy 把一些配置直接写到了环境变量中去。简化了我们的使用流程。 yangchuansheng/registry-proxy 在有提供 代理服务的 仓库镜像之后，还需要一个管理工具，用来对我们的镜像进行可视化的webui管理。这里找到了下面的那这个项目 Joxit/docker-registry-ui 可以直接进行部署用来Registry的资源管理。 实践过程 持久化存储 因为需要进行镜像的缓存，所以对于拉去的镜像需要进行持久化存储。这里原计划是使用NFS来提供存储，不过这种基础的服务不希望降低系统的整体性。所以就在Master 的节点拓展了磁盘。直接进行磁盘的localpath存储。 多个的镜像代理都是公用的一个PV存储，这样便于管理且不会冲突。下面的yaml就是对这个 PV 的定义 --- apiVersion: v1 kind: PersistentVolume metadata: name: master-local-storage spec: accessModes: - ReadWriteOnce - ReadWriteMany capacity: storage: 15Gi local: path: /data nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: node-role.kubernetes.io/storage operator: In values: - storage persistentVolumeReclaimPolicy: Retain storageClassName: local-path volumeMode: Filesystem 这里需要注意的是两点，其中一个是 persistentVolumeReclaimPolicy...

记录下K3s agent 部署的过程，官网给了简单的Oneclick 的命令，但是实际安装过长中还是遇到了些许的问题。这里就记录一下。 k3s 默认使用 containerd 作为容器运行时, 因为我更熟悉 docker, 所以打算在 k3s 中使用 docker 代替 containerd. 先升级一下系统 apt update apt upgrade -y 在系统中安装 docker, 直接使用 apt 安装 apt install docker.io 然后安装 k3s 的 master 节点 curl -sfL https://get.k3s.io | sh -s - --docker 安装完成后, 从 master 节点上的 /var/lib/rancher/k3s/server/node-token 获取到 token 值. 然后用 token 值安装 node 节点 这里的Server 是已经配置好的hostname，需要网络是可通状态。 curl -sfL https://get.k3s.io | K3S_URL=https://server:6443 K3S_TOKEN=token sh -s - --docker 给 node 节点添加 role，...

前 实践 echo Deploy apiVersion: apps/v1 kind: Deployment metadata: labels: app: echo name: echo spec: replicas: 1 selector: matchLabels: app: echo template: metadata: labels: app: echo spec: containers: - name: echo image: k8s.gcr.io/echoserver:1.10 imagePullPolicy: Always ports: - containerPort: 8080 resources: limits: cpu: 10m memory: 20Mi requests: cpu: 10m memory: 20Mi nodeSelector: network: proxy terminationGracePeriodSeconds: 60 Service apiVersion: v1 kind: Service metadata: labels: app: echo name: echo spec: ports: - name: http port: 80 protocol: TCP targetPort: 8080 selector: app: echo Ingress apiVersion: networking....

前 第N次，和 K3S打上了交道。因为K8S的技术的学习曲线较为陡峭。也因为自己基础不牢。 基础部署都没熟练直攻Helm。 然后导致集群就处于失控状态，从而导致了最终的学习/研究失败。 现在重新捡起来，使用基础的例子一步步的构建K3S homelab体系。 最终的目的是可以把目前所有的 docker-compose 的项目都迁移到K3S下面来。