1: docker容器时间与宿主机时间不一致问题
详细描述：
docker容器时间与宿主机时间不一致问题
解题思路：
对比容器和宿主机的时区是否一致；
原因分析：
一般情况下主要由于宿主机和容器的时区不一致导致
解决步骤：
修改容器内的时区：
docker exec -it <容器名> ／bin／bash
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
docker restart <容器名>2: 在docker环境内部，当使用CURL来访问局域网内的另外一台服务器的时候会出现域名午饭解析饿的情况
详细描述：
在docker环境内部，当使用CURL来访问局域网内的另外一台服务器的时候会出现域名午饭解析饿的情况；类似的错误如下：
cURL error 6: Could not resolve host
Couldnt resolve host。 The given remote host was not resolved
解题思路：
查看docker内部的hosts配置情况
原因分析：
Docker容器无法解析局域网内的域名，就算本地主机的hosts配置了域名映射也是不行的
Docker环境不同于wamp或者Xampp，对于局域网内的域名解析，Docker需要到docker内部配置hosts文件
解决步骤：
进入docker容器后，在docker文件中，配置域名解析；
1: docker exec -it my_web /bin/bash
2: vi /etc/hosts
3:添加域名解析规则3: K8s dns主机名无法正常解析，coredns服务一直处于CrashLoopBackOff状态
详细描述：
K8s dns主机名无法正常解析，coredns服务一直处于CrashLoopBackOff状态
kubectl log coredns
发现log中有错误
plugin/loop: Loop (127.0.0.1:44222 -> :53) detected for zone
解题思路：
coredns主要和resolv.conf打交道，查询resolv中是否形成相应的环造成错误
原因分析：
coredns会读取系统中/etc/resov.conf中的nameserver内容，如果里面存在本地回环如127.0.0.1或者127.0.0.53那么就容易造成死循环
解决步骤：
临时修改方案： vim /etc/resolv.conf 将nameserver 临时修改为114.114.114.114
若临时手动修改，每次重启都会被覆盖的话，则进行如下的操作：
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo apt install unbound
sudo rm -rf /etc/resolv.conf
sudo vim /etc/NetworkManager/NetworkManager.conf
在［main］下添加
dns=unbound
将dns服务替换为unbound
reboot 服务器
之后：
kubectl edit deployment coredns -n kube-system
将replicates改为0，从而停止已经启动的coredns pod
再将replicates 改为2， 这样会触发coredns重新读取系统配置，此时服务的状态为Running4: docker 内部ping 不通www.baidu.com
详细描述：
1: 手动启动一个centos容器
2: ping www.baidu.com 不通
3: 将容器中的/etc/resolve.conf 中加入k8s集群外的dns
nameserver 10.128.142.149 ＃集群外dns地址
nameserver 172.20.0.2 ＃集群内的coredns服务地址
4: ping www.baidu.com 可以ping通
5: 进入容器中安装dig命令 yum install bind-utils; dig www.baidu.com 返回的地址是集群外DNS服务
那么将集群外的dns去掉，再执行dig www.163.com or dig www.qq.com则会出现不通的情况
解题思路：
无
原因分析：
无
解决步骤：
Ubuntu系统中： worker节点中查看br_netfilter这个模块是不是启用，如果没有则启用modprobe br_netfilter
Centos系统中：查看/proc/sys/net/bridge/bridge-nf-call-iptables的值是不是1，如果不是执 行echo ‘1’> /proc/sys/net/bridge/bridge-nf-call-iptables
这样问题就解决了5:coreDns解析域名失败以及内网转发出现5s卡顿
详细描述：
coreDns解析域名失败以及内网转发出现5s卡顿
解题思路：
内网转发卡顿思路：
1: 排查目标服务是否出现卡顿现象
2:排查网关和nginx是否出现转发卡顿
3:绕过Dns解析，直接ip访问，无卡顿现象
外网域名解析失败思路：
1:对请求域名进行抓包分析
2：分析抓包结果
原因分析：
内网卡顿问题，CoreDns在解析域名时候会尝试获取ipv6的地址，在默认的情况下解析ipv6地址会出现卡顿的现象
k8s集群内部要访问外网需要从CoreDns统一获取DNS解析，在默认情况下使用forward模式；
forward模式和proxy模式区别：
forward： 转发域名查询到上游DNS服务器
proxy：转发特定的域名查询到多个其他DNS服务器,同时提供多个DNS服务器的负载均衡功能
解决步骤：
内网卡顿现象解决：
修改coredns的配置增加ipv6解析加速
template ANY AAAA｛
rcode NXDOMAIN
｝
外网无法访问的解决：
修改coredns的配置，将forward换成proxy6:Pod内无法ping通外网域名，访问外网IP、K8s内部域名或者IP均正常
详细描述：
Pod内无法ping通外网域名，访问外网IP、K8s内部域名或者IP均正常
解题思路：
无
原因分析：
K8s在创建Pod的时候会把宿主机的/etc/resolv.conf里的内容拷贝到Pod同文件中， 如 果/etc/resov.conf里面写的配置不正确，则Pod无法解析外网的域名。
解决步骤：
ls -ls /etc/resov.conf 查看可以看出是个软链接，链接到/etc/systemd/resolved.conf；
那么如何修改该文件？
主要步骤：删除该软链接，然后手动创建该文件