部署Dotnet Core应用到Kubernetes(二)

前一篇文章,概念性地介绍了K8s的一些基础组件,如Pod、部署和服务。这篇文章,我打算写写如何使用YAML清单定义和配置这些资源。

实际上,在K8s集群中创建对象有几种方式 - 命令,或声明。两种方式区别不大。

不过实际应用中,一旦开始真正部署应用,最终都会走到YAML配置文件方式。这种方式也叫配置清单。每个资源类型的清单,例如部署、服务、入口,他们的格式会略有不同,尽管他们之间存在着共性。

这篇文章,我就着重写写如何使用YAML清单定义和配置这些资源。当然,涉及内容太多,我们还是面向实际应用,写写通用的,和最有针对性的配置格式,而不详细解释所有的配置选项和排列。

Pod和部署的配置清单

前文我们说过,Pod是K8s最小的可部署单元。我们部署Pod,不是部署单个容器,而是部署包含一个或多个容器的Pod。这个概念一定要清楚。

K8s中部署独立的Pod是可以的。但在实际应用中,最常见的做法是将Pod部署成为“部署资源”的一部分。

所以,通常我们的做法,是在部署清单中定义Pod资源,而不是创建一个Pod,然后创建一个部署来管理他们。换句话说,我们是创建了一个知道如何为我们创建Pod的部署。

我们先来看一个相对基础的部署清单:

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3strategy: type: RollingUpdaterollingUpdate:maxUnavailable: 1maxSurge: 1maxUnavailable: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19.3ports:- containerPort: 80

YAML对空格敏感,所以写的时候一定要注意缩进。

1. apiVersion、kind、metadata

这是K8s配置清单的开头,每个清单都会有这三个项。

apiVersion: apps/v1

apiVersion用来指示K8s API的版本。K8s有很多个API版本。以下命令可以查询已经安装的全部版本。

% kubectl api-versions

K8s的每个版本都包含了不同的API资源版本。

大多数情况下,配置应用时不需要太多关注这个版本号,对应好就成。

kind: Deployment

定义清单的类型。前面说了,各种资源都有不同的配置清单。本例中是部署。

metadata:name: nginx-deploymentlabels:app: nginx

元数据提供了诸如资源名称以及附加到资源上的标签等细节。

需要注意一下:标签是与资源相关的键值对,后面我们会用到。本例中,我们只有一个标签app,值是nginx。

2. spec

这是K8s清单中的规范资源部分,这部分才是实际指定类型的资源定义,在本例中,是部署(kind: Deployment)的配置。

  replicas: 3strategy: type: RollingUpdaterollingUpdate:maxUnavailable: 1maxSurge: 1maxUnavailable: 1

副本和策略,定义了部署应该创建多少个Pod实例,以及创建他们应该使用的方法。本例中,我们希望K8s同时运行三个Pod,并且部署新版本时使用滚动更新。

在策略中,我们设置maxUnavilable为1,这是更新策略的一个额外设置,表示我们希望在发布部署新版本时,在需要用新版本替换旧版本的Pod过程中,或者开始新Pod之前,每次只删除一个旧Pod。

maxSurge和maxUnavailable也是额外设置。maxSurge控制滚动更新时一次应该添加多少额外的容器,而maxUnavilable则定义了一个容器要运行多少秒后才可被认为是可用的。

  selector:matchLabels:app: nginx

selector部分定义这个部署管理哪些Pod。这里面涉及到元数据和选择器的相互配合,我们后面会说到。

  template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19.3ports:- containerPort: 80

部署的spec节的最后一个部分是模板。这是一个清单内的清单,里面也同样有metadata和spec。这里的内容实际是一个Pod的定义配置清单。

因此,这整个部署清单定义了两种类型的资源:Pod,和用于管理Pod扩展和生命周期的部署。

上面这个Pod模板,定义了一个叫nginx的容器,是由nginx 1.19.3镜像构建的。这里containerPort定义了容器内公开的端口。默认80,可不写。不过我自己觉得,写出来是一个好习惯。

如果我们想在Pod中部署两个容器,则需要在containers下添加另一个:

template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19.3ports:- containerPort: 80- name: nginx1image: nginx:1.19.3ports:- containerPort: 8080

例子中,我们添加的第二个容器,名称叫nginx1,也是nginx 1.19.3镜像,端口在8080。

上面就是部署清单的基本内容。这部分内容很多,需要了可以查K8s相关的部分。

前面说了,K8s清单不同类型的规范会稍有不同,但他们的共同之处也很多,比如元数据和选择器。所以学通了一个,其它基本上也就通了。

标签和选择器的配合

标签是K8s中最广泛使用的一个概念,是与对象关联的一个键值对。每个对象都可以有几个不同的标签,但每个键只能定义一次。

看前边的例子:

metadata:name: nginx-deploymentlabels:app: nginx

有一个键名叫app,值是nginx。

同样,在spec的template中:

spec:template:metadata:labels:app: nginx

这里,我们向Pod添加了同样的键值对。

在需要的情况下,我们还可以添加其它的标签,例如:

metadata:labels:app: nginxenvironment: stagingsystem: frontend

这两个标签的用处,可以自己去查。

标签在命令行管理的时候非常有用。例如下面的命令:

kubectl get pods -l environment=staging,system=frontend

可以查出所有具有staging和frontend标签的Pod。

标签在这里,主要是提供附加信息。所以,实际中可以加上各种合适的标签。同样,在选择器定义时,也可以通过这些标签来区分不同的资源。例如:

selector:matchLabels:app: nginx

这里面,选择器定义了所选资源的条件。满足条件的资源,才会被匹配。例如,上面这个选择器将匹配所有具有app标签且值为nginx的Pod。

同样,对应上面的命令行,选择器可以写为:

selector:matchLabels:environment: stagingsystem: frontend

这儿要注意:这个匹配的全条件的,条件之间是与的关系。当然,还有一些资源可以支持更多的匹配表达式,例如:In、NotIn、Exists或DoesNotExist。

除了部署外,服务也使用相同的机制来定义它将数据传递给哪个Pod。

服务的配置清单

在前文中说过,服务可以看作集群内的负载均衡,负责隔离并转发向Pod发出的请求。

我们来看一个清单的例子:

apiVersion: v1
kind: Service
metadata:name: my-shop-backendlabels: app: my-shopsystem: backend
spec:type: ClusterIPselector:app: my-shopsystem: backendports:- port: 80targetPort: 8080protocol: TCP

1. apiVersion、kind、metadata

跟前边一样,先定义清单的资源类型,这回是服务,以及所需的API版本。元数据为服务指定了一个名称,并加了两个标签用来记录和提供信息。

2. spec

首先,需要定义服务类型。根据K8s的版本,这儿有4种选择:

  • ClusterIP,默认值,定义服务只能从内部访问;

  • NodePort,在每个节点自动生成的端口上公开服务;

  • loadbalance,在连接AWS、Azure等云服务时,提供负载均衡;

  • ExternalName,这个有点特殊,它不做代理或转发,而只提供内部的DNS服务。

实际应用中,通常就用默认的ClusterIP,把服务作为内部负载均衡器,并使用入口将外部请求转发到服务的结构就OK了。

下一个是选择器,这个配置具体控制负载均衡的实现配置。如前一节所写的,选择器将选择所有具有所需标签的Pod,在本例中是app:my-shop和system:backend。服务将把所有传入的请求路由到这些服务。看下面的部分:

spec:selector:app: my-shopsystem: backend

最后,是清单中的端口配置。例子中定义了服务将被公开的端口80以及要使用的协议,本例中是TCP。targetPort是Pod上的端口,表示请求将会被传发到8080。这一段单摘出来如下:

spec:ports:- port: 80targetPort: 8080protocol: TCP

这个部分因为涉及到网络,所以配置可以很复杂。必要时,可以参考K8s的文档。

在应用中,通常需要向外部公开某种HTTP服务。部署部分处理应用程序Pod的管理,服务提供多个Pod内部的负载均衡,而入口将应用暴露给外部。

入口的配置清单

前文中说过,入口充当内部K8s服务的外部负载均衡或反向代理。下面的例子展示了如何公开内部服务到外网:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: my-shop-backend-ingresslabels: app: my-shopsystem: backendannotations:nginx.ingress.kubernetes.io/rewrite-target: /
spec:rules:- http:host: api.my-shop.compaths:- path: /my-shopbackend:serviceName: my-shop-backendservicePort: 80

1. apiVersion、kind、metadata

同样,入口清单也包含API版本、类型和元数据。不同的是,入口的元数据还包含入口的名称以及关联对象的标签。

此外,还多了一个注释标签annotations。注释标签的工作原理与前面提到的标签很相似,也都是键值对。不同的是注释标签不能用来选择对象。

本例中,我们添加了注释nginx.ingress.kubernetes.io/rewrite-target,值为/。这个注释用到了Nginx入口控制器的一个特殊键值,用来告诉控制器重写传入请求的匹配路径为“/”。

例如,在以下路径收到一个请求:

/my-shop/orders/123

入口控制器将重写到:

/orders/123

另外,为了使用入口,集群中需要部署一个入口控制器。每个入口控制器会有不同的特性,都需要不同的注释来配置。因此,入口配置清单可能会根据不同的作用而有所不同。

2. spec

入口清单的spec部分包含配置由集群的入口控制器管理的反向代理所需要的全部规则。如果你用过Nginx、IIS或其它类似的反代,那应该会容易理解,规则很相似,都是定义了一组传入请求的规则,以决定将他们路由到什么路径。

入口清单可以定义多种规则,但一定要记着可部署单元的概念。我们应该为部署到K8s的每个应用配置单一入口,而不是跨应用去配置入口,尽管这样做技术上支持。

看上面例子的spec段:

spec:rules:- http:host: api.my-shop.compaths:- path: /my-shopbackend:serviceName: my-shop-backendservicePort: 80

通常我会习惯用主机来区分不同的应用,像例子中的api.my-shop.com。当然,您也可以通过匹配路径来定义,例如/my-shop。而这个会根据元数据中的重写定义注释被重写。

除了匹配传入的路径和主机外,清单中还需要定义请求转发的内部服务和端口。本例中,我们用了同样的80端口去路由到上一节中定义的后端服务中。

上面这个例子是最常见的一个入口清单定义,只将传入的请求与单个服务匹配。

有时候,可能会几种不同类型的Pod组成一个服务“微单元”。这种情况下,也可能会有几个K8s服务,并且基于路径将几个服务路由到单一入口内,这时候可以这样配置:

spec:rules:- http:paths:- path: /ordersbackend:serviceName: my-shop-orders-serviceservicePort: 80- http:paths:- path: /historybackend:serviceName: my-shop-order-history-backendservicePort: 80

在K8s配置时,入口中可以加入很多配置。这部分如果有问题,可以去翻K8s文档。

如果只是需要将应用部署到K8s,那上边的内容基本够用了。唯一要注意的是集群中用了哪个入口控制器。

总结一下

这篇文章是这个系列的第二篇。

这篇文章介绍了我们必须要知道的K8s的主要资源:Pod、部署、服务、入口的YAML基本配置,并列出了一些最重要的配置值。

K8s这个东西,做为一个大的分布式架构,肯定是比较复杂的。但实际应用中,不是每个内容都需要理解和应用。

做多了,就是套路。

蹚过了,就是经验。

(未完待续)

喜欢就来个三连,让更多人因你而受益

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/306878.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

linux+c+逐行读文件内容,使用C ++中的ifstream逐行读取文件

在C 中逐行读取文件可以通过某些不同的方式完成。[快]循环使用std :: getline()最简单的方法是使用std :: getline()调用打开std :: ifstream和循环。 代码简洁易懂。#include std::ifstream file(FILENAME);if (file.is_open()) {std::string line;while (getline(file, line)…

如何区分netty是udp还是tcp_鲜奶粉还是大包粉,到底该如何区分?

100%的宝爸宝妈们都希望为宝宝挑选最营养、最新鲜的口粮,也相信让娃爸每周逛遍各大超市,只为了选两罐最新日期的奶粉,这种事情一定不止一个人做过!一直以来,人们对于“新鲜”有着亘古不变的追求。尤其是对待生活中的“…

Winform 进度条弹窗和任务控制

Winform 进度条弹窗和任务控制目录Winform 进度条弹窗和任务控制一、弹窗前台二、弹窗后台三、使用方法四、效果展示和代码地址独立观察员 2020 年 11 月 17 日最近要给一个 Winform 项目添加功能,需要一个能显示进度条的弹窗,还要求能够中止任务&#x…

linux下rip服务启动失败,RIP协议_linux系统管理与服务的技术博客_51CTO博客

理解并配置动态路由协议RIPRIP(Routing Information Protocol)是应用较早、使用较普遍的内部网关协议(Interior Gateway Protocol,IGP),适用于小型网络,是典型的距离矢量(Distance-Vector)路由协议,是一种单纯的向邻居路由器发送自…

c语言prime函数怎么用_C语言 要发就发

点击上方“蓝字”关注我们愉快的一天,不得不做的三件事:种田,锄地,整代码!!!【题目】“1898——要发就发”。请将不超过1993的所有素数从小到大排成第一行,第二行上的每个数都等于它…

linux如何使用vnc远程登录,如何使用Xmanager及VNC登录远程桌面

如何调用远程桌面,比较常见的有两种方式:Xmanager及VNC正好今天鼓捣了一下,特整理如下:XmanagerXmanager的调用也有两种方式:一、直接在Xshell中调用这时需设置会话属性,如下图所示,需在“隧道”…

python自然语言处理_python

chinese-xinhua/ | - data/ 汉字例子: { "word": "吖", "oldword": "吖", "strokes": "6", "pinyin": "ā", "radicals": "口", "explanation": &…

别在.NET死忠粉面前黑.NET5,它未来可期!

期盼已久的.NET5,终于在11月11日正式发布,整个.NET社区都为之沸腾,知乎、博客园、QQ群、微信群,随处可见.NET5 的热议,作为.NET死忠粉,我也挺兴奋的。然而一片欢歌笑语中总有一些很不和谐的声音&#xff0c…

linux系统 个人使用情况,个人使用Linux操作系统常要做的事

也算是装过多个Linux发行版了,无论是虚拟机还是实际的电脑。虽然大多是装了之后很初浅玩玩——只是在本地操作一些文件和目录,而且可以使用的软件工具也是有限的,甚至没有网络(你可以想象一下都能做些什么了)。这尤其对我这样的菜鸟来说使用起…

c#物联网_C# 基础知识系列- 16 开发工具篇

0. 前言 这是C# 基础知识系列的最后一个内容讲解篇,下一篇是基础知识-实战篇。这一篇主要讲解一下C#程序的结构和主要编程工具。 1. 工具 工欲善其事必先利其器,在实际动手之前我们先来看看想要编写一套C#程序需要做哪些准备吧。 1.1 选择 C# 的sdk在之前…

接口幂等设计探索实践

幂等性原本是数学上的概念,即使公式:f(x)f(f(x)) 能够成立的数学性质。用在编程领域,则意为对同一个系统,使用同样的条件,一次请求和重复的多次请求对系统资源的影响是一致的、或者说是符合预期的。背景稳定性设计第一…

linux 用mutex定义一个linkedlist,一个高性能无锁非阻塞链表队列

这个是一个用c 11标准实现的无锁非阻塞链表队列,通过增加一个dummy节点,解偶合链表头指针和尾指针。使得当只有一个生产者和一个消费者时,进队和出队都无需加锁,进队操作的是尾指针,出队操作的是头指针,互不…

Windows 7 安装 .NET 5 / .NET Core 3.1 环境的方法和依赖文件

随着 .NET 5 正式版的发布,越来越多的人开始向 .NET 5 、.NET Core 平台迁移。尽管微软已经在 2020 年 1 月 14 日停止了对 Windows 7 的支持,但仍有大批客户的操作系统对 Windows 7 恋恋不舍。为此,我们需要解决 .NET 5 运行时(R…

easyui 动态设置单元格控件_动态显示最大最小值的折线图

小伙伴们好啊,今天和大家分享一个图表有关的知识。折线图想必大家已经司空见惯,今天就要在简单的折线上,做出不简单的效果。用动态折线图,展示一周销售的变化,并且自动突出最大最小值。1、准备数据源以某家水果店1月份…

WebBenchmark动态测试Webapi

在编写Webapi测试用例的时候都是定义固定的测试数据,但这样的测试只能针对单一数据。为了更好的模拟实际情况,往往需要进行动态数据测试;通过动态数据测试可以更好的测出服务在不同数据情况下的处理能力。WebBenchmark支持动态数据函数&#…

linux开发需要学习什么,linux开发需要掌握哪些知识?

原标题:linux开发需要掌握哪些知识?嵌入式linux开发的应用是非常广泛的。而且linux是开源的,各种技术也是非常成熟的。不过很多初学者在学习linux开发过程中感觉非常难,那么对于linux开发需要掌握哪些知识呢?1.Linux是…

csv 字符串_python3从零学习-5.5.1、CSV 文件读写

源代码: Lib/csv.py模块内容csv 模块定义了以下函数:csv.reader(csvfile, dialectexcel, **fmtparams)返回一个 reader 对象,该对象将逐行遍历 csvfile。csvfile 可以是任何对象,只要这个对象支持 iterator 协议并在每次调用 __ne…

持续交付三:动手自动化“开发”—“测试”

前两篇博文中提到Development,QA,Staging,Production四个环境,也说明了源代码的分支和四个环境的对应关系,本篇博文聊一下,怎么把源码自动化发布到对应的环境中。市面上主流的DevOpt工具都支持这些功能,github,gitlab,…

如何把python文件发给别人没_如何把自己写的python程序给别人用

这里讲的给别人用,不是指将你的代码开源,也不是指给另一个程序员用。。。。。 前段时间写了个程序,输入URP学生系统的账号和密码,输出课表、绩点之类的信息,想给同学用,但是总不能叫别人也去装python吧。。…

使用WebBenchmark对webapi进行管理和性能测试

WebBenchmark是基于beetlex开发的webapi管理和性能测试软件,最新版本1.0.3可以独立运行在linux/windows中,并不再需要安装.net core运行环境。部署可以通过以下地址下载最新版本:https://github.com/IKende/WebBenchmark可以根据需要下载linux64或win64运…