Docker与k8s的恩怨情仇(七)—— “服务发现”大法让你的内外交互原地起飞
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具、解决方案和服务,赋能开发者。
第一章:Docker与k8s的恩怨情仇(一)—成为PaaS前浪的Cloud Foundry
第二章:Docker与k8s的恩怨情仇(二)—用最简单的技术实现“容器”
第三章:Docker与k8s的恩怨情仇(三)—后浪Docker来势汹汹
第四章:Docker与k8s的恩怨情仇(四)-云原生时代的闭源落幕
第五章:Docker与k8s的恩怨情仇(五)——Kubernetes的创新
第六章:Docker与k8s的恩怨情仇(六)—— “容器编排”上演“终结者”大片
在上节中我们介绍了活字格公有云版在k8s上部署,以及如何实现容器之间的编排与管理控制。为了进一步实现内外交互调用,则需要实现服务发现的功能。也就是我们前面提到“人与狗”之间的关系。
做过微服务的同学可能了解过什么叫服务发现,spring cloud项目中的Eureka框架就是完成这个功能的,其主要工作就是注册内部的服务,以供其他集群的服务可以调用、访问这个服务。
我们合理猜测Kubernetes的存在很有可能激发了各种微服务框架产生服务发现机制。
在Kubernetes中服务发现对应的模块是Service与Ingress,接下来,我们分别来说说这两个功能。
Service与Ingress
Service类似于服务的注册功能。
其逻辑很简单,在kubernetes声明一个服务,从而生成一个VIP(虚拟网络),所有Kubernetes集群中的其他组件,都可以通过这个VIP来访问这个服务,并且这个服务是不会随Service的改变而改变的,只要创建就是终生存在。
Service
而服务的内容是什么呢?这部分和上述的Deployment一样,是通过selector选择器确定的。我们可以通过下述yaml来创建一个服务:
apiVersion: v1
kind: Service
metadata:
name: hostnames
spec:
selector:
app: hostnames
ports:
- name: default
protocol: TCP
port: 80
targetPort: 9376
通过上一篇的介绍,我们可以了解这个服务所需要代理的内容是app==hostnames的Pod。同时这里也有一个新的字段ports,这个字段是说明该代理的服务的请求方式(protocol)、对外暴露的端口(port)、内部的端口(targetPort)分别是什么。
我们可以通过这个sample-service.yaml的文件创建一个Service并且查看一个Service:
# 创建
kubectl apply -f sample-service.yaml
# 查看
kubectl get services hostnames
在这个service中存在一个ClusterIP,这个IP就是这个Service生成的VIP,在集群内部的其他成员,都可以通过这个VIP来访问这个Service。但是由于我们现在没有任何的具体服务让这个Service代理,因此现在请求这个IP是不会成功的。
那么,我们需要为这个Service创建一个具体实现:以下的sample-deployment.yaml文件是创建一个多副本的Pod,其Pod的功能是返回自己的podname:
apiVersion: apps/v1
kind: Deployment
metadata:
name: hostnames
spec:
selector:
matchLabels:
app: hostnames
replicas: 3
template:
metadata:
labels:
app: hostnames
spec:
containers:
- name: hostnames
image: k8s.gcr.io/serve_hostname
ports:
- containerPort: 9376
protocol: TCP
~
在这段代码中,我们把容器的9376端口暴露的出来,因为这个Pod是通过这个端口与外部通行的。同样我们执行以下命令创建和查看这个pod副本:
# 创建
kubectl apply -f sample-deployment.yaml
# 查看
kubectl get pods -l app=hostnames
在这部分内容中可以看到这个pod副本已经创建成功了。此时,根据我上一节所说的控制器模式,Service也有对应的处理Service的控制器,其内部发现了有满足app==hostnames的服务,即将这个服务和Service进行了绑定 。此时,我们就可以通过任意一台集群内的主机来请求刚才上文中的ClusterIP:
在这一部分可以看到,我们进行了很多次请求,但是每次返回的结果都不同,这是因为Service在其内部通过网络插件(CNI)做了负载均衡处理,所以我们可以通过Service来实现的负载均衡功能。
学习过程中的“误入歧路”
在学习了解这部分内容的时候,我一直有一个误解:认为Service是必须对应Deployment这种Pod的编排控制器对象才能工作的,所以把Service --> Deployment --> Pods这条逻辑关系熟记于心,但这种理解其实是错误的。
在Kubernetes中,每个功能组件各司其职,他们只会处理自己该做的事,比如这里,Service绑定Pod所依赖的是选择器中的app==hostnames,而这个定义是出现在Deployment中定义在Pod中的,因此Service和Deployment完全没有关系,它们俩谁也不认识谁,关系可以用下图来描述:
并且,在之前的学习中还错误地认为负载均衡服务是由Deployment提供的,其实这个功能是Service中的网络插件来处理的,并且用户同样也可以自定义使用的网络查件或者负载均衡算法是什么,Kubernetes给了用户足够大的自由度。
Ingress
有了Service之后,我们的服务就可以在集群中随意访问达到服务之间的交流关系了, 但是要想让我们的服务让最终的用户访问到,我们还需要最后一个组件Ingress。
Ingress是Kubernetes中的反向代理服务,它可以解析配置的域名指向到我们内部的Service中,其定义可以通过下述的yaml来实现:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: sample-ingress
spec:
rules:
- host: hostname.sample.com
http:
paths:
- path: /
backend:
serviceName: hostnames
servicePort: 80
上述代码中,我们将hostname.sample.com这个域名指向了刚才定义的hostnames这个Service。通过这样的操作,我们的服务便就可以通过定义域名配置供外部的服务进行访问了。而Ingress的创建命令,也和前面所说的一样:
kubectl apply -f sample-ingress.yaml
有了这部分配置,我们的功能原则上就能够让外部访问了。但在实际应用中我们本地没有可供测试的环境,本地的Kubernetes环境是通过kindD生成的,其核心是多个Docker Container而不是多台机器。上述内容在Container内部运行,是使用Docker模拟Kubernetes的功能,因此这也是本文中唯一无法验证成功的一个功能模块。
完整部署一个活字格应用
通过上节我们一起学习了Pod间的编排控制器的使用,本节中实现了内外交互调用,进一步实现服务发现的功能,我们现在就可以再次回到之前提出的问题: 究竟如何成功部署一个活字格应用。
通过介绍整个Kubernetes的基础使用的流程,我们可以看到一个服务在Kubernetes变成Pod,通过Deployment部署,通过Service服务发现,通过Ingress反向代理的全过程,经过这些模块的协力配合之后,我们的活字格应用终于可以部署在这个Kubernetes集群中了。
希望这张图片展示,能够为大家带来更加直观的感觉。
总结
截止到本章,我们已经完整介绍了活字格公有云版做k8s部署的全过程。下一节将会为大家带来本系列文章的最后一篇——Kubernetes总览,让大家对Kubernetes集群内容部分有一个整体性印象,对一些深层次功能做一个总结。
感兴趣的小伙伴不要错过~我们下篇接着聊。
Docker与k8s的恩怨情仇(七)—— “服务发现”大法让你的内外交互原地起飞的更多相关文章
- Docker与k8s的恩怨情仇(四)-云原生时代的闭源落幕
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 在本系列前几篇文章中,我们介绍了从Cloud Foundry到Docker等PaaS平台的发展迭代过程.今天 ...
- Docker与k8s的恩怨情仇(六)—— “容器编排”上演“终结者”大片
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 在上节中,我们为大家介绍了Pod的基础内容,Kubernetes如何站在上帝视角上处理容器和容器之间的关系. ...
- Docker与k8s的恩怨情仇(八)——蓦然回首总览Kubernetes
在系统介绍了如何实际部署一个K8S项目后,作为本系列文章的最后一篇,我们一起来看看Kubernetes集群内容总览,再对一些更深层次的功能进行总结. Kubernetes总览 下图是一个k8s的总览结 ...
- Docker与k8s的恩怨情仇(一)—成为PaaS前浪的Cloud Foundry
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 大家在工作中或许或多或少都接触过Docker,那你知道Docker以及容器化背后的原理到底是什么吗? 容器化 ...
- Docker与k8s的恩怨情仇(二)—用最简单的技术实现“容器”
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 上次我们说到PaaS的发展历史,从Cloud Foundry黯然退场,到Docker加冕,正是Docker& ...
- Docker与k8s的恩怨情仇(三)—后浪Docker来势汹汹
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 上一节我们为大家介绍了Cloud Foundry等最初的PaaS平台如何解决容器问题,本文将为大家展示Doc ...
- Docker与k8s的恩怨情仇(五)——Kubernetes的创新
转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具.解决方案和服务,赋能开发者. 上节中我们提到了社区生态的发展使得Kubernetes得到了良性的发展和传播.比起相对封闭的Docker社区 ...
- Docker 与 K8S学习笔记(七)—— 容器的网络
本节我们来看看Docker网络,我们这里主要讨论单机docker上的网络.当docker安装后,会自动在服务器中创建三种网络:none.host和bridge,接下来我们分别了解下这三种网络: $ s ...
- k8s之服务发现
一.概述 k8s中支持两种服务发现方法: 环境变量和DNS 二.环境变量 当Pod被创建的时候,k8s将为Pod设置每一个Service的相关环境变量,这些环境变量包括两种类型: k8s Servic ...
随机推荐
- 解决 Golnag Gin框架跨域
package main import ( "github.com/gin-gonic/gin" "awesomeProject/app/app_routers" ...
- 使用jsonp实现跨源请求
jsonp 该技术用来实现跨源请求,即向协议.域名.端口号不同的服务器发送请求 通过使用 script 标签的 src 向服务器发送GET请求http://xxx/xxx?callback=callb ...
- Kubernetes的资源管理
本节讲解为一个pod配置资源的预期使用量和最大使用量.通过设置这两组参数,可以确保pod公平地使用Kubernetes集群资源,同时也影响着整个集群pod的调度方式. 1.为pod中的容器申请资源 创 ...
- 11、linux的目录结构
11.1.查看磁盘的id: blkid 11.2.linux目录类似一个倒挂的树: / 是所有目录的顶点,目录磁盘和分区是没有关联的,因此/下不同的目录会对应不同的磁盘的不同的分区: linux中硬盘 ...
- 45、django工程(URLconf)
45.1.django URLconf 路由系统介绍: 1.说明: URL配置(URLconf)就像Django 所支撑网站的目录.它的本质是URL模式以及要为该URL模式调用的视图函数之间的映射表, ...
- API安全综述
API安全综述 译自:An Overview on API Security. 本文概括了API防护有关的方方面面,从上层视角介绍了API防护中主要注意的点,并给出了相应的建议.本文可以作为一个API ...
- nginx限流模块(防范DDOS攻击)
Nginx限流模式(防范DDOS攻击) nginx中俩个限流模块: 1.ngx_http_limit_req_module(按请求速率限流) 2.ngx_http_limit_conn_module( ...
- 1.5Java、万维网以及其他
要点提示:Java是一种功能强大和多用途的编程语言,可用于开发运行在移动设备.台式计算机以及服务器端的软件.
- 堆&&优先队列&&TreeMap
题目描述 5710. 积压订单中的订单总数 题解 题目不难,主要是要读懂题意,一步步模拟,代码较长,需要细心检查. 坑较多,比如我犯了很多傻逼问题:想都不想就拿1<<9+7当作100000 ...
- Java核心基础第3篇-Java流程控制
Java流程控制 本章一起来探讨下Java的流程控制语句.主要从以下几个方面展开: Java分支语句 Java循环语句 Java其实和其他任何的开发语言一样,分支语句和循环语句是必不可少的,有个这两个 ...