k8d创建资源(3)（负载均衡原理，回滚指定版本，label控制pod的位置）

Deployment介绍

Deployment是kubernetes 1.2引入的概念，用来解决Pod的编排问题。Deployment可以理解为RC的升级版（RC+Reolicat Set）。特点在于可以随时知道Pod的部署进度，即对Pod的创建、调度、绑定节点、启动容器完整过程的进度展示。

使用场景

创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。
检查Deployment的状态来确认部署动作是否完成（Pod副本的数量是否达到预期值）。
更新Deployment以创建新的Pod(例如镜像升级的场景)。
如果当前Deployment不稳定，回退到上一个Deployment版本。
挂起或恢复一个Deployment。

Service介绍

Service定义了一个服务的访问入口地址，前端应用通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端的Pod副本集群之间是通过Label Selector来实现“无缝对接”。RC保证Service的Pod副本实例数目保持预期水平。

外部系统访问Service的问题

IP类型 说明
Node IP Node节点的IP地址
Pod IP Pod的IP地址
Cluster IP Service的IP地址

环境介绍

主机 IP地址 服务
master 192.168.1.21 k8s
node01 192.168.1.22 k8s
node02 192.168.1.23 k8s

基于https://blog.51cto.com/14320361/2464655 的实验继续进行

一，Delpoyment和service的简单使用

1.练习写一个yaml文件，要求使用自己的私有镜像，要求副本数量为三个。

[[email protected] ~]# vim xgp.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1

（1）执行一下

[[email protected] ~]# kubectl apply -f xgp.yaml  --record

（2）查看一下

[[email protected] ~]# kubectl get pod

（3）访问一下

[[email protected] ~]# curl 10.244.2.16

（4）更新一下yaml文件，副本加一

[[email protected] ~]# vim xgp.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  replicas: 4
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1

<1>执行一下

[[email protected] ~]# kubectl apply -f xgp.yaml --recore

<2>查看一下

[[email protected] ~]# kubectl get pod

副本数量加一，如果yaml文件的副本为0，则副本数量还是之前的状态，并不会更新。

2.练习写一个service文件

[[email protected] ~]# vim xgp-svc.yaml
kind: Service
apiVersion: v1
metadata:
  name: xgp-svc
spec:
  selector:
    app: xgp-server
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

（1）执行一下

[[email protected] ~]# kubectl apply -f xgp-svc.yaml

（2）查看一下

[[email protected] ~]# kubectl get svc

（3）访问一下

[[email protected] ~]# curl 10.107.119.49

3.修改yaml文件

[[email protected] ~]# vim xgp.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1
        ports:
          - containerPort: 80  #提示端口

注意：在Delpoyment资源对象中，可以添加Port字段，但此字段仅供用户查看，并不实际生效

执行一下

[[email protected] ~]# kubectl apply -f xgp.yaml

4.service文件映射端口

[[email protected] ~]# vim xgp-svc.yaml
kind: Service
apiVersion: v1
metadata:
  name: xgp-svc
spec:
  type: NodePort
  selector:
    app: xgp-server
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30123

执行一下

[[email protected] ~]# kubectl apply -f xgp-svc.yaml

查看一下

[[email protected] ~]# kubectl get svc

访问一下

[[email protected] ~]# curl 127.0.0.1:30123

5.修改三个pod页面内容

（1）查看一下pod信息

[[email protected] ~]# kubectl get pod -o wide

（2）修改POD页面内容（三台不一样）

[[email protected] ~]# kubectl exec -it xgp-web-8d5f9656f-8z7d9 /bin/bash
//根据pod名称进入pod之中

进入容器后修改页面内容

[email protected]:/usr/local/apache2# echo xgp-v1 > htdocs/index.html
[email protected]:/usr/local/apache2# exit

访问一下

[[email protected] ~]# curl 127.0.0.1:30123

二.分析一下k8s负载均衡原理

（1）查看service的暴露IP

[[email protected] ~]# kubectl get svc

（2）查看一下iptabes规则

[[email protected] ~]# iptables-save
//查看已配置的规则

SNAT：Source NAT（源地址转换）

DNAT：Destination NAT（目标地址转换）

MASQ：动态的源地址转换

（3）根据service的暴露IP，查看对应的iptabes规则

[[email protected] ~]# iptables-save | grep 10.107.119.49

[[email protected] ~]# iptables-save | grep KUBE-SVC-ESI7C72YHAUGMG5S

（4）对应一下IP是否一致

[[email protected] ~]# iptables-save | grep KUBE-SEP-ZHDQ73ZKUBMELLJB

[[email protected] ~]# kubectl get pod -o wide

Service实现的负载均衡：默认使用的是iptables规则。IPVS

三.回滚到指定版本

（1）删除之前创建的delpoy和service

[[email protected] ~]# kubectl  delete -f xgp.yaml
[[email protected] ~]# kubectl  delete -f xgp-svc.yaml

（2）准备三个版本所使用的私有镜像，来模拟每次升级不同的镜像

[[email protected] ~]# vim xgp1.yaml  （三个文件名不相同）
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1  （三台版本不同）
        ports:
          - containerPort: 80

此处3个yaml文件 指定不同版本的镜像

（3）运行三个服务，并记录三个版本信息

[[email protected] ~]# kubectl apply -f xgp-1.yaml --record
[[email protected] ~]# kubectl apply -f xgp-2.yaml --record
[[email protected] ~]# kubectl apply -f xgp-3.yaml --record

（4）查看有哪些版本信息

[[email protected] ~]# kubectl rollout history deployment xgp-web

（5）运行之前的service文件

[[email protected] ~]# kubectl apply -f xgp-svc.yaml

（6）查看service暴露端口

[[email protected] ~]# kubectl get svc

（7）测试访问

[[email protected] ~]# curl 127.0.0.1:30123

（8）回滚到指定版本

[[email protected] ~]# kubectl rollout undo deployment xgp-web --to-revision=1
//这里指定的是版本信息的编号

<1>访问一下

[[email protected] ~]# curl 127.0.0.1:30123

<2>查看有哪些版本信息

[[email protected] ~]# kubectl rollout history deployment xgp-web


编号1已经被编号2替代，从而生的是一个新的编号4

四.用label控制pod的位置

默认情况下，scheduler会将pod调度到所有可用的Node，不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。

kubernetes通过label来实现这个功能

label 是 key-value 对，各种资源都可以设置 label，灵活添加各种自定义属性。比如执行如下命令标注 k8s-node1 是配置了 SSD 的节点

首先我们给node1节点打上一个ssd的标签

[[email protected] ~]# kubectl label nodes node02 disk=ssd

（1）查看标签

[[email protected] ~]# kubectl get nodes --show-labels | grep node02

（2）删除副本一

[[email protected] ~]# kubectl delete -f xgp-1.yaml
deployment.extensions "xgp-web" deleted
[[email protected] ~]# kubectl delete svc xgp-svc

（3）修改副本一的yaml文件

[[email protected] ~]# vim xgp-1.yaml 

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1
        ports:
          - containerPort: 80
      nodeSelector:    #添加节点选择器
        disk: ssd      #和标签内容一致

（4）执行一下

[[email protected] ~]# kubectl apply -f xgp-1.yaml

查看一下

[[email protected] ~]# kubectl get pod -o wide

现在pod都在node02上运行

（5）删除标签

[[email protected] ~]# kubectl  label nodes node02 disk-

查看一下

[[email protected] ~]# kubectl get nodes --show-labels | grep node02

没有disk标签了

五，小实验

1）使用私有镜像v1版本部署一个Deployment资源对象，要求副本Pod数量为3个，并创建一个Service资源对象相互关联，指定要求3个副本Pod全部运行在node01节点上，记录一个版本。

（1）用label控制pod的位置

[[email protected] ~]# kubectl label nodes node01 disk=ssd

（2）编写源yaml文件

[[email protected] ~]# vim xgp.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v1
        ports:
          - containerPort: 80
      nodeSelector:
        disk: ssd

（3）编写源service文件

[[email protected] ~]# vim xgp-svc.yaml
kind: Service
apiVersion: v1
metadata:
  name: xgp-svc
spec:
  type: NodePort
  selector:
    app: xgp-server
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30123

（4）执行yaml文件，创建控制器。执行service文件创建映射端口

[[email protected] ~]# kubectl apply -f  xgp.yaml  --recore
[[email protected] ~]# kubectl apply -f xgp-svc.yaml

（5）查看一下pod节点

[[email protected] ~]# kubectl get pod -o wide

（6）记录一个版本

[[email protected] ~]# kubectl rollout history deployment xgp-web > pod.txt

（7）访问一下

2）根据上述Deployment，升级为v2版本，记录一个版本。

（1）修改yaml文件镜像版本

[[email protected] ~]# vim xgp.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v2    #修改版本为二
        ports:
          - containerPort: 80
      nodeSelector:
        disk: ssd

（2）刷新一下yaml文件

[[email protected] ~]# kubectl apply -f xgp.yaml --record

（3）访问一下

（4）记录一个版本

[[email protected] ~]# kubectl rollout history deployment xgp-web > pod.txt

3）最后升级到v3版本，这时，查看Service关联，并且分析访问流量的负载均衡详细情况。

1）修改yaml文件镜像版本

[[email protected] ~]# vim xgp.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: xgp-web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: xgp-server
    spec:
      containers:
      - name: web
        image: 192.168.1.21:5000/web:v3   #修改版本为二
        ports:
          - containerPort: 80
      nodeSelector:
        disk: ssd

（2）刷新一下yaml文件

[[email protected] ~]# kubectl apply -f xgp.yaml --record

（3）访问一下

（5）分析访问流量的负载均衡详细情况

<1>查看一下service映射端口

<2>以ip为起点，分析访问流量的负载均衡详细情况

Service实现的负载均衡：默认使用的是iptables规则。IPVS

[[email protected] ~]# iptables-save | grep 10.107.27.229
//根据service的暴露IP，查看对应的iptabes规则

[[email protected] ~]# iptables-save | grep KUBE-SVC-ESI7C72YHAUGMG5S

这里显示了各节点的负载比例

<3>对应一下IP是否一致
[[email protected] ~]# iptables-save | grep KUBE-SEP-VDKW5WQIWOLZMJ6G

[[email protected] ~]# kubectl get pod -o wide

4）回滚到指定版本v1，并作验证。

<1>回滚到指定版本

[[email protected] ~]# kubectl rollout undo deployment xgp-web --to-revision=1
//这里指定的是版本信息的编号

<2>访问一下

[[email protected] ~]# curl 127.0.0.1:30123

排错思路

[[email protected] ~]# less /var/log/messages  | grep kubelet
[[email protected] ~]# kubectl  logs -n  kube-system kube-scheduler-master
[[email protected] ~]# kubectl describe pod xgp-web-7d478f5bb7-bd4bj

原文地址：https://blog.51cto.com/14320361/2465238

时间： 2024-10-06 05:31:38

k8d创建资源(3)（负载均衡原理，回滚指定版本，label控制pod的位置）的相关文章

通过svn回滚指定版本

右击文件(也可以是文件夹),TortoiseSVN – show log,右击你想要回滚到的版本. “Revert to this revision”,这个比较好理解,也比较常用.就是把文件恢复到某个版本,然后commit,文件就回滚成功了.回滚成功后,所有的历史还存在.例如回滚到版本4,commit之后,会出现新的版本6,但是他的内容和版本4是一样的 原文地址:https://www.cnblogs.com/ynyhl/p/12169796.html

使用LVS实现负载均衡原理及安装配置详解

转:http://www.cnblogs.com/liwei0526vip/p/6370103.html 使用LVS实现负载均衡原理及安装配置详解 负载均衡集群是 load balance 集群的简写,翻译成中文就是负载均衡集群.常用的负载均衡开源软件有nginx.lvs.haproxy,商业的硬件负载均衡设备F5.Netscale.这里主要是学习 LVS 并对其进行了详细的总结记录. 一.负载均衡LVS基本介绍 LB集群的架构和原理很简单,就是当用户的请求过来时,会直接分发到Director

使用 LVS 实现负载均衡原理及安装配置详解

使用 LVS 实现负载均衡原理及安装配置详解 来源:肖邦linux 发布时间:2017-02-19 阅读次数:106 0 负载均衡集群是 load balance 集群的简写,翻译成中文就是负载均衡集群.常用的负载均衡开源软件有nginx.lvs.haproxy,商业的硬件负载均衡设备F5.Netscale.这里主要是学习 LVS 并对其进行了详细的总结记录. 一.负载均衡LVS基本介绍 LB集群的架构和原理很简单,就是当用户的请求过来时,会直接分发到Director Server上,然后它把用

[转]f5负载均衡原理

f5负载均衡原理 一. 负载均衡技术 负载均衡技术在现有网络结构之上提供了一种廉价.有效.透明的方法,来扩展网络设备和服务器的带宽.增加吞吐量.加强网络数据处理能力.提高网络的灵活性和可用性. 1. 负载均衡发生的流程图: 1. 客户发出服务请求到VIP 2.BIGIP接收到请求,将数据包中目的IP地址改为选中的后台服务器IP地址,然后将数据包发出到后台选定的服务器 3. 后台服务器收到后,将应答包按照其路由发回到BIGIP 4.BIGIP收到应答包后将其中的源地址改回成VIP的地址,发回客户端

RestTemplate 负载均衡原理

RestTemplate负载均衡原理 RestTemplate为什么具有负载均衡的功能? 在使用了@LoadBalanced后,Spring容器在启动的时候会为被修饰过的RestTemplate添加拦截器,拦截器里会使用LoadBalanced相关的负载均衡接口来处理请求,通过这样一个间接的处理,会使原来的RestTemplate变得不是原来的RestTemplate了,就变的更NB了,因此具备了负载均衡的功能.那么在这章的内容中呢,笔者将带大家实现一个很简单的LoadBalanced注解,为R

搞懂分布式技术9：Nginx负载均衡原理与实践

搞懂分布式技术9:Nginx负载均衡原理与实践 本篇摘自<亿级流量网站架构核心技术>第二章 Nginx负载均衡与反向代理 部分内容. 当我们的应用单实例不能支撑用户请求时,此时就需要扩容,从一台服务器扩容到两台.几十台.几百台.然而,用户访问时是通过如的方式访问,在请求时,浏览器首先会查询DNS服务器获取对应的IP,然后通过此IP访问对应的服务. 因此,一种方式是域名映射多个IP,但是,存在一个最简单的问题,假设某台服务器重启或者出现故障,DNS会有一定的缓存时间,故障后切换时间长,而且没有对

[转]Nginx负载均衡原理初解

什么是负载均衡 我们知道单台服务器的性能是有上限的,当流量很大时,就需要使用多台服务器来共同提供服务,这就是所谓的集群. 负载均衡服务器,就是用来把经过它的流量,按照某种方法,分配到集群中的各台服务器上.这样一来不仅可以承担 更大的流量.降低服务的延迟,还可以避免单点故障造成服务不可用.一般的反向代理服务器,都具备负载均衡的功能. 负载均衡功能可以由硬件来提供,比如以前的F5设备.也可以由软件来提供,LVS可以提供四层的负载均衡(利用IP和端口), Haproxy和Nginx可以提供七层的负载均

负载均衡原理的解析

开头先理解一下所谓的“均衡” 不能狭义地理解为分配给所有实际服务器一样多的工作量,因为多台服务器的承载能力各不相同,这可能体现在硬件配置.网络带宽的差异,也可能因为某台服务器身兼多职,我们所说的“均衡”,也就是希望所有服务器都不要过载,并且能够最大程序地发挥作用. 一.http重定向 当http代理(比如浏览器)向web服务器请求某个URL后,web服务器可以通过http响应头信息中的Location标记来返回一个新的URL.这意味着HTTP代理需要继续请求这个新的URL,完成自动跳转. 性能缺

六大Web负载均衡原理与实现

开头先理解一下所谓的"均衡" 不能狭义地理解为分配给所有实际服务器一样多的工作量,因为多台服务器的承载能力各不相同,这可能体现在硬件配置.网络带宽的差异,也可能因为某台服务器身兼多职,我们所说的"均衡",也就是希望所有服务器都不要过载,并且能够最大程序地发挥作用. 一.http重定向 当http代理(比如浏览器)向web服务器请求某个URL后,web服务器可以通过http响应头信息中的Location标记来返回一个新的URL.这意味着HTTP代理需要继续请求这个新的