K8S核心插件-coredns服务
K8S核心插件-coredns服务
目录
- K8S核心插件-coredns服务
- 1 coredns用途
- 1.1 为什么需要服务发现
- 2 coredns的部署
- 2.1 获取coredns的docker镜像
- 2.2 创建coredns的资源配置清单
- 2.2.1 rbac集群权限清单
- 2.2.2 configmap配置清单
- 2.2.3 depoly控制器清单
- 2.2.4 service资源清单
- 2.3 创建资源并验证
- 2.3.1 验证服务能够访问`
- 2.3.2 创建资源:
- 2.3.3. 查看创建情况:
- 2.3.4 使用dig测试解析
- 2.3.5 创建一个service资源来验证
1 coredns用途
coredns github地址
coredns都做了什么:Kubernetes内部域名解析原理、弊端及优化方式
coredns在K8S中的用途,主要是用作服务发现,也就是服务(应用)之间相互定位的过程。
1.1 为什么需要服务发现
在K8S集群中,POD有以下特性:
- 服务动态性强
容器在k8s中迁移会导致POD的IP地址变化 - 更新发布频繁
版本迭代快,新旧POD的IP地址会不同 - 支持自动伸缩
大促或流量高峰需要动态伸缩,IP地址会动态增减
service资源解决POD服务发现:
为了解决pod地址变化的问题,需要部署service资源,用service资源代理后端pod,通过暴露service资源的固定地址(集群IP),来解决以上POD资源变化产生的IP变动问题
那service资源的服务发现呢?
service资源提供了一个不变的集群IP供外部访问,但
- IP地址毕竟难以记忆
- service资源可能也会被销毁和创建
- 能不能将service资源名称和service暴露的集群网络IP对于
- 类似域名与IP关系,则只需记服务名就能自动匹配服务IP
- 岂不就达到了service服务的自动发现
在k8s中,coredns就是为了解决以上问题。
2 coredns的部署
从coredns开始,我们使用声明式向k8s中交付容器的方式,来部署服务
2.1 获取coredns的docker镜像
以下操作可以在任意节点上完成,推荐在7.200
上做,因为接下来制作coredns的k8s配置清单也是在运维主机7.200
上创建后,再到node节点上应用
docker pull docker.io/coredns/coredns:1.6.1 docker tag coredns:1.6.1 harbor.zq.com/public/coredns:v1.6.1 docker push harbor.zq.com/public/coredns:v1.6.1
2.2 创建coredns的资源配置清单
以下资源配置清单,都是参考官网改出来的
mkdir -p /data/k8s-yaml/coredns
2.2.1 rbac集群权限清单
cat >/data/k8s-yaml/coredns/rbac.yaml <<EOF apiVersion: v1 kind: ServiceAccount metadata:name: corednsnamespace: kube-systemlabels:kubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata:labels:kubernetes.io/bootstrapping: rbac-defaultsaddonmanager.kubernetes.io/mode: Reconcilename: system:coredns rules: - apiGroups:- ""resources:- endpoints- services- pods- namespacesverbs:- list- watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:annotations:rbac.authorization.kubernetes.io/autoupdate: "true"labels:kubernetes.io/bootstrapping: rbac-defaultsaddonmanager.kubernetes.io/mode: EnsureExistsname: system:coredns roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:coredns subjects: - kind: ServiceAccountname: corednsnamespace: kube-system EOF
2.2.2 configmap配置清单
cat >/data/k8s-yaml/coredns/cm.yaml <<EOF apiVersion: v1 kind: ConfigMap metadata:name: corednsnamespace: kube-system data:Corefile: |.:53 {errorsloghealthreadykubernetes cluster.local 192.168.0.0/16 #service资源cluster地址forward . 10.4.7.11 #上级DNS地址cache 30loopreloadloadbalance} EOF
2.2.3 depoly控制器清单
cat >/data/k8s-yaml/coredns/dp.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata:name: corednsnamespace: kube-systemlabels:k8s-app: corednskubernetes.io/name: "CoreDNS" spec:replicas: 1selector:matchLabels:k8s-app: corednstemplate:metadata:labels:k8s-app: corednsspec:priorityClassName: system-cluster-criticalserviceAccountName: corednscontainers:- name: corednsimage: harbor.zq.com/public/coredns:v1.6.1args:- -conf- /etc/coredns/CorefilevolumeMounts:- name: config-volumemountPath: /etc/corednsports:- containerPort: 53name: dnsprotocol: UDP- containerPort: 53name: dns-tcpprotocol: TCP- containerPort: 9153name: metricsprotocol: TCPlivenessProbe:httpGet:path: /healthport: 8080scheme: HTTPinitialDelaySeconds: 60timeoutSeconds: 5successThreshold: 1failureThreshold: 5dnsPolicy: Defaultvolumes:- name: config-volumeconfigMap:name: corednsitems:- key: Corefilepath: Corefile EOF
2.2.4 service资源清单
cat >/data/k8s-yaml/coredns/svc.yaml <<EOF apiVersion: v1 kind: Service metadata:name: corednsnamespace: kube-systemlabels:k8s-app: corednskubernetes.io/cluster-service: "true"kubernetes.io/name: "CoreDNS" spec:selector:k8s-app: corednsclusterIP: 192.168.0.2ports:- name: dnsport: 53protocol: UDP- name: dns-tcpport: 53- name: metricsport: 9153protocol: TCP EOF
2.3 创建资源并验证
在任意NODE节点执行配置都可以,先
2.3.1 验证服务能够访问`
[root@hdss7-21 ~]# dig -t A harbor.zq.com +short 10.4.7.200
2.3.2 创建资源:
kubectl create -f http://k8s-yaml.zq.com/coredns/rbac.yaml kubectl create -f http://k8s-yaml.zq.com/coredns/cm.yaml kubectl create -f http://k8s-yaml.zq.com/coredns/dp.yaml kubectl create -f http://k8s-yaml.zq.com/coredns/svc.yaml
2.3.3. 查看创建情况:
kubectl get all -n kube-system kubectl get svc -o wide -n kube-system dig -t A www.baidu.com @192.168.0.2 +short
2.3.4 使用dig测试解析
[root@hdss7-21 ~]# dig -t A www.baidu.com @192.168.0.2 +short www.a.shifen.com. 39.156.66.18 39.156.66.14 [root@hdss7-21 ~]# dig -t A harbor.zq.com @192.168.0.2 +short 10.4.7.200
coredns已经能解析外网域名了,因为coredns的配置中,写了他的上级DNS为10.4.7.11
,如果它自己解析不出来域名,会通过递归查询一级级查找
但coredns我们不是用来做外网解析的,而是用来做service名和serviceIP的解析
2.3.5 创建一个service资源来验证
先查看kube-public
名称空间有没有pod
~]# kubectl get pod -n kube-public No resources found. # 之前我调试问题已经清理了所有的POD,所以没有
如果没有则先创建pod
kubectl create deployment nginx-dp --image=harbor.zq.com/public/nginx:v1.17.9 -n kube-public ~]# kubectl get deployments -n kube-public NAME READY UP-TO-DATE AVAILABLE AGE nginx-dp 1/1 1 1 35s ~]# kubectl get pod -n kube-public NAME READY STATUS RESTARTS AGE nginx-dp-568f8dc55-rxvx2 1/1 Running 0 56s
给pod创建一个service
kubectl expose deployment nginx-dp --port=80 -n kube-public ~]# kubectl -n kube-public get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-dp ClusterIP 192.168.63.255 <none> 80/TCP 11s
验证是否可以解析
~]# dig -t A nginx-dp @192.168.0.2 +short # 发现无返回数据,难道解析不了 # 其实是需要完整域名:服务名.名称空间.svc.cluster.local. ~]# dig -t A nginx-dp.kube-public.svc.cluster.local. @192.168.0.2 +short 192.168.63.255
可以看到我们没有手动添加任何解析记录,我们nginx-dp的service资源的IP,已经被解析了:
进入到pod内部再次验证
~]# kubectl -n kube-public exec -it nginx-dp-568f8dc55-rxvx2 /bin/bash -qjwmz:/# apt update && apt install curl -qjwmz:/# ping nginx-dp PING nginx-dp.kube-public.svc.cluster.local (192.168.191.232): 56 data bytes 64 bytes from 192.168.191.232: icmp_seq=0 ttl=64 time=0.184 ms 64 bytes from 192.168.191.232: icmp_seq=1 ttl=64 time=0.225 ms
为什么在容器中不用加全域名?
-qjwmz:/# cat /etc/resolv.conf nameserver 192.168.0.2 search kube-public.svc.cluster.local svc.cluster.local cluster.local host.com options ndots:5
当我进入到pod内部以后,会发现我们的dns地址是我们的coredns地址,以及搜索域中已经添加了搜索域:kube-public.svc.cluster.local
我们解决了在集群内部解析的问题,要想在集群外部访问我们的服务还需要igerss
服务暴露功能
现在,我们已经解决了在集群内部解析的问题,但是我们怎么做到在集群外部访问我们的服务呢?
K8S核心插件-coredns服务相关推荐
- 【好文收藏】K8S集群部署CoreDNS服务
K8S集群部署CoreDNS服务 k8s集群中的应用通常是通过ingress实现微服务发布的,前文介绍过在K8S集群中使用traefik实现服务的自动发布,其实现方式是traefik通过集群的DNS服 ...
- k8s kubernetes 核心组件 CoreDNS 域名解析服务 学习总结
k8s kubernetes 核心组件 CoreDNS 域名解析服务 学习总结 大纲 基础概念 CoreDNS下载与安装 DNS资源记录配置说明 CoreDNS配置文件Corefile语法总结 Cor ...
- 理论+实操:K8S搭建dns内部服务与控制器controlls五种模式
文章目录 故障排查 一:控制器的类型 一: pod与控制器之间的关系 二:deployment 2.1 deployment概述 2.1 演示 2.1.1 编写yaml文件 2.1.2 创建pod 2 ...
- 浅谈k8s cni 插件
目前不论是个人还是企业,在使用k8s时,都会采用CNI作为集群网络方案实现的规范. 在早先的k8s版本中,kubelet代码里提供了networkPlugin,networkPlugin是一组接口,实 ...
- k8s核心资源之service四层负载均衡器代理(六)
目录 1. k8s四层负载均衡-service 1.1 四层负载均衡Service:概念.原理 1.1.1 为什么要有Service? 1.1.2 Service概述 1.1.3 Service工作原 ...
- k8s 系列之 CoreDNS 解读
k8s 系列之 CoreDNS CoreDNS工作原理 kuberntes 中的 pod 基于 service 域名解析后,再负载均衡分发到 service 后端的各个 pod 服务中,如果没有 DN ...
- k8s业务迁移与服务部署实践
K8s运行业务的优势 部署上线业务流程 情景模拟: 业务部署上线是每个运维都需要面对的问题,接下来分别从传统运维和k8s运维角度,梳理操作流程: 传统运维: 安装操作系统 初始化系统配置(安全策略.时 ...
- K8s网络插件Flannel,Calico
文章目录 一.K8s网络插件flannel与calico 1. k8s网络解决方案 容器虚拟化网络方案 基于隧道 基于路由 2. CNI(容器网络接口) flannel与calico 选型比较 3. ...
- k8s kafka集群 连接不上_图解 K8s 核心概念和术语
我第一次接触容器编排调度工具是 Docker 自家的 Docker Swarm,主要解决当时公司内部业务项目部署繁琐的问题,我记得当时项目实现容器化之后,花在项目部署运维的时间大大减少了,当时觉得这玩 ...
最新文章
- 电脑DIY之内存传输标准
- C++程序员学Python:C与Python进行交互
- mysql正则提取字符串_mysql字符串查找截取与正则表达式的联合应用
- html的属性与css的属性,HTML的属性和css基础
- Angular jasmine returnValue方法的实现原理
- 高度焦虑、凌晨出没、空中飞人,这些竟是 IT 大佬的日常!
- Android MediaCodec硬编码H264文件(四)
- 2021-05-15 SqlServer面试题 通用篇
- 最新高德地图使用——申请key、显示地图
- 腾讯校招 针对找工作的小伙伴们
- 世界十大经典爱情故事
- burst传输 - 理解
- Solr与MongoDB集成,实时增量索引[转]
- numpy数组array的shape属性-1维、2维···
- 【CSS—美化网页元素】
- MATLAB 神经网络训练参数解释
- Linux ethtool 命令
- 用 php 编写输入一个整数n(n>1),计算并输出1+2+3+…+n的值
- 2022年美容师(初级)考试题模拟考试平台操作
- 如何更好地利用谷歌浏览器?——快捷键和一些个人使用技巧