K8s如何实现服务发现与配置管理

简介: K8s在实现负载均衡与配置管理上的原理是咋样的呢?

K8s如何实现服务注册与发现

  我们一直在说K8s具备服务发现以及配置管理的能力,K8s是如何实现服务的注册与发现,然后如何做到服务的转发、实现负载均衡的。

  其实服务在K8s中,也定义了一种资源:Service,Service,顾名思义是一个服务,什么样的服务呢?它是定义了一个服务的多种 pod 的逻辑合集以及一种访问 pod 的策略。

service 的类型有四种:

  • ExternalName:创建一个 DNS 别名指向 service name,这样可以防止 service name 发生变化,但需要配合 DNS 插件使用。
  • NodePort:基于 ClusterIp,用于为集群外部访问 Service 后面 Pod 提供访问接入端口。
  • LoadBalancer:它是基于 NodePort。
  • ClusterIP:默认的类型,用于为集群内 Pod 访问时,提供的固定访问地址,默认是自动分配地址,可使用 ClusterIP 关键字指定固定 IP。

从上面讲的 Service,我们可以看到一种场景:所有的微服务在一个局域网内,或者说在一个 K8s 集群下,那么可以通过 Service 用于集群内 Pod 的访问,这就是 Service 默认的一种类型 ClusterIP,ClusterIP 这种的默认会自动分配地址。

  那么问题来了,既然可以通过上面的 ClusterIp 来实现集群内部的服务访问,那么如何注册服务呢?其实 K8s 并没有引入任何的注册中心,使用的就是 K8s 的 kube-dns 组件。然后 K8s 将 Service 的名称当做域名注册到 kube-dns 中,每一个Service在kube-dns中都有一条DNS记录,同时,如果有服务的ip更换,kube-dns自动会同步,对服务来说是不需要改动的。通过 Service 的名称就可以访问其提供的服务。那么问题又来了,如果一个服务的 pod 对应有多个,那么如何实现 LB?其实,最终通过 kube-proxy,实现负载均衡。也就是说kube-dns通过 servicename 找到指定 clusterIP,kube-proxy完成通过 clusterIP 到 PodIP 的过程。

说到这,我们来看下 Service 的服务发现与负载均衡的策略,Service 负载分发策略有两种:

  • RoundRobin:轮询模式,即轮询将请求转发到后端的各个 pod 上,其为默认模式。
  • SessionAffinity:基于客户端 IP 地址进行会话保持的模式,类似 IP Hash 的方式,来实现服务的负载均衡。

下面写一个很简单的例子:

apiVersion: v1
kind: Service
metadata:
  name: cas-server-service
  namespace: default
spec:
  ports:
  - name: cas-server01
    port: 2000
    targetPort: cas-server01
  selector:
    app: cas-server

可以看到执行 kubectl apply -f service.yaml 后:

root@ubuntu:~$ kubectl get svc
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)              AGE
admin-web-service             ClusterIP   10.16.129.24    <none>        2001/TCP              84d
cas-server-service            ClusterIP   10.16.230.167   <none>        2000/TCP               67d
cloud-admin-service-service   ClusterIP   10.16.25.178    <none>        1001/TCP         190d

这样,我们可以看到默认的类型是 ClusterIP,用于为集群内 Pod 访问时,可以先通过域名来解析到多个服务地址信息,然后再通过 LB 策略来选择其中一个作为请求的对象。

K8s 如何处理微服务中常用的配置

  接下来我们看看微服务中场景的居多配置该如何来利用K8s实现统一管理。其实,在K8s中,定义了一种资源:ConfigMap,我们来看看这种资源。

  ConfigMap,看到这个名字可以理解:它是用于保存配置信息的键值对,可以用来保存单个属性,也可以保存配置文件。对于一些非敏感的信息,比如应用的配置信息,则可以使用 ConfigMap。

创建一个 ConfigMap 有多种方式如下。

  1. key-value 字符串创建
kubectl create configmap test-config --from-literal=baseDir=/usr

  上面的命令创建了一个名为 test-config,拥有一条 key 为 baseDir,value 为 "/usr" 的键值对数据。

  1. 根据 yml 描述文件创建
apiVersion: v1
kind: ConfigMap
metadata:
  name: test-config
data:
  baseDir: /usr

也可以这样,创建一个 yml 文件,选择不同的环境配置不同的信息:

kind: ConfigMap
apiVersion: v1
metadata:
  name: cas-server
data:
  application.yaml: |-
    greeting:
      message: Say Hello to the World
    ---
    spring:
      profiles: dev
    greeting:
      message: Say Hello to the Dev
    spring:
      profiles: test
    greeting:
      message: Say Hello to the Test
    spring:
      profiles: prod
    greeting:
      message: Say Hello to the Prod

注意点:

  • ConfigMap 必须在 Pod 使用其之前创建。
  • Pod 只能使用同一个命名空间的 ConfigMap。

  当然,还有其他更多用途,具体可以参考官网(https://kubernetes.io/zh/docs/concepts/configuration/configmap/)

前面讲述了几种创建ConfigMap的方式,其中有一种在 Java 中常常用到:通过创建 yml 文件来实现配置管理。比如:

kind: ConfigMap
apiVersion: v1
metadata:
  name: cas-server
data:
  application.yaml: |-
    greeting:
      message: Say Hello to the World
    ---
    spring:
      profiles: dev
    greeting:
      message: Say Hello to the Dev
    spring:
      profiles: test
    greeting:
      message: Say Hello to the Test
    spring:
      profiles: prod
    greeting:
      message: Say Hello to the Prod

  这样,当我们启动容器时,通过 --spring.profiles.active=dev 来指定当前容器的活跃环境,即可获取 ConfigMap 中对应的配置。是不是感觉跟 Java 中的 Config 配置多个环境的配置有点类似呢?但是,我们不用那么复杂,这些统统可以交给 K8s 来处理。只需要你启动这一命令即可,是不是很简单?

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
5月前
|
Kubernetes Nacos 微服务
k8s教程(pod篇)-配置管理
k8s教程(pod篇)-配置管理
84 0
|
8月前
|
Kubernetes 负载均衡 安全
K8S | Service服务发现
在K8S集群中是通过Pod组件来部署应用服务,Deployment组件实现Pod编排管理,Service组件实现应用的访问;
192 0
|
9月前
|
域名解析 Kubernetes 网络协议
【k8s】kubernetes的基于coredns的服务发现机制
【k8s】kubernetes的基于coredns的服务发现机制
130 0
|
9月前
|
运维 负载均衡 Kubernetes
基于 Stork 和 Quarkus 扩展 Kubernetes 服务发现
在传统的单体架构中,应用程序已经通过静态主机名、IP 地址和端口知道后端服务的存在位置。IT运维团队为服务可靠性和系统稳定性维护静态配置。自从微服务开始在分布式网络系统中运行以来,其维护发生了显著变化。之所以发生这种变化,是因为微服务需要与多个后端服务进行通信,以提高负载均衡和服务弹性。
84 0
|
9月前
|
Kubernetes 网络协议 Cloud Native
K8S生态之服务发现解析
当前,云原生生态已经成为全球各大厂商以及企业尤其是互联网企业技术选型、场景推广的一个重要参考标准。云原生所代表的技术已经逐渐成为大家的共识,从一个虚无缥缈的概念逐渐演化成众多参与者的下一个技术战略储备。自然而言,承载业务需求的应用架构就会提及到微服务生态体系,以及其中最重要的分布式协作模式——“Service Discovery”,即:服务发现。
149 0
|
存储 Kubernetes Docker
Docker 与 K8S学习笔记(十九)—— Pod的配置管理
我们在部署应用时常常会考虑将应用程序与配置文件相分离,这样可以使应用程序更好的复用,并且通过不同配置也能实现更灵活的功能。将应用制作成镜像后,我们可以在启动容器时通过环境变量或挂载文件的方式注入,但是在面临大规模容器集群的场景下就显得力不从心了,因此我们可以使用ConfigMap进行统一配置。 一、
300 0
|
tengine 自然语言处理 Kubernetes
Nacos2.0的K8s服务发现生态应用及规划
Nacos 是阿里巴巴于 2018 年开源的注册中心及配置中心产品,帮助用户的分布式微服务应用进行服务发现和配置管理功能。随着 Nacos2.0 版本的发布,在性能和扩展性上取得较大突破后,社区开始考虑如何提供更加云原生方向的功能和用法。本次分享主要介绍 Nacos 在 2.0 版本在Kubernetes 环境下对服务发现生态的应用探索成果及后续探索方向的规划。
Nacos2.0的K8s服务发现生态应用及规划
|
缓存 Kubernetes 监控
Dubbo3 基于 Kubernetes Informer 的服务发现原理解析
## List/Watch 机制介绍 List/Watch机制是Kubernetes中实现集群控制模块最核心的设计之一,它采用统一的异步消息处理机制,保证了消息的实时性、可靠性、顺序性和性能等,为声明式风格的API奠定了良好的基础。 `list`是调用`list API`获取资源列表,基于`HTTP`短链接实现。 `watch`则是调用`watch API`监听资源变更事件,基于`HTTP
435 0
Dubbo3 基于 Kubernetes Informer 的服务发现原理解析
|
存储 Kubernetes 安全
【云原生 | 从零开始学Kubernetes】二十七、配置管理中心Secret和rbac授权
上面我们学习的 Configmap 一般是用来存放明文数据的,如配置文件,对于一些敏感数据,如密码、私钥等数据时,要用 secret 类型。
180 0
|
存储 Kubernetes Cloud Native
【云原生 | 从零开始学Kubernetes】二十六、配置管理中心configmap
Configmap 是 k8s 中的资源对象,用于保存非机密性的配置的,数据可以用 key/value 键值对的形式保存,也可通过文件的形式保存。
329 0
【云原生 | 从零开始学Kubernetes】二十六、配置管理中心configmap

推荐镜像

更多