什么网站可以做试卷,网站开发价格,com网站是用什么做的,开网店3个月来亏了10万前一篇文章#xff0c;概念性地介绍了K8s的一些基础组件#xff0c;如Pod、部署和服务。这篇文章#xff0c;我打算写写如何使用YAML清单定义和配置这些资源。实际上#xff0c;在K8s集群中创建对象有几种方式 - 命令#xff0c;或声明。两种方式区别不大。不过实际应用中… 前一篇文章概念性地介绍了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 environmentstaging,systemfrontend
可以查出所有具有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这个东西做为一个大的分布式架构肯定是比较复杂的。但实际应用中不是每个内容都需要理解和应用。做多了就是套路。蹚过了就是经验。未完待续喜欢就来个三连让更多人因你而受益
