在k8s集群中，服务是运行在Pod中的，Pod的发现和副本间负载均衡是我们面临的问题。我们使用Service解决了负载均衡的问题，但是集群环境中，service经常伴随着ip的变动而变动，得益于kubedns插件，使其可以直接通过域名（service name）进行访问。

1.常见使用场景

在常见集群中经常会出现服务之间彼此通过http或者tcp、RPC的形式进行访问，在kubernetes集群中，pod和pod、service之间的网络是互通的，但是service的ip地址是存储在etcd中，如果创建完成之后，一直使用apply，那么ip不会变化，如果不小心执行了kubectl delete -f yaml，那么service的ip将发生变化，如果此ip被很多服务使用，将会带来灾难性的修改，这时我们可以借助kube-dns解决问题。

2.kubernetes网络模型

一个完整的Kubernetes集群应该包含三层网络，首先第一层是mater和node节点之间的网络，这个网络需要在部署kubernetes集群之前配置完成，第二层网络是pod的网络通过kubenet或者cni插件实现，用于pod之间或者内部的通信，集群中的所有pod均处在同一个网络平面空间内，可以直接通信，第三层网络是Service资源的网络，是一个虚拟网络，用于为Kubernetes集群配置IP地址，但此地址并不配置于任何主机或者容器的网络接口之上，而是通过kubeproxy配置为iptables规则，将发往该地址的所有流量调度至后端的pod之上。

Kubernetes网络中常见四种通信方式

1 同一个pod的内部通信；

2 各个pod彼此通信；

3 pod和service的通信；

4 集群外部流向service的通信。

看到上面这些你就不难理解为什么在yaml中存在port，targetPort，nodePort？

containerPort：一个信息性数据，他只是为集群提供一个可以快速了解相关pod可以访问端口的途径，而且显式指定容器端口，无论你是否指定都不影响其他节点上的客户端pod对其进行访问。

port：服务提供端口，用于kubernetes集群内部服务访问。

targetPort：pod目标端口，如果不设置使用默认port端口，port和nodePort的数据通过这个端口进入到Pod内部，Pod里面的containers的端口映射到这个端口，提供服务。

nodePort：外部用户访问端口

3.kubernetes中如何发现服务

通过如下yaml创建两个nginx服务

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nginx

spec:

  replicas: 1

  selector:

    matchLabels:

      app: nginx

  template:

    metadata:

     labels:

      app: nginx

    spec:

      containers:

      - name: nginx

        image: docker.hub.com/ops/openresty:1.15

        ports:

        - containerPort: 80

通过进入服务内部进行访问nginx服务

kubectl exec nginx-deployment-74fd67c98d-26j9r -it /bin/bash


[root@nginx-deployment-74fd67c98d-26j9r /]# curl 10.244.1.49:80

<!DOCTYPE html>

<html>

<head>

<title>Welcome to OpenResty!</title>

<style>

    body {

        width: 35em;

        margin: 0 auto;

        font-family: Tahoma, Verdana, Arial, sans-serif;

    }

</style>

</head>

<body>

<h1>Welcome to OpenResty!</h1>

<p>If you see this page, the OpenResty web platform is successfully installed and

working. Further configuration is required.</p>

<p>For online documentation and support please refer to

<a href="https://openresty.org/">openresty.org</a>.<br/>

Commercial support is available at

<a href="https://openresty.com/">openresty.com</a>.</p>

<p><em>Thank you for flying OpenResty.</em></p>

</body>

</html>

看到这里可能有人要说，这简直没法用，每次创建pod ip都要改变，总不能每次手动修改ip地址访问吧？如此访问，我怎么才能做负载均衡？

如何通过service解决问题负载问题

创建如下service，通过selector选择nginx服务

apiVersion: v1

kind: Service

metadata:

  name: nginx-service

  labels:

    app: nginx

spec:

  type: NodePort

  ports:

  - name: http

    port: 80

    targetPort: 80

    nodePort: 30007

  - name: https

    port: 443

    targetPort: 443

    nodePort: 30003

  selector:

    app: nginx

查看服务对应服务ip，并访问服务。

root@k8s-m opt]# kubectl get svc nginx-service

NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE

nginx-service   NodePort   10.99.251.122   <none>        80:30007/TCP,443:30003/TCP   29h

[root@k8s-master opt]#

[root@nginx-deployment-745fd7c98d-2xj9r /]# curl 10.99.251.122:80

<!DOCTYPE html>

<html>

<head>

<title>Welcome to OpenResty!</title>

<style>

    body {

        width: 35em;

        margin: 0 auto;

        font-family: Tahoma, Verdana, Arial, sans-serif;

    }

</style>

</head>

<body>

<h1>Welcome to OpenResty!</h1>

<p>If you see this page, the OpenResty web platform is successfully installed and

working. Further configuration is required.</p>

<p>For online documentation and support please refer to

<a href="https://openresty.org/">openresty.org</a>.<br/>

Commercial support is available at

<a href="https://openresty.com/">openresty.com</a>.</p>

<p><em>Thank you for flying OpenResty.</em></p>

</body>

</html>

通过如上service的方式已经实现了负载均衡，但是我们在服务没有创建之前仍然是不知道服务对外提供服务IP是什么？当然我们可以在service的yaml中内置ClusterIP，但是即使如此，还可能会出现ip占用的问题。

kube-dns是如何解决如上问题的？

在创建pod资源时，kubelet会将其所属名称空间中的所有service对象以环境变量的形式注入其中。如下所示：

[root@nginx-deployment-745fd7c98d-2xj9r /]# printenv|grep NGINX

NGINX_SERVICE_PORT_443_TCP=tcp://10.99.251.123:443

NGINX_SERVICE_PORT_80_TCP_PORT=80

NGINX_SERVICE_PORT_443_TCP_PORT=443

NGINX_SERVICE_PORT_80_TCP_PROTO=tcp

NGINX_SERVICE_PORT_443_TCP_PROTO=tcp

NGINX_SERVICE_SERVICE_HOST=10.99.251.123

NGINX_SERVICE_SERVICE_PORT_HTTP=80

NGINX_SERVICE_PORT=tcp://10.99.251.123:80

NGINX_SERVICE_PORT_80_TCP=tcp://10.99.251.123:80

NGINX_SERVICE_SERVICE_PORT_HTTPS=443

NGINX_SERVICE_SERVICE_PORT=80

NGINX_SERVICE_PORT_80_TCP_ADDR=10.99.251.123

NGINX_SERVICE_PORT_443_TCP_ADDR=10.99.251.123

所以我们可以直接通过如下形式进行访问（当然如果存在集群内服务调用的话，我们就可以直接配置成域名的形式）：

[root@nginx-deployment-745fd7c98d-2xj9r /]# curl nginx-service:80

<!DOCTYPE html>

<html>

<head>

<title>Welcome to OpenResty!</title>

<style>

    body {

        width: 35em;

        margin: 0 auto;

        font-family: Tahoma, Verdana, Arial, sans-serif;

    }

</style>

</head>

<body>

<h1>Welcome to OpenResty!</h1>

域名格式

具体为：<service_name>.<namespace>.svc.<cluster_domain>和<service_name>.<namespace>.<cluster_domain>，当然后面cluster_domain取决于本地/etc/resolv.conf是否配置，如上我的示例就没有使用命名空间也没有配置集群域名，那么我直接service名称就可以直接访问。

Kubernetes中使用ClusterDNS进行服务发现的更多相关文章

  1. kubernetes 简介：kube-dns 和服务发现

    服务发现 kubernetes 提供了 service 的概念可以通过 VIP 访问 pod 提供的服务,但是在使用的时候还有一个问题:怎么知道某个应用的 VIP?比如我们有两个应用,一个 app,一 ...

  2. Kubernetes如何使用kube-dns实现服务发现

    大纲: •       Kubernetes中如何发现服务 •       如何发现Pod提供的服务 •       如何使用Service发现服务 •       如何使用kube-dns发现服务 ...

  3. kubernetes进阶（三）服务发现-coredns

    服务发现,说白了就是服务(应用)之间相互定位的过程. 服务发现需要解决的问题: 1.服务动态性强--容器在k8s中ip变化或迁移 2.更新发布频繁--版本迭代快 3.支持自动伸缩--大促或流量高峰 我 ...

  4. Kubernetes 服务发现

    目录 什么是服务发现? 环境变量 DNS 服务 Linux 中 DNS 查询原理 Kubernetes 中 DNS 查询原理 调试 DNS 服务 存根域及上游 DNS 什么是服务发现? 服务发现就是一 ...

  5. Istio技术与实践02：源码解析之Istio on Kubernetes 统一服务发现

    前言 文章Istio技术与实践01: 源码解析之Pilot多云平台服务发现机制结合Pilot的代码实现介绍了Istio的抽象服务模型和基于该模型的数据结构定义,了解到Istio上只是定义的服务发现的接 ...

  6. prometheus k8s服务发现

    Prometheus的服务发现在解决什么问题? 被监控的目标(target)是整个监控体系中重要组成部分,传统监控系统zabbix通过 网络发现的机制自动创建主机到zabbix-server,进而快速 ...

  7. k8s之服务发现

    一.概述 k8s中支持两种服务发现方法: 环境变量和DNS 二.环境变量 当Pod被创建的时候,k8s将为Pod设置每一个Service的相关环境变量,这些环境变量包括两种类型: k8s Servic ...

  8. nginx动态配置及服务发现那些事

    Reference: http://xiaorui.cc/2016/10/16/nginx%E5%8A%A8%E6%80%81%E9%85%8D%E7%BD%AE%E5%8F%8A%E6%9C%8D% ...

  9. SpringCloud学习(3)——Eureka服务注册中心及服务发现

    Eureka概述: Eureka是Netflix的一个子模块, 也是核心模块之一.Eureka是一个基于REST的服务, 用于定位服务, 以实现云端中间层服务发现和故障转移.服务注册与发现对于微服务框 ...

随机推荐

  1. NIO.2中Path、 Paths、Files类的使用

  2. File类的概述和File类的静态成员变量

    File类概述:java.io.File类 文件和目录路径名的抽象表示形式 java把电脑中的文件和文件夹(目录)封账为了一个File类,我们可以使用File类对文件和文件夹进行操作 默认情况下,ja ...

  3. JavaScript进阶知识点——函数和对象详解

    JavaScript进阶知识点--函数和对象详解 我们在上期内容中学习了JavaScript的基本知识点,今天让我们更加深入地了解JavaScript JavaScript函数 JavaScript函 ...

  4. JAVA定时任务原理入门

    本文适用语言:java 序章:定时任务实现方式 当下,java编码过程中,实现定时任务的方式主要以以下两种为主 spring框架的@Scheduled quzrtz框架 网络上关于这两种框架的实践和配 ...

  5. 题解【CodeForces 910A The Way to Home】

    题目大意 一只青蛙现在在一个数轴上,它现在要从点 \(1\) 跳到点 \(n\) ,它每次可以向右跳不超过 \(d\) 个单位.比如,它可以从点 \(x\) 跳到点 \(x+a\)(\(1\le a\ ...

  6. YII学习总结2（命名空间和操作响应）

    YII基础准备1.命名空间<?php /****假设有三个同名的类,输出的值为A,B,C****/ use a\b\c\apple; use d\e\f\apple as bApple; use ...

  7. 基于微前端qiankun的多页签缓存方案实践

    作者:vivo 互联网前端团队- Tang Xiao 本文梳理了基于阿里开源微前端框架qiankun,实现多页签及子应用缓存的方案,同时还类比了多个不同方案之间的区别及优劣势,为使用微前端进行多页签开 ...

  8. SpringBoot定时任务 - 经典定时任务设计：时间轮(Timing Wheel)案例和原理

    Timer和ScheduledExecutorService是JDK内置的定时任务方案,而业内还有一个经典的定时任务的设计叫时间轮(Timing Wheel), Netty内部基于时间轮实现了一个Ha ...

  9. 羽夏看Linux内核——启动那些事

    写在前面   此系列是本人一个字一个字码出来的,包括示例和实验截图.如有好的建议,欢迎反馈.码字不易,如果本篇文章有帮助你的,如有闲钱,可以打赏支持我的创作.如想转载,请把我的转载信息附在文章后面,并 ...

  10. 万答#15，都有哪些情况可能导致MGR服务无法启动

    欢迎来到 GreatSQL社区分享的MySQL技术文章,如有疑问或想学习的内容,可以在下方评论区留言,看到后会进行解答 本文转载自微信公众号 "老叶茶馆" 欢迎大家关注! 1.都有 ...