1. 问题现象

公司内部SaaS产品运行在阿里云kubernetes环境，使用阿里云[标准托管版]进行部署使用，[标准托管版] 版就是用户只需要自己运维k8s node节点，master节点由阿里云进行维护，当k8s环境部署完成之后，将公司生产业务部署后发现部分业务模块无法解析到阿里云OSS自定义的对象存储域名，导致业务出现异常；

业务模块是可以通过域名访问其他业务模块及互联网域名的，而且业务模块配置了SNAT都是可以访问互联网的

1.1. 问题分析

公司域名后缀为*.oneprocloud.com，统一方便管理，所有的资源均使用子域名

在阿里云我们采用2个4核16G的云主机作为Node节点进行部署公司生产业务，因为有部分业务模块需要访问阿里云OSS对象存储进行访问数据，OSS对象存储我们设置了自定义域名，为了方便访问，短域名地址为"downloads.oneprocloud.com"，并配置了智能DNS解析，办公笔记本可以解析短域名地址，即判定自定义短域名生效，可以正常使用

在k8s业务模块内进行如下测试：

  • nslookup进行解析互联网地址，是可以正常解析的
# www.baidu.com可以正常解析
[root@jumpserver-7596dc7dcb-lcs4n ~]# nslookup www.baidu.com
Server:         10.0.0.10
Address:        10.0.0.10#53

Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com.
Name:   www.a.shifen.com
Address: 220.181.38.149
Name:   www.a.shifen.com
Address: 220.181.38.150
  • nslookup解析自定义阿里云OSS域名地址，发现无法进行解析
# www.baidu.com可以正常解析
[root@jumpserver-7596dc7dcb-lcs4n ~]# nslookup downloads.oneprocloud
Server:         10.0.0.10
Address:        10.0.0.10#53

Server:         10.0.0.10
Address:        10.0.0.10#53

Non-authoritative answer:
*** Can't find downloads.oneprocloud.com: No answer

经过以上测试，分析为在k8s集群内部，都是去找coredns 10.0.0.10 DNS进行解析域名，www.baidu.com 就可以解析，但是我们自定义的downloads.oneprocloud.com就无法解析，这个现象很诡异，我们接着查看coredns的配置：

查看k8s集群的coredns配置：

# 查看kube-system下的coredns configmap
[root@jumpserver-7596dc7dcb-lcs4n ~]# kubectl get configmap -n kube-system
NAME                                 DATA   AGE
ack-cluster-profile                  6      16d
acr-configuration                    5      16d
coredns                              1      16d
extension-apiserver-authentication   6      16d
kube-flannel-cfg                     2      16d
kube-proxy-worker                    2      16d
kubeadm-config                       1      16d
kubelet-config-1.11                  1      16d
kubelet-config-1.12                  1      16d
kubelet-config-1.18                  1      16d
kubernetes-dashboard-settings        1      13d

# 查看coredns的configmap的定义是如何的，其实就是看看dns的配置
[root@jumpserver-7596dc7dcb-lcs4n ~]# kubectl get configmap -n kube-system coredns -o yaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready

        kubernetes oneprocloud.com in-addr.arpa ip6.arpa {  # 在Corefile配置文件我们发现dns的域配置的oneprocloud.com

          pods verified
          upstream
          fallthrough in-addr.arpa ip6.arpa
          ttl 30
        }
        autopath @kubernetes
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  annotations: # 这边的配置信息也是 oneprocloud.com域名
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"Corefile":".:53 {\n    errors\n    health {\n       lameduck 5s\n    }\n    ready\n\n    kubernetes oneprocloud.com in-addr.arpa ip6.arpa {\n\n      pods verified\n      upstream\n      fallthrough in-addr.arpa ip6.arpa\n      ttl 30\n    }\n    autopath @kubernetes\n    prometheus :9153\n    forward . /etc/resolv.conf\n    cache 30\n    loop\n    reload\n    loadbalance\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"creationTimestamp":"2021-01-11T10:33:07Z","managedFields":[{"apiVersion":"v1","fieldsType":"FieldsV1","fieldsV1":{"f:data":{".":{},"f:Corefile":{}},"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}}},"manager":"rc","operation":"Update","time":"2021-01-11T10:33:07Z"}],"name":"coredns","namespace":"kube-system","resourceVersion":"24861979","selfLink":"/api/v1/namespaces/kube-system/configmaps/coredns","uid":"7891c2a7-bff4-4f81-abaa-d06abb0ddf35"}}
  creationTimestamp: "2021-01-11T10:33:07Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data: {}
      f:metadata:
        f:annotations: {}
    manager: rc
    operation: Update
    time: "2021-01-11T10:33:07Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:Corefile: {}
      f:metadata:
        f:annotations:
          f:kubectl.kubernetes.io/last-applied-configuration: {}
    manager: kubectl
    operation: Update
    time: "2021-01-27T10:22:30Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "145403500"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 7891c2a7-bff4-4f81-abaa-d06abb0ddf35

问题分析结果如下：

通过以上信息查看，其实oneprocloud.com是coredns的解析域，这个应该是在阿里云上部署k8s的时候设置的，这个域名会在k8s集群内部进行生效，作用是什么那，比如两个业务模块之间需要访问的话，我定义了模块的services，我就可以通过xxx.oneprocloud.com这个域名去访问其他业务模块是实现域名注册，xxx就为子域名，只能在k8s集群内部访问，其实我们定义的downloads.oneprocloud.com也是 xxx的子域名，但是并没有在k8s集群内部定义这种services，所以解析的时候，coredns认为这是同一个域内部的，然后去解析发现解析不到，但是为什么www.baidu.com域名可以访问那，是因为非oneprocloud.com后缀域，coredns正常集群外域名如果coredns解析不了，会去coredns的ecs配置的nameserver解析。所以才会出现www.baidu.com可以解析，downloads.oneprocloud.com解析不了的现象；

2. 问题处理方法

针对此问题，个人能力有限，不确定是否有更好的解决办法，例如设置tag文件，写明同一个域的其他子域名，如果coredns在内部集群解析不到的话，先去查询此tag文件，然后再进行找外部dns进行解析，只是个人想法

以上问题的发生，因为k8s环境已经部署完成，业务也已经部署了，总不能重新部署吧，那这个代价也太大了，有没有办法修改coredns配置，让其更改一个另外的解析域。

我这边大概想到2个方案：

  • 第一个方案

k8s集群内部解析域不变，变动外部自定义OSS对象域名，更换成其他的后缀域名

  • 第二个方案

改变k8s集群内部解析域，外部自定义OSS对象域名保持不变

根据以上两个方案分析，其实第二个方案还是比较合适的，因为公司内部的注册域这个肯定不可能变化的，我总不能再注册一个其他的后缀域吧，这个维护和代价成本也比较大，k8s集群内部域其实就是一个内部的，只要服务能够直接可以解析就可以了，所以第二个方案比较合适，第二个方案的处理办法继续往下

2.1. 修改k8s内部解析域名

如何按照我们的解决方案，第二个方案更改k8s集群内部coredns配置，需要如下两个操作步骤：

  1. 修改集群的coredns configmap文件
  2. 修改所有k8s集群node节点的kubelet服务的配置文件，并重启kubelet服务
  3. 重建业务pod服务

2.1.1. 修改集群coredns cm文件

  • 查看集群coredns cm配置文件并保存
[root@jumpserver-7596dc7dcb-lcs4n ~]# kubectl get configmap -n kube-system coredns -o yaml > coredns-configmap.yaml
  • 修改coredns cm配置 （以下红色标记的两处域名，修改成其他自定义）
[root@jumpserver-7596dc7dcb-lcs4n ~]# vim coredns-configmap.yaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready

        kubernetes **cluster.local** in-addr.arpa ip6.arpa {

          pods verified
          upstream
          fallthrough in-addr.arpa ip6.arpa
          ttl 30
        }
        autopath @kubernetes
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"Corefile":".:53 {\n    errors\n    health {\n       lameduck 5s\n    }\n    ready\n\n    kubernetes **oneprocloud.com** in-addr.arpa ip6.arpa {\n\n      pods verified\n      upstream\n      fallthrough in-addr.arpa ip6.arpa\n      ttl 30\n    }\n    autopath @kubernetes\n    prometheus :9153\n    forward . /etc/resolv.conf\n    cache 30\n    loop\n    reload\n    loadbalance\n}\n"},"kind":"ConfigMap","metadata":{"annotations":{},"creationTimestamp":"2021-01-11T10:33:07Z","managedFields":[{"apiVersion":"v1","fieldsType":"FieldsV1","fieldsV1":{"f:data":{".":{},"f:Corefile":{}},"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}}},"manager":"rc","operation":"Update","time":"2021-01-11T10:33:07Z"}],"name":"coredns","namespace":"kube-system","resourceVersion":"24861979","selfLink":"/api/v1/namespaces/kube-system/configmaps/coredns","uid":"7891c2a7-bff4-4f81-abaa-d06abb0ddf35"}}
  creationTimestamp: "2021-01-11T10:33:07Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data: {}
      f:metadata:
        f:annotations: {}
    manager: rc
    operation: Update
    time: "2021-01-11T10:33:07Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        f:Corefile: {}
      f:metadata:
        f:annotations:
          f:kubectl.kubernetes.io/last-applied-configuration: {}
    manager: kubectl
    operation: Update
    time: "2021-01-27T10:22:30Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "145403500"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 7891c2a7-bff4-4f81-abaa-d06abb0ddf35
  • 重新进行应用
[root@jumpserver-7596dc7dcb-lcs4n ~]# kubectl apply -f coredns-configmap.yaml

2.1.2. 修改所有k8s集群node节点配置文件

这里需要注意是所有的节点kubelet配置文件都需要更改并重启服务，包含以后横向扩展的node节点，一定要记得也要同步修改节点配置文件，例如：当前2个node节点更改了，后续增加1个多个节点，同样也需要重复以下步骤，不然还是无法进行解析

  • 修改配置文件/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

修改配置文件中标红的内容，修改成自定义的域名，要和coredns configmap修改的域名保持一致

[Service]
Environment="KUBELET_EXTRA_ARGS=--node-labels=HM-SAAS-Lable=Production"
EnvironmentFile=-/etc/kubernetes/kubelet-customized-args.conf
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_SYSTEM_PODS_ARGS=--max-pods 64 --pod-max-pids 16384 --pod-manifest-path=/etc/kubernetes/manifests"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --dynamic-config-dir=/etc/kubernetes/kubelet-config --v=3"
Environment="KUBELET_DNS_ARGS=--enable-controller-attach-detach=true --cluster-dns=10.0.0.10 --pod-infra-container-image=registry-vpc.cn-beijing.aliyuncs.com/acs/pause:3.2 --enable-load-reader --cluster-domain=**cluster.local** --cloud-provider=external --hostname-override=cn-beijing.192.168.1.156 --provider-id=cn-beijing.i-2ze6kkewztaauih0izyr"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --authentication-token-webhook=true --anonymous-auth=false --client-ca-file=/etc/kubernetes/pki/ca.crt"
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Environment="KUBELET_CERTIFICATE_ARGS=--tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256 --tls-cert-file=/var/lib/kubelet/pki/kubelet.crt --tls-private-key-file=/var/lib/kubelet/pki/kubelet.key --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS $KUBELET_CUSTOMIZED_ARGS
  • 重新加载配置文件并重启kubelet服务
[root@iZ2ze6kkewztaauih0izyrZ ~]# systemctl daemon-reload
[root@iZ2ze6kkewztaauih0izyrZ ~]# systemctl restart kubelet

2.1.3. 重建业务pod服务

将所有的业务pod重建，不然无法使用最新的coredns配置进行服务注册发现

# 按照业务pod重建方式
# kubectl replace --force -f xxxx.yaml

2.1.4. 验证业务域名访问

  • 验证corends cm配置在这里插入图片描述

  • 验证域名解析

通过nslookup进行解析测试，发现已经可以正常解析外部域名在这里插入图片描述

3. 问题分析结论

在k8s集群内部设置了域，例如*.oneprocloud.com，那么oneprocloud.com就会被认为是集群内的域名，只向coredns进行域名解析，如果你在互联网也设置了同样后缀的DNS域名解析，在coredns内部是解析不了的，需配置配置其他外部域进行访问，正常集群外域名如果coredns解析不了，例如：*.baidu.com 那么coredns会去coredns所在ecs节点配置的nameserver进行解析。

# docker # linux # kubernetes # 运维
Logo
Cloudpods

开源、云原生的融合云平台

更多推荐

面向未来的 IT 基础设施管理架构——融合云（Unified IaaS）

随着数字化时代的到来，IT系统已成为人类社会正常运转不可或缺的组成部分。不远的未来，智能制造，5G和人工智能等技术将成为推动生产力发展的重要引擎，人类社会将面临前所未有的全面彻底的数字化浪潮。IT基础设施作为IT系统运行的平台和载体，是实现数字化的基石。在这场数字化浪潮中，企业必须积极拥抱云计算技术，采用符合技术发展趋势、面向未来的IT基础构架，才能在未来的竞争中赢得先机。 一、云计算历经十余年

avatar Cloudpods

Cloudpods负载均衡的功能介绍

作者:周有松 今天的内容会从以下几个方面展开： 负载均衡产品简介。主要介绍负载均衡作为一个云上产品，它的功能模型是怎样的，日常使用中会遇到的业务词汇负载均衡的功能与典型应用场景。这部分主要结合业务词汇，对负载均衡服务中常见的一些功能选项进行介绍，并举例介绍一些典型的应用场景最后，我们做一下总结，讨论一下负载均衡产品相比传统方式的优点 一、产品简介​ 1. 以NGINX为例​ 提到负载均衡，我们以

avatar Cloudpods

使用Linux vfio将Nvidia GPU透传给QEMU虚拟机

Linux 上虚拟机 GPU 透传需要使用 vfio 的方式。主要是因为在 vfio 方式下对虚拟设备的权限和 DMA 隔离上做的更好。但是这么做也有个缺点，这个物理设备在主机和其他虚拟机都不能使用了。 qemu 直接使用物理设备本身命令行是很简单的，关键在于事先在主机上对系统、内核和物理设备的一些配置。 单纯从 qemu 的命令行来看，其实和普通虚拟机启动就差了最后那个-device的选项。这

avatar Cloudpods