Kubernetes-Service介绍(二)-服务发现

本文涉及的产品
.cn 域名,1个 12个月
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: Kubernetes提供两种客户端以固定方式获取后端访问地址的方式:环境变量和DNS方式。

一、前言


本篇是Kubernetes第九篇,大家一定要把环境搭建起来,看是解决不了问题的,必须实战。

Kubernetes系列文章:
  1. Kubernetes介绍
  2. Kubernetes环境搭建
  3. Kubernetes-kubectl介绍
  4. Kubernetes-Pod介绍(-)
  5. Kubernetes-Pod介绍(二)-生命周期
  6. Kubernetes-Pod介绍(三)-Pod调度
  7. Kubernetes-Pod介绍(四)-Deployment
  8. Kubernetes-Service介绍(一)-基本概念


二、服务发现


Kubernetes提供两种客户端以固定方式获取后端访问地址的方式:环境变量和DNS方式。

环境变量

该实验以上文中的nginx-deployment.yaml和nginx-service.yaml为基础;

  1. 新建一个Pod资源,文件名为nginx-pod.yaml;
apiVersion: v1
kind: Pod
metadata:
  name: nginx-deployment
spec:
  containers:
  - name: nginx
    image: nginx:latest
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 80
  1. 启动该资源;
kubectl apply -f nginx-pod.yaml
  1. 进入容器内部,查看系统的环境变量;
#进入容器内部
kubectl exec -it nginx-deployment -- /bin/bash
#查看环境变量
env | grep NGINX

image.png

  1. 通过环境变量访问服务信息;
curl http://${NGINX_SERVICE_SERVICE_HOST}

image.png

DNS方式
  1. 通过DNS解析方式在容器内部访问;
curl http://nginx-service.default.svc.cluster.local

image.png

相比于环境变量来说,DNS域名格式的Service名称提供的稳定、不变的访问地址,可以简化客户端的应用配置,是Kubernetes推荐的方式。当Service以DNS形式进行访问的时候,需要在集群中存在一个DNS服务器来完成域名到ClusterIP的地址解析工作,kubeadm在初始化的时候已经完kube-dns的安装,这个里要注意一个问题,就是使用busybox解析Service时候,最新版本是有问题的,我采用了1.28.3版本,对于服务中心中是否安装kube-dns可以通过以下方式检查:

#检查deployment
kubectl get deployment --namespace=kube-system
#检查service
kubectl get services --namespace=kube-system

Service在Kubernetes中遵守DNS命名规范,Service的DNS域名表示方法为servicename.namespace.svc.clusterdomain,其中servicename为服务名称,namespace为所在的名空间,clusterdomain为Kubernetes中集群设置的域名后缀,此外如果Service定义中设置了名称,该端口会拥有一个DNS域名,在DNS服务器中保存格式为:_portname._protocol.servicename.namespace.svc.clusterdomain,其值为端口号的数值。

三、Pod的DNS相关特征


Pod作为集群中提供服务的实体,也可以设置DNS域名,Kubernetes为Pod使用的DNS策略提供很多种方式。

Pod的DNS

对于Pod来说,Kubernetes会为其设置一个pod-ip.namespace.pod.cluster-domain格式的DNS域名,其中Pod的IP需要使用-替换.,我们通过nslookup来证明一下;

  1. 查看Pod的IP信息,我们使用niginx-deployment的Pod为案例;
kubectl get pod -o wide

image.png

  1. 使用nslookup进行验证;
kubectl exec busybox -- nslookup 10-100-1-103.default.pod.cluster.local

image.png

对于Deployment和Daement类型的创建的Pod来说,Kubernetes会为每个Pod设置一个DNS域名,格式为pod-ip.deployment-name/daement-name.namespace.svc.cluster-domain,Pod的IP也需要使用-替换.

为Pod设置hostname和subdomain

当前,创建Pod时其主机名取自Pod的metadata.name,在定义Pod的yaml文件中包含一个可选的 hostname 字段,可以用来指定Pod的主机名。 当这个字段被设置时,它将优先于Pod的名字成为该 Pod 的主机名。此外还有一个字段subdomain 字段,可以用来指定 Pod的子域名。

  1. 删除所有Pod;
kubectl delete -f nginx-pod.yaml
  1. 创建busybox-headless-service.yaml文件,这里Headless Service与Pod子域名保持一致,这样子DNS服务器才会自动创建响应的DNS记录;
apiVersion: v1
kind: Service
metadata:
  name: default-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
  - name: foo # 实际上不需要指定端口号
    port: 1234
    targetPort: 1234
  1. 创建nginx-pod.yaml文件;
apiVersion: v1
kind: Pod
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  hostname: busybox-1
  subdomain: default-subdomain
  containers:
  - image: busybox:1.28.3
    command:
      - sleep
      - "3600"
    name: busybox
  1. 创建资源;
kubectl apply -f busybox-headless-service.yaml
kubectl apply -f busybox-pod1.yaml
  1. 进入Pod检查DNS是否写入,其他Pod就可以通过busybox-1.default-subdomain.default.svc.cluster.local来访问该Pod;
kubectl exec -it busybox1 -- /bin/sh
cat /etc/hosts

image.png

Pod的DNS策略

Kubernetes可以通过Pod中dnsPolicy属性指定DNS相关策略,目前支持以下四种策略:

  1. Default: 继承Pod所在的节点的域名解析设置;
  2. ClusterFirst: 优先使用Kubernetes提供的DNS服务(CoreDNS),将无法解析域名转发到系统配置的DNS服务器;
  3. ClusterFirstWithHostNet:适用于以hostNetWork方式运行的Pod;
  4. None:忽略Kubernetes提供的DNS配置,采用自定义的配置方式;
Pod自定义DNS配置

Kubernetes可以通过Pod的dnsConfig属性来自定义DNS相关配置,同时必须指定dnsPolicy为None。

自定义DNS可以在dnsConfig指定以下属性:

nameservers: 用于域名解析DNS服务列表,最多可以设置3个,当 Pod的dnsPolicy设置为none时, 列表必须至少包含一个 IP 地址。配置的nameserver列表与系统自动设置的nameserver自动合并去重;

searches: 用于域名搜索的DNS域名后缀,最多设置6个,也会与系统自动设置的search列表合并去重;

options:配置其他可选的DNS参数,以name或者name/value的形式表示,系统也会自动设置option列表合并去重;

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
7天前
|
Kubernetes 网络协议 Nacos
OpenAI 宕机思考丨Kubernetes 复杂度带来的服务发现系统的风险和应对措施
Kubernetes 体系基于 DNS 的服务发现为开发者提供了很大的便利,但其高度复杂的架构往往带来更高的稳定性风险。以 Nacos 为代表的独立服务发现系统架构简单,在 Kubernetes 中选择独立服务发现系统可以帮助增强业务可靠性、可伸缩性、性能及可维护性,对于规模大、增长快、稳定性要求高的业务来说是一个较理想的服务发现方案。希望大家都能找到适合自己业务的服务发现系统。
|
6月前
|
负载均衡 Kubernetes 算法
K8s服务发现与负载均衡的技术探索
【7月更文挑战第15天】K8s通过Service资源对象和kube-proxy组件实现了高效、灵活的服务发现和负载均衡机制。通过合理选择Service类型、优化kube-proxy配置以及使用Ingress进行高级路由,可以确保应用在K8s集群中高效、可靠地运行。随着云原生技术的不断发展,K8s的服务发现和负载均衡机制也将不断完善和优化,为更多场景提供强大的支持。
|
tengine 自然语言处理 Kubernetes
Nacos2.0的K8s服务发现生态应用及规划
Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品,帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布,在性能和扩展性上取得较大突破后,社区开始考虑如何提供更加云原生方向的功能和用法。本次分享主要介绍 Nacos 在 2.0 版本在Kubernetes 环境下对服务发现生态的应用探索成果及后续探索方向的规划。
Nacos2.0的K8s服务发现生态应用及规划
|
存储 缓存 Kubernetes
Dubbo-kubernetes 基于 Informer 服务发现优化之路
优化为 Informer 后,Dubbo 的服务发现不用每次直接调用 kube-apiserver,减小了 kube-apiserver 的压力,也大大减少了响应时间,助力 Dubbo 从传统架构迁移到 Kubernetes 中。
221 10
Dubbo-kubernetes 基于 Informer 服务发现优化之路
|
Kubernetes 负载均衡 安全
K8S | Service服务发现
在K8S集群中是通过Pod组件来部署应用服务,Deployment组件实现Pod编排管理,Service组件实现应用的访问;
281 0
|
域名解析 Kubernetes 网络协议
【k8s】kubernetes的基于coredns的服务发现机制
【k8s】kubernetes的基于coredns的服务发现机制
276 0
|
运维 负载均衡 Kubernetes
基于 Stork 和 Quarkus 扩展 Kubernetes 服务发现
在传统的单体架构中,应用程序已经通过静态主机名、IP 地址和端口知道后端服务的存在位置。IT运维团队为服务可靠性和系统稳定性维护静态配置。自从微服务开始在分布式网络系统中运行以来,其维护发生了显著变化。之所以发生这种变化,是因为微服务需要与多个后端服务进行通信,以提高负载均衡和服务弹性。
150 0
|
Kubernetes 网络协议 Cloud Native
K8S生态之服务发现解析
当前,云原生生态已经成为全球各大厂商以及企业尤其是互联网企业技术选型、场景推广的一个重要参考标准。云原生所代表的技术已经逐渐成为大家的共识,从一个虚无缥缈的概念逐渐演化成众多参与者的下一个技术战略储备。自然而言,承载业务需求的应用架构就会提及到微服务生态体系,以及其中最重要的分布式协作模式——“Service Discovery”,即:服务发现。
217 0
|
存储 缓存 Kubernetes
Dubbo-kubernetes 基于Informer服务发现优化之路
在 Kubernetes(简称 K8S,一个可移植容器的编排管理工具)体系中,etcd 存储集群的数据信息,kube-apiserver作为统一入口,任何对数据的操作都必须经过 kube-apiserver。因此 Dubbo 想要以 Kubernetes 作为注册中心,必须调用 kube-apiserver 获取服务地址列表,那是以什么样的机制保持信息的可靠性、实时性、顺序性、高性能呢?答案就是基于List/Watch的Informer组件。
Dubbo-kubernetes 基于Informer服务发现优化之路
|
域名解析 缓存 Prometheus
Kubernetes 集群 DNS 服务发现原理
本文介绍 Kubernetes 集群中 DNS 服务发现原理。
14559 0