Linux云计算 |【第五阶段】CLOUD-DAY8

主要内容:

掌握DaemonSet控制器、污点策略(NoSchedule、Noexecute)、Job / CronJob资源对象、掌握Service服务、服务名解析CluterIP(服务名自动发现)、(Nodeport、Headless)、Ingress控制器

一、DaemonSet控制器

DaemonSet在每个机器都要启动运行Pod时,确保全部或一些Node上运行Pod副本当有Node节点加入集群时,也会为他新增Pod副本,当Node从集群移除时,这些Pod也会被回收;(有多少个Node节点,就在每个节点上运行Pod副本)

删除DaemonSet控制器时,将删除所有它创建的Pod副本;

典型应用:Ceph节点、监控节点、Filebeat日志收集等;

系统服务:Kube-proxy和Flannel就是这种类型;

DaemonSet与Deployment在编写配置文件时非常相似,区别是不需要配置replicas参数POD副本数,因为DaemonSet是每节点启动Pod副本;

  • 格式:kubectl -n kube-system get daemonsets.apps     //查看DaemonSet控制器

补充:查询daemonsets.apps发现flannel和proxy的每个节点都创建了Pod副本,且没有二级控制器RS;(架构:daemonset-pod)

DaemonSet资源文件模板


编写DaemonSet资源文件示例:

[root@master ~]# vim mynginx.yaml
---                     //资源定义起始标志
kind: DaemonSet         //创建资源的类型(DaemontSet控制器,注意大小写)
apiVersion: apps/v1     //控制器资源类型的版本
metadata:               //控制器资源的元数据name: mynginx         //控制器资源的名称(mynginx)
spec:                   //控制器资源的详细定义selector:             //声明资源匹配选择器matchLabels:        //资源方式:匹配标签myapp: nginx     //为服务的后端选择标签(具体匹配的标签,与labels要一致)template:            //POD资源模板定义metadata:          //POD资源的元数据labels:          //声明定义标签myapp: nginx   //标签名(与matchLabels要一致)spec:              //容器的详细定义containers:             //容器定义- name: nginxcluster    //容器名称image: 192.168.1.100:5000/myos:nginx    //启动容器的镜像地址stdin: false        //标准输入,默认falsetty: false          //终端,默认falseports:              //服务端口定义- protocol: TCP      //服务使用的协议containerPort: 80   //容器监听的端口号restartPolicy: Always    //容器的死亡策略[root@master ~]# kubectl apply -f mynginx.yaml
daemonset.apps/mynginx created
[root@master ~]# kubectl get pod -o wide

# DaemonSet控制器自动为所有节点上运行Pod副本;

[root@master ~]# kubectl get daemonsets.apps
NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
mynginx   3         3         3       3            3           <none>          12m

# 测试效果

[root@master ~]# curl http://10.244.2.13
this is nginx
[root@master ~]# curl http://10.244.1.11
this is nginx
[root@master ~]# curl http://10.244.3.19
this is nginx

思考:

在查询Pod资源时,发现Proxy和Flannel的Pod资源是有4个Pod副本;而执行编写的daemonset资源文件时,只有3个副本;DaemonSet调度器调度到除Master以外的所有节点,因希望Master节点除了一些系统服务以外,不会再有其它的POD副本,防止其它消耗高的POD抢占资源;而默认在Master上设置了污点策略,所以其它POD副本不会在Master上部署;

二、污点策略

1、污点标签

NoSchedule:不会被调度(容器创建时有效)

PreferNoSchedule:尽量不调度(容器创建时有效)

NoExecute:驱逐节点(容器创建、运行时都有效),针对不同控制器有不同效果;

1)查看污点标签

  • - 格式:kubectl describe nodes | grep -P "^Taints"
  • - 格式:kubectl describe node [node-name]    //查看节点详细信息(Taints)

2)设置污点标签

- 格式:kubectl taint node =

删除污点标签

- 格式:kubectl taint node -


示例1:污点标签NoSchedule配置(创建容器时有效)

① 设置污点标签(在daemonset的资源文件上测试)

[root@master ~]# kubectl delete -f mynginx.yaml    //删除资源,重新创建
daemonset.apps "mynginx" deleted
[root@master ~]# kubectl describe nodes | grep -P "^Taints"

[root@master ~]# kubectl taint node node-0001 k1=v1:NoSchedule   //设置污点标签
node/node-0001 tainted
[root@master ~]# kubectl describe nodes | grep -P "^Taints"

[root@master ~]# kubectl apply -f mynginx.yaml
daemonset.apps/mynginx created
[root@master ~]# kubectl get pods   //设置污点标签后,只有2节点有POD副本
NAME            READY   STATUS    RESTARTS   AGE
mynginx-6j8h4   1/1     Running   0          9s
mynginx-8g2wc   1/1     Running   0          9s

② 删除污点标签

[root@master ~]# kubectl taint node node-0001 k1-
node/node-0001 untainted

[root@master ~]# kubectl get pods   //移除污点标签后,3节点都有POD副本
NAME            READY   STATUS    RESTARTS   AGE
mynginx-6j8h4   1/1     Running   0          68s
mynginx-8g2wc   1/1     Running   0          68s
mynginx-z4k4k   1/1     Running   0          39s

解释:为node-0001节点设置NoSchedule污点标签后,在创建容器时,不会对该节点调度创建Pod副本;移除NoSchedule污点标签后,会自动重新调度分配Pod副本;


示例2:污点标签NoExecute配置(创建、运行容器时都有效)

针对不同的控制器配置污点标签NoExecute会有不同效果

[root@master ~]# kubectl get pod    //当前运行的Pod容器(DaemonSet控制器)
NAME            READY   STATUS    RESTARTS   AGE
mynginx-6j8h4   1/1     Running   0          64m
mynginx-8g2wc   1/1     Running   0          64m
mynginx-z4k4k   1/1     Running   0          64m[root@master ~]# kubectl apply -f myapache.yaml   //执行Deployment资源
deployment.apps/myapache created
[root@master ~]# kubectl scale deployment myapache --replicas=3
deployment.apps/myapache scaled
[root@master ~]# kubectl get pod -o wide    //查看Pod资源信息

[root@master ~]# kubectl taint node node-0003 k1=v1:NoExecute   //设置污点
node/node-0003 tainted
[root@master ~]# kubectl get pod -o wide

解释:在POD容器运行时,为node-0003节点设置NoExecute污点标签后,针对Deployment控制器,0003节点被驱逐,并按照Deployment控制器的规则在另一节点重建Pod副本,为满足高可用,保证副本为3;针对Daemonset控制器,0003节点被驱逐,但并未创建额外的副本;

[root@master ~]# kubectl taint node node-0003 k1-
node/node-0003 untainted
[root@master ~]# kubectl get pod -o wide

解释:为node-0003节点移除NoExecute污点标签后,针对Deployment控制器,继续使用另外节点重建的Pod副本;针对Daemonset控制器,为0003节点创建Pod副本;

2、容忍污点

某些时候需要无视污点标签进行操作,这种方式称为对污点的容忍;

节点亲和性是Pod 的一种属性,它使 Pod 被吸引到一类特定的节点。这可能出于一种偏好,也可能是硬性要求。Taint(污点)则相反,它使节点能够排斥一类特定的Pod。

容忍度(Tolerations)是应用于 Pod 上的,允许(但并不要求)Pod 调度到带有与之匹配的污点的节点上。

污点和容忍度(Toleration)相互配合,可以用来避免 Pod 被分配到不合适的节点上。 每个节点上都可以应用一个或多个污点,这表示对于那些不能容忍这些污点的 Pod,是不会被该节点接受的;

容忍污点资源文件模板:

三、Job / CronJob资源对象

1、Job资源对象

Job也称为单任务控制器,负责执行一次任务,保证任务在一个或多个Pod上执行成功;如果运行一个Pod,当第一个Pod失败或者被删除(比如因接待硬件失效或重启)时,Job对象会启动一个新的Pod,直到这个任务完成Completed;

删除Job控制器的操作,会清除所创建的全部Pods;

  • - 格式:kubectl get job.batch    //查看Job控制器

Job资源文件模板(架构:Job - pod)

补充:command 可以替换容器默认启动命令


编写Job资源文件示例:

[root@master ~]# vim myjob.yaml
---
apiVersion: batch/v1     //资源类型的版本
kind: Job                //资源的类型(Job)
metadata:                //控制器的元数据name: pi               //控制器的名称
spec:                    //控制器资源的详细定义template:              //POD资源模板定义spec:                //容器的详细定义containers:       //容器定义- name: piimage: 192.168.1.100:5000/myos:v1804command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]   //替换默认启动命令,打印输出π到2000位;restartPolicy: OnFailure    //容器重启策略,只支持[OnFailure,Nerver][root@master ~]# kubectl apply -f myjob.yaml
job.batch/pi created
[root@master ~]# kubectl get job.batch
NAME   COMPLETIONS   DURATION   AGE
pi     1/1           9s         10s
[root@master ~]# kubectl get pod
NAME                       READY   STATUS      RESTARTS   AGE
pi-246kc                   0/1     Completed   0          19s

# 验证效果

[root@master ~]# kubectl logs pi-246kc    //打印输出结构显示在终端

补充:K8S核心为POD,POD外层使用不同控制器实现不同应用;

2、CronJob资源对象

CronJob重复多次任务控制器,像是Job的升级版,是基于时间管理的Job;

典型用法:Crontab周期性计划任务

CronJob的本质是在约定的时间创建Job;

在Job中会保留最后三次的状态,并进行滚动更新,其它会被清除;

CronJob资源文件模板(架构:CronJob - Job - Pod)


编写CronJob资源文件示例:

[root@master ~]# vim mycronjob.yaml
---                         //资源定义起始标志
apiVersion: batch/v1beta1   //资源类型的版本
kind: CronJob               //控制器资源类型(CronJob)
metadata:                   //控制器资源的元数据name: cronjob-pi          //控制器资源的名称
spec:                       //CronJob的详细定义schedule: "*/1 * * * *"   //每分钟创建一个JobjobTemplate:              //Job资源模板定义spec:                  //Job资源的详细定义template:            //POD资源模板定义spec:              //容器的详细定义containers:- name: piimage: 192.168.1.100:5000/myos:v1804command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]restartPolicy: OnFailure[root@master ~]# kubectl apply -f mycronjob.yaml
cronjob.batch/cronjob-pi created
[root@master ~]# kubectl get cronjobs.batch
NAME         SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cronjob-pi   */1 * * * *   False     0        <none>          5s
[root@master ~]# kubectl get pod
NAME                          READY   STATUS      RESTARTS   AGE
cronjob-pi-1625464980-266ss   0/1     Completed   0          9s   //Completed完成

其他资源对象

1)StatefulSet有状态服务相关POD

- 为了解有状态服务设计的一种控制器

- 基于PVC的稳定持久化存储

- 稳定的网络标志,基于Headless Service

- 有序部署,有序扩展/收缩(基于init containers实现)

2)Horizontal Pod Autoscaling控制器

- 自动扩展,可以根据业务的高峰和低谷自动水平扩展Pod节点,提高资源利用率;

四、Service服务与负载均衡

1、服务使用场景

使用Deployment控制器在创建简单WEB集群时,多副本会自动调度分配到不同主机上

例如:使用scale创建2副本实验

[root@master ~]# kubectl apply -f myapache.yaml
deployment.apps/myapache created
[root@master ~]# kubectl scale deployment myapache --replicas=2
deployment.apps/myapache scaled
[root@master ~]# kubectl get pod -o wide

[root@master ~]# kubectl delete pod myapache-7d689bf8f-rt2vw
pod "myapache-7d689bf8f-rt2vw" deleted
[root@master ~]# kubectl get pod -o wide

说明:当发现某一个Pod不能使用的时候,RS控制器会在其它机器上再创建一个相同的Pod及其对应的容器(IP端、分配节点发生变化),会变化的Pod给用户访问带了非常多的不便;

2、Service资源文件

Service就是解决该问题的办法(Service的本质就是LVS负载均衡),会创建一个Cluster IP,这个地址对应资源地址,不管Pod如何变化,Service总能自动发现找到对应的Pod,且Cluster IP保持不变,如果有Pod对应多个容器,Service会自动在多个容器间实现负载均衡;(主要功能:自动发现、负载均衡)

原理:Service通过 IPTABLES / LVS 规则将访问的请求最终映射到Pod的容器内部服务上。

1)创建Service服务

  • - 格式:kubectl apply -f Service的资源文件

2)查询Service服务

  • - 格式:kubectl get service

定义Service服务资源文件模板

解释说明:Service服务的端口

① port:Service开放在前端的Cluster IP上端口,是提供给集群内部客户访问Service的入口,提供集群内部服务访问使用(类似VIP:port)

② targetPort:是后端Pod上容器服务监听的端口,从port或nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort进入容器,从而达到访问Pod容器内部服务的目的;


编写Service服务资源文件示例:

注意:服务创建前,必须要基于运行的容器应用集群

[root@master ~]# vim clusterip.yaml
---
kind: Service        //定义Service资源类型
apiVersion: v1       //类型的版本
metadata:            //类型的元数据name: myapache     //类型的名称
spec:                //类型的详细定义ports:             //Service服务的端口- protocol: TCP      //后端服务所使用的协议,需要一致port: 80          //前端监听的服务端口号targetPort: 80    //后端目标主机的服务端口号selector:           //选择为哪个deployment提供服务(后端)myapp: httpd      //标签必须与deployment资源文件中一致(mypod)type: ClusterIP     //服务类型(ClusertIP)[root@master ~]# kubectl apply -f clusterip.yaml
service/myapache created
[root@master ~]# kubectl get service

# 访问Service服务

Service服务只有在集群内部才可以访问,集群外无法访问服务(LVS-NAT网络架构有关 )

[root@master ~]# kubectl get pod -o wide       //查看集群容器

[root@master ~]# kubectl apply -f mypod.yaml    //创建Pod,并在Pod容器中访问服务
pod/mypod created
[root@master ~]# kubectl exec -it mypod -- /bin/bash
[root@mypod /]# curl http://10.254.106.60/info.php    //验证Service服务的轮询效果
<pre>
Array
([REMOTE_ADDR] => 10.244.3.30[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-gmgz9    //POD容器名
1229[root@mypod /]# curl http://10.254.106.60/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.3.30[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-k2vzw    //POD容器名
1229

# 删除其中一台容器,等待控制器重建,并测试Service服务的自动发现和负载均衡

[root@master ~]# kubectl delete pod myapache-7d689bf8f-k2vzw
pod "myapache-7d689bf8f-k2vzw" deleted
[root@master ~]# kubectl get pod -o wide

[root@master ~]# kubectl exec -it mypod -- /bin/bash
[root@mypod /]# curl http://10.254.106.60/info.php     //验证Service服务的轮询效果
<pre>
Array
([REMOTE_ADDR] => 10.244.3.30[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-hprkc    //POD容器名
1229[root@mypod /]# curl http://10.254.106.60/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.3.30[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-gmgz9    //POD容器名
1229

多个资源可以写到同一个YAML文件,使用【---】分割,用一个文件管理2个服务

补充:一般情况下,先创建Deployment,再创建Service,实现Service资源为Deployment资源提供服务,方便2个服务的管理;

— 示例:多资源文件

① 清除原来的资源文件配置

[root@master ~]# kubectl delete -f myapache.yaml
[root@master ~]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
mypod   1/1     Running   0          8h

② 使用重定向方式,将2个资源服务写到同一个YAML文件

[root@master ~]# cat clusterip.yaml >> myapache.yaml   //重定向追加方式
---
kind: Deployment       //定义Deployment资源类型
apiVersion: apps/v1
metadata:name: myapache
spec:selector:matchLabels:myapp: httpdreplicas: 2        //副本数为2template:metadata:labels:myapp: httpdspec:containers:- name: webclusterimage: 192.168.1.100:5000/myos:httpdstdin: falsetty: falseports:- protocol: TCPcontainerPort: 80restartPolicy: Always---
kind: Service      //定义Service资源类型
apiVersion: v1
metadata:name: myapache
spec:ports:- protocol: TCPport: 80targetPort: 80selector:myapp: httpdtype: ClusterIP[root@master ~]# kubectl apply -f myapache.yaml
deployment.apps/myapache created
service/myapache created
[root@master ~]# kubectl get pod      //查看Pod资源

[root@master ~]# kubectl get service    //查看Service服务

3、服务自动发现

主要目的:通过Service服务名称代替Cluster-IP)

Cluster-IP是集群分配的服务IP,提供前端集群访问;因Cluster-IP也是随机分配的,固定IP不太可取,所以K8S内部有服务的域名注册功能,推荐使用服务名称来当Cluster-IP;在集群内部通过服务的名称访问,服务的名称是通过coredns解析,每个服务在创建的过程中都会完成自动注册;

  • 服务名称:..svc.cluster.local

例:ClusterIP 10.254.69.188:80 = myapache.default.svc.cluster.local

解释:服务名称.default命名空间.service.cluster.local

[root@master ~]# kubectl get service

cluster.local在Master初始化配置文件中定义

[root@master ~]# vim init/kubeadm-init.yaml


示例:通过服务名称来代替ClusterIP访问集群容器

[root@master ~]# kubectl exec -it mypod -- /bin/bash
[root@mypod /]# curl http://myapache.default.svc.cluster.local
this is apache

# 因/etc/resolv.conf域名配置文件默认已加search搜索头,搜索域名后缀(自动补齐)

[root@mypod /]# cat /etc/resolv.conf
nameserver 10.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options ndots:5[root@mypod /]# curl http://myapache
this is apache
[root@mypod /]# ping myapache

补充:search可以将搜索的名称和域名配置文件的域名进行拼接搜索;

五、服务原理

1、代理模式种类

① Kubernetes v1.0 服务支持userspace代理模式(用户命名空间)

  • 数据流向:Client-> ClusterIP-> kube-proxy-> 容器

补充:图中Kube-proxy在集群中起到调度负载均衡作用,并需要与Apiserver进行通信,Apiserver能获取POD容器的地址并存入ETCD数据库,根据ETCD跟踪容器地址;但遇到大并发高负载的情况,Kube-proxy并不优于LVS专门的负载均衡器,所以性能就变差了;

② Kubernetes v1.1 服务支持iptables代理模式

  • 数据流向:Client-> ClusterIP--(旁路模式kube-proxy)-> 容器

补充:图中Kube-proxy在集群中负责修改IPTABLES规则,不负责流量数据转发;集群中通过IPTABLES来进行端口转发;

③ Kubernetes v1.8 服务支持ipvs代理模式

  • 数据流向:Client-> ClusterIP--(旁路模式kube-proxy)-> 容器

补充:图中Kube-proxy在集群中负责修改LVS规则,不负责流量数据转发;集群中通过LVS来进行调度转发;

补充:在Kubernetes v1.2中,kube-proxy的iptables模式成为默认设置,现阶段默认使用ipvs,如果不能满足要求回退至iptables模式;

说明:Service服务本质就是LVS负载均衡,而Kube-proxy就是负责修改LVS规则;

[root@master ~]# ipvsadm-save -n | grep 10.254.69.188
-A -t 10.254.69.188:80 -s rr
-a -t 10.254.69.188:80 -r 10.244.1.15:80 -m -w 1    //集群容器RIP地址
-a -t 10.254.69.188:80 -r 10.244.2.20:80 -m -w 1    //集群容器RIP地址
[root@master ~]# kubectl get pod -o wide

2、服务类型

Service允许指定一个Type类型(一般默认是ClusterIP)

① ClusterIP:通过集群的内部IP暴露服务,但服务只能够在集群内部可以访问,这也是默认的ServiceType;

② NodePort:通过每个Node上的IP和静态端口暴露服务,NodePort服务会路由到ClusterIP服务,可以对外提供服务;

③ LoadBalancer:使‘用云提供商的负载均衡器,如华为云容器引擎CCE,外部的负载均衡器可以路由到NodePort服务和Cluster服务;(对外提供服务)

1)nodePort服务

场景:之前构建的服务已可以在集群内部运转,但集群外还无法访问集群内部的服务;有时候,服务可能来自第三方或其他团队,我们无法把所有服务都放入集群内部里,这时就需要集群内部和集群外部的服务能够实现互相访问;

- LoadBalancer:使用外部的云服务(需支持externallPs)

- nodePort:基于端口对外提供服务(四层)(端口映射)

- Ingress:使用ingress控制器(七层)(本质为Nginx)

nodePort服务资源文件模板:


编写nodePort服务资源文件示例:
[root@master ~]# vim mynodeport.yaml
---
kind: Service         //定义资源的类型
apiVersion: v1
metadata:name: mynodeport    //资源的名称
spec:ports:- protocol: TCPport: 80targetPort: 80selector:           //选择为哪个deployment提供服务(后端)myapp: httpd      //标签必须与deployment资源文件中一致(mypod)type: NodePort      //指定服务类型(NodePort)[root@master ~]# kubectl apply -f mynodeport.yaml
service/mynodeport created
[root@master ~]# kubectl get service

补充:80为访问容器服务的端口,30705为对外发布访问集群的端口;

# K8S中所有节点都是LVS负载均衡器,通过Node节点30705端口均可访问集群容器

[root@ecs-proxy ~]# curl http://192.168.1.31:30705/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.1.0[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-sn2xn    //POD容器
1229[root@ecs-proxy ~]# curl http://192.168.1.32:30705/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.2.0[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-lwpb8    //POD容器
1229[root@ecs-proxy ~]# curl http://192.168.1.33:30705/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.3.0[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-sn2xn    //POD容器
1229

补充:集群服务图例

2)Headless服务

场景:有时候不需要或不想要负载均衡,以及单独的Cluster IP,可以创建Headless服务;

原理:Headless服务会把IP通过多个A记录的形式解析到具体的容器IP上,多用于有状态的服务;

主要目的:用户通过headless服务,解析到容器IP,不需要使用ClusterIP,不使用负载均衡,直接访问容器;

Headless服务资源文件模板


编写headless 服务资源文件示例:
[root@master ~]# vim myheadless.yaml
---
kind: Service           //定义资源的类型
apiVersion: v1
metadata:name: myheadless      //资源的名称
spec:ports:- protocol: TCPport: 80targetPort: 80selector:            //选择为哪个deployment提供服务(后端)myapp: httpd       //标签必须与deployment资源文件中一致(mypod)type: ClusterIP      //类型为ClusterIPclusterIP: None      //设置None[root@master ~]# kubectl apply -f myheadless.yaml
service/myheadless created
[root@master ~]# kubectl get service

# 进入pod查看解析结果

[root@master ~]# kubectl exec -it mypod -- /bin/bash
[root@mypod /]# yum install -y bind-utils   //软件包含host命令,用来解析域名
[root@mypod /]# host myheadless.default.svc.cluster.local
myheadless.default.svc.cluster.local has address 10.244.2.20
myheadless.default.svc.cluster.local has address 10.244.1.15

五、Ingress插件

1、Ingress介绍

Ingress公开了从集群外部到集群内service路由,实现负载均衡;Ingress本质是Nginx,所以只能发布7层的web服务,也可以将Ingress配置为提供服务外部可访问的URL、负载均衡流量;

Ingress控制器通常由负载均衡器来实现;必须具有ingress控制器才能满足Ingress的要求,仅创建资源无效;

Ingress镜像地址:https://github.com/kubernetes/ingress-nginx

  • 格式:kubectl get ingresses //查看ingress控制器 

架构图:

说明:用户直接访问Ingress控制器,由于是7层的负载均衡,控制器上可以实现基于域名的负载均衡,每个域名对应一个Service(Cluster IP),再对应POD资源;


示例:配置Ingress控制器

① 安装控制器

# 拷贝云盘 kubernetes/v1.17.6/ingress 文件夹到 master上,导入镜像到私有仓库

[root@ecs-proxy v1.17.6]# rsync -av ingress 192.168.1.21:/root
[root@master ~]# tree ingress/
ingress/
├── ingress-example.yaml
├── ingress-nginx.tar.gz    //ingress控制器镜像文件
├── ingress-service.yaml
└── mandatory.yaml       //ingress资源文件
0 directories, 4 files

② 导入镜像到私有仓库

[root@master ~]# cd ingress/
[root@master ingress]# docker load -i ingress-nginx.tar.gz
[root@master ingress]# docker tag quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0 192.168.1.100:5000/nginx-ingress-controller:0.30.0
[root@master ingress]# docker push 192.168.1.100:5000/nginx-ingress-controller:0.30.0
[root@master ingress]# curl http://192.168.1.100:5000/v2/nginx-ingress-controller/tags/list
{"name":"nginx-ingress-controller","tags":["0.30.0"]}

③ 修改资源配置文件

[root@master ingress]# vim mandatory.yaml
221:  image: 192.168.1.100:5000/nginx-ingress-controller:0.30.0  //修改为私有镜像地址

④ 执行资源配置文件

# ingress指定创建命名空间ingress-nginx,并把所有的Pod放在该命名空间内

[root@master ingress]# kubectl apply -f mandatory.yaml
[root@master ingress]# kubectl get namespaces    //查看命名空间
NAME              STATUS   AGE
default           Active   4d14h
ingress-nginx     Active   106s
kube-node-lease   Active   4d14h
kube-public       Active   4d14h
kube-system       Active   4d14h
[root@master ingress]# kubectl -n ingress-nginx get pod   //查看POD资源
NAME                                      READY   STATUS    RESTARTS   AGE
nginx-ingress-controller-fc6766d7-rq4v5   1/1     Running   0          2m13s

⑤ 通过ingress控制器映射集群内web服务,发布服务

[root@master ingress]# vim ingress-example.yaml
---
apiVersion: extensions/v1beta1    //资源的版本
kind: Ingress            //定义资源的版本
metadata:name: my-web           //资源的名称annotations:kubernetes.io/ingress.class: "nginx"
spec:backend:serviceName: myapache    //Service服务名
servicePort: 80
root@master ingress]# kubectl apply -f ingress-example.yaml
ingress.extensions/my-app created
[root@master ingress]# kubectl get ingresses
NAME     HOSTS   ADDRESS        PORTS   AGE
my-app   *       192.168.1.33   80      89s

# 测试服务,及轮询效果

[root@master ingress]# curl http://192.168.1.33/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.3.0[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-lwpb8
1229[root@master ingress]# curl http://192.168.1.33/info.php
<pre>
Array
([REMOTE_ADDR] => 10.244.3.0[REQUEST_METHOD] => GET[HTTP_USER_AGENT] => curl/7.29.0[REQUEST_URI] => /info.php
)
php_host:       myapache-7d689bf8f-sn2xn
1229

扩展知识

  • Ingress本质是nginx / haproxy 实现的负载均衡
  • Ingress可以设置七层规则,例如根据域名选择服务

小结:

本篇章节为【第五阶段】CLOUD-DAY8 的学习笔记,这篇笔记可以初步了解到 DaemonSet控制器、污点策略(NoSchedule、Noexecute)、Job / CronJob资源对象、掌握Service服务、服务名解析CluterIP(服务名自动发现)、(Nodeport、Headless)、Ingress控制器,除此之外您还可以参考以下内容:

  • 污点和容忍度 | Kubernetes

Tip:毕竟两个人的智慧大于一个人的智慧,如果你不理解本章节的内容或需要相关笔记、视频,可私信小安,请不要害羞和回避,可以向他人请教,花点时间直到你真正的理解。

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

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

相关文章

机器学习1_机器学习定义——MOOC

一、机器学习定义 定义一 1959年Arthur Samuel提出机器学习的定义&#xff1a; Machine Learning is Fields of study that gives computers the ability to learn without being explicitly programmed. 译文&#xff1a;机器学习是这样的领域&#xff0c;它赋予计算机学习的…

无人机维护保养、部件修理更换技术详解

无人机作为一种精密的航空设备&#xff0c;其维护保养和部件修理更换是确保飞行安全、延长使用寿命的重要环节。以下是对无人机维护保养、部件修理更换技术的详细解析&#xff1a; 一、无人机维护保养技术 1. 基础构造理解&#xff1a; 熟悉无人机的基本构造&#xff0c;包括…

HCIP--以太网交换安全(总实验)

实验背景 假如你是公司的网络管理员&#xff0c;为了提高公司网络安全性&#xff0c;你决定在接入交换机部署一些安全技术&#xff1a;端口隔、端口安全、DHCP snooping、IPSG。 实验拓扑图 实验的要求&#xff1a; 1.在R1、R2连接在GE0/0/1和GE0/0/2接口下&#xff0c;均划…

Qt中的Model与View 3:从样例出发理解QStringListModel和QListView

目录 Ui文件设计如下&#xff1a; 初始化窗口 这里&#xff0c;就是一经典的例子 你可以看到&#xff0c;我们的环境变量是一个经典的List列表&#xff0c;其中承载的就是我们的字符串。我们现在来仿照着搞一个&#xff1a; Ui文件设计如下&#xff1a; 我们下面来逐一演示用…

【VSCode】配置

安装插件 C vscode-icons gdb调试 https://www.bilibili.com/video/BV15U4y1x7b2/?spm_id_from333.999.0.0&vd_sourcedf0ce73d9b9b61e6d4771898f1441f7f https://www.bilibili.com/video/BV1pU4y1W74Z?spm_id_from333.788.recommend_more_video.-1&vd_sourcedf0…

【开发心得】筑梦上海:项目风云录(10)

目录 经典代码背后的故事 贵人相助与价值创造的跳槽哲学 从甲方现场到职场晋升 经典代码背后的故事 写完上一篇故事,本来想休息一段时间,再把思路整理一下。 但是感觉前面的故事里,涉及的故事多,涉及的技术和代码少,很多小伙伴私信希望能够多一些技术和代码的分享。 好…

编译原理第一次实验报告

源代码及附件&#xff1a;编译原理实验一源程序及附件资源-CSDN文库实验题目 实验要求 实验设计 前两部分指出了实验的宏观把控&#xff0c;为了具体实施实验&#xff0c;我们需要预先为实验做出如下设计&#xff1a; 本次实验我选取了C语言的一个子集进行设计词法分析器&…

Elastix-基于ITK的医学图像配准库

作者&#xff1a;翟天保Steven 版权声明&#xff1a;著作权归作者所有&#xff0c;商业转载请联系作者获得授权&#xff0c;非商业转载请注明出处 Elastix是什么&#xff1f; Elastix是一个广泛使用的医学图像配准库&#xff0c;旨在帮助研究人员和临床医生处理和分析医学影像…

清华双臂机器人扩散大模型RDT:先预训练后微调,支持语言、图像、动作多种输入

前言 通过上文介绍的GR2&#xff0c;我们看到了视频生成模型在机器人训练中的应用&#xff0c;无独有偶&#xff0c;和GR2差不多一个时期出来的清华RDT&#xff0c;其模型架构便基于视频生成架构DiT改造而成(当然&#xff0c;该清华团队其实也在DiT之前推出了U-ViT&#xff0c…

远程连接服务

目录 一、远程连接服务器简介 二、连接加密技术简介 三、认证阶段 四、ssh实验 1.修改ssh服务器的端口号 2.拒绝root账户远程登录 3.允许特定用户ssh登录&#xff0c;其他用户无法登录 4.ssh-keygen 一、远程连接服务器简介 概念&#xff1a; 远程连接服务器通过文字或…

YOLOv5之Common.py

文章目录 1.学习目的2.网络模型![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/67b8dbd00c9b4034ba370fc8b8a6031a.jpeg)3.common.py分析 1.学习目的 YOLOv5中最关键一个模型类 2.网络模型 3.common.py分析 # Ultralytics YOLOv5 &#x1f680;, AGPL-3.0 license…

获取Windows计算机信息的一些常用命令

一、获取Windoiws计算机基本信息 1.1、获取系统详细信息 # systeminfo的详细用法帮助命令 systeminfo /? 通过获取系统信息可以了解系统版本内容、硬件信息、域信息和补丁情况。 systeminfo 1.2、获取系统已经启动的服务 # net的详细用法帮助命令 net /? 1.2.1、获取系…

通过 codespaces + ipad 来进行算法训练

目录 零、前言 一、环境搭建 二、DockerFile 2.1 主要流程 2.2 个人模板 零、前言 最近遇到了翘不了的水课&#xff0c;想在课上写题&#xff0c;但是游戏本一个是太重&#xff0c;一个是续航不行&#xff0c;然后想到了在Ipad 上通过云IDE来码题。 一开始用的腾讯云的 C…

部署Prometheus、Grafana、Zipkin、Kiali监控度量Istio

1. 模块简介 Prometheus 是一个开源的监控系统和时间序列数据库。Istio 使用 Prometheus 来记录指标&#xff0c;跟踪 Istio 和网格中的应用程序的健康状况。Grafana 是一个用于分析和监控的开放平台。Grafana 可以连接到各种数据源&#xff0c;并使用图形、表格、热图等将数据…

深入理解Redis的四种模式

Redis是一个内存数据存储系统&#xff0c;支持多种不同的部署模式。以下是Redis的四种主要部署模式。 1、单机模式 单机模式是最简单的部署模式&#xff0c;Redis将数据存储在单个节点上。这个节点包括一个Redis进程和一个持久化存储。单机模式非常适合小型应用程序或者开发和…

uln2003驱动28BYJ-48步进电机

欢迎入群共同学习交流 时间记录&#xff1a;2024/11/2 一、模块解析 1.uln2003 E脚&#xff1a;接GND COM脚&#xff1a;接VCC外部电源 1-7B&#xff1a;输入引脚 1-7C&#xff1a;输出引脚&#xff0c;输入与输出反向 无法输出高电平&#xff0c;外围电路需要接上拉电路…

使用 PyCharm 构建 FastAPI 项目:零基础入门 Web API 开发

使用 PyCharm 构建 FastAPI 项目&#xff1a;零基础入门 Web API 开发 本文提供了一份完整的 FastAPI 入门指南&#xff0c;涵盖从环境搭建、依赖安装到创建并运行一个简单的 FastAPI 应用的各个步骤。通过 FastAPI 和 Uvicorn&#xff0c;开发者可以快速构建现代化的 Web API…

SAP ABAP开发学习——BAPI

目录 业务对象 概念 ​编辑业务对象浏览 BAPI BAPI的浏览 BAPI的调用 BAPI的确认和返回 BAPI的创建 MM/SD常用BAPI 附加&#xff1a;长文本修改 业务对象 概念 业务对象浏览 进入SWO3查看 双击BUS2012 双击下图上方红色位置可以看到BAPI方法的内容 BAPI BAPI(Busines…

《高频电子线路》 —— 电感三端LC振荡器

文章内容来源于【中国大学MOOC 华中科技大学通信&#xff08;高频&#xff09;电子线路精品公开课】&#xff0c;此篇文章仅作为笔记分享。 电感三端LC振荡器 基本原理&#xff08;哈特莱电路&#xff09; 在高频下直流电阻对交流电相阻抗无穷大&#xff0c;相当于开路。谐振回…

它真能替代Express?tinyhttp用速度和轻量征服开发者

它真能替代Express&#xff1f;tinyhttp用速度和轻量征服开发者 如果你是个 Express 粉丝&#xff0c;又经常为它的历史遗留问题头疼&#xff0c;那么有个好消息要告诉你&#xff1a;tinyhttp 来啦&#xff01;这款专注于轻量、快速的 Web 框架正在以一种更现代的方式挑战 Expr…