2020年10月初,Rancher推出了新的版本2.5,本次版本带来了好几项新的功能,以下几点最吸引人:

  • 集成GitOps引擎:Fleet
  • 全新的Dashboard:面向专业用户,特别是大量使用CRD资源的用户,新接口可获取所有CRD可操作
  • 全面集成AWS EKS:可以直接使用Rancher创建与管理EKS集群

但是同时新版Rancher也推荐使用Kubernetes部署以支持更大规模的Kubernetes集群,以往我们常常使用Docker部署,现在虽然也可以继续此种方式,但是确实在使用上,Rancher连接太多集群,经常需要重启,不然用户无法使用,所以就新建K3S集群部署Rancher2.5.1,然后导入一个集群进入的Rancher2.5.1,我们的乌龙问题就就此展开。


架构

我们共有5套Kubernetes集群,分别为:

  • Dev
  • Test
  • Prep
  • Prod
  • Ops

前面4套集群,分别单独部署了ArgoCD,各自管理自身的集群,而最后一个集群Ops,则使用了Dev内的ArgoCD进行管理,ArgoCD添加其他集群的方式比较简单,大致如下:

# 被管理方集群Ops部署argocd
kubectl create ns argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.7.8/manifests/ha/install.yaml

# 管理方集群Dev添加被管理方集群
argocd cluster add $CONTEXT

这里的$CONTEXT对应的是kubeconfig内的内容,Rancher管理的Kubernete都会提供Rancher的kuneconfig文件,文件格式如下:

apiVersion: v1
kind: Config
clusters:
- name: "local"
  cluster:
    server: "https://rancher-k3s.spex.top/k8s/clusters/local"
    certificate-authority-data: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQ\
      VM2Z0F3SUJBZ0lCQURBS0JnZ3Foa2pPUFFRREFqQTdNUnd3R2dZRFZRUUtFeE5rZVc1aGJXbGoKY\
      kdsemRHVnVaWEl0YjNKbk1Sc3dHUVlEVlFRREV4SmtlVzVoYldsamJHbHpkR1Z1WlhJdFkyRXdIa\
      GNOTWpBeApNREk0TURZd09UUXhXaGNOTXpBeE1ESTJNRFl3T1RReFdqQTdNUnd3R2dZRFZRUUtFe\
      E5rZVc1aGJXbGpiR2x6CmRHVnVaWEl0YjNKbk1Sc3dHUVlEVlFRREV4SmtlVzVoYldsamJHbHpkR\
      1Z1WlhJdFkyRXdXVEFUQmdjcWhrak8KUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVJrRDZxcFFOclQ0M\
      WlGT3RCK2FXMTV6OEhzczdCVEJuU0pYSnlLNkRETgp6eWliNFdHdnQ2eHRaU0ZDMzdSNlBqaFBHT\
      0pFaXc3Sko4NEFVd3UvMGpZUm95TXdJVEFPQmdOVkhROEJBZjhFCkJBTUNBcVF3RHdZRFZSMFRBU\
      UgvQkFVd0F3RUIvekFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUVBdTdxVDhocUsKSWd0ZXowQ01jV\
      Tg2VGR3dVNhRzBwb1B5WU9UQ2taVXZEeVFDSUVFTTRwYVF1ZmJsOE50QUU2TkVaOU9XOGZJaQpSd\
      nF2STg1bzBHYkpWeWpiCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0="

users:
- name: "local"
  user:
    token: "kubeconfig-user-lcb7q:npdnt66glvkscqvsc4ckvnjtgdtnbphg4vqbhp52cf862wjflp88j8"

contexts:
- name: "local"
  context:
    user: "local"
    cluster: "local"

current-context: "local"

这里的context.name就是我们的context,argocd在接受到命令后,会从默认的kubeconfig文件中取server与token作为对应的配置项存入secret中。

apiVersion: v1
data:
  config: {"bearerToken": "kubeconfig-user-d8zsc:x76q2d5lmmg8msmchkp4qbg5k5wsvx4sjfpsb6mtt7kjdlmb2zcjd9"}
  name: ops-cluster
  server: "https://rancher-k3s.spex.top/k8s/clusters/xxxxx"
kind: Secret
metadata:
  labels:
    argocd.argoproj.io/secret-type: cluster
  name: ops-cluster
  namespace: argocd
type: Opaque

这里的server是来自于Rancher,所以我们的Ops集群如果更换了Rancher,响应的server与token肯定是变更了,argocd就会失去Ops集群的控制。

正确的做法

先说说正确的做法,正确的做法按照以下步骤新增或修改即可:

  • argocd cluster add 新集群
  • 确认argocd application project的权限,是否可作用于新集群
  • 修改argocd application的destination.server

这样我们的服务就可以完成迁移,而我只做了第一步就发现argocd添加的集群返回的信息不正常,就走岔了,这个后面再说。

1.argocd cluster add 新集群

建议直接新增secret的方式来新增集群,方式argocd cli工具返回报错信息影响判断。

# new-cluster.yaml

apiVersion: v1
data:
  config: {"bearerToken": "kubeconfig-user-d8zsc:x76q2d5lmmg8msmchkp4qbg5k5wsvx4sjfpsb6mtt7kjdlmb2zcjd9"}
  name: new-cluster
  server: "https://rancher-k3s.spex.top/k8s/clusters/new-cluster"
kind: Secret
metadata:
  labels:
    argocd.argoproj.io/secret-type: cluster
  name: new-cluster
  namespace: argocd
type: Opaque

# 导入控制端 dev argocd
kubectl apply -n argocd -f new-cluster.yaml

在刚刚导入集群后,查看所有集群信息,会发现集群状态为Unknow,且返回信息为:Cluster has no application and not being monitored.

这是因为新增的集群内没有部署任何application,是正常的信息。

$ argocd cluster list
SERVER                                             NAME              VERSION  STATUS      MESSAGE
https://rancher-k3s.spex.top/k8s/clusters/new-cluster  ops-cluster           Unknown     Cluster has no application and not being monitored.
https://kubernetes.default.svc                     in-cluster        1.17+    Successful

2.确认argocd project权限

查看AppProjects的权限:

$ kubectl get appprojects -n argocd ops -o yaml

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  creationTimestamp: "2020-07-08T09:45:23Z"
  generation: 3
  name: ops
  namespace: argocd
  resourceVersion: "65005904"
  selfLink: /apis/argoproj.io/v1alpha1/namespaces/argocd/appprojects/ops
  uid: 73ee97af-07c9-4f84-bf00-79e22238acc7
spec:
  description: 'Operation '
  destinations:
  - namespace: '*'
    server: '*'
  orphanedResources:
    warn: false
  sourceRepos:
  - git@git.spex.top:gitops/argocd.git
status: {}

这里可以看到destinations的namespace与server都是通配符,说明我们的项目可以运行在任意的集群下。

如果这里是限定的集群或者命名空间,需要修改为对应的。

3.确认argocd application destination.server

这里拿一个服务举例:

$ cat caravel.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: caravel-ops
  namespace: argocd
spec:
  destination:
    namespace: component
    server: https://rancher-k3s.spex.top/k8s/clusters/old-cluster
  project: ops
  source:
    helm:
      valueFiles:
      - dev-values.yaml
    path: caravel
    repoURL: git@git.spex.top:gitops/argocd.git
    targetRevision: HEAD
  syncPolicy:
    automated:
      prune: false
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

这里可以看到project为ops,刚刚已经确认过此project下的服务可以部署至任意的集群的任意namespace中。

destination.server为old-cluster,我们已经没有这个集群了,现在是new-cluster,修改server的自己为新的集群,然后重新kubectl apply -n argocd -f caravel.yaml 更新。

这里说的old-cluster与new-cluster只是代号,方便理解,在Rancher中是一串随机的字符串。

至此就完成了服务的迁移。

错误的做法

很可惜,上面正确的做法已经在错误的做法的一天后了。

在增加新集群的时候集群状态为Unknow,且返回信息为:Cluster has no application and not being monitored. 的时候,我已经慌了。

按照查找问题的方式验证:

  • Google:无有效信息
  • Github Issue:仅有2条
  • Source Code:无有效信息

现在就剩2条信息了,均为解决,且对应同一个问题,这个Bug在最新的1.7.8中已经修复了,问题很有意思。

在Argocd Ui中操作外部的server信息,如修改ops-cluster的作用namespace后,Argocd Ui后会将修改后的信息保存入secret中,但是同时会丢失config参数,这里保存着的beartoken,就是我们的认证信息,这样此集群则无法管控。

信息如下:https://github.com/argoproj/argo-cd/issues/4405

确认IAM与RBAC

考虑到我们的变量是更换了Rancher,IAM并不会有任何不同,Pass。

RBAC都是使用官方文件安装,理论上都是相同的,经过一波漫长的确认操作后,Pass。

峰回路转

因为Ops Argocd是Dev Argocd管理的,所以本身并没有配置git repository,那就添加。

添加git repository直接添加会报known_hosts的问题,在集群内部署一个alpine pod,添加git repostiory ssh key后ssh连接到集群生成know_hosts后,添加至argocd的 Repository certificates的known_hosts中,然后再添加git repository即可成功了。

然后随便部署了一个服务,成功……集群状态也成功变为Success。

总结

出现这个滑稽的乌龙是因为对argocd的不熟悉引起的,在搜到不到信息的时候其实脑子里在想,也许我发现了bug,也可能是我做了个超级傻的操作,但是很多时候,都是自己的操作引起了问题。

Last modification:November 3rd, 2020 at 05:56 pm