企业网站的建立标准,来个网站吧好人一生平安,织梦游戏网站模板,网页设计有哪些岗位主要内容#xff1a;
掌握DaemonSet控制器、污点策略#xff08;NoSchedule、Noexecute#xff09;、Job / CronJob资源对象、掌握Service服务、服务名解析CluterIP#xff08;服务名自动发现#xff09;、#xff08;Nodeport、Headless#xff09;、Ingress控制器 一…主要内容
掌握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资源文件示例
[rootmaster ~]# 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 //容器的死亡策略[rootmaster ~]# kubectl apply -f mynginx.yaml
daemonset.apps/mynginx created
[rootmaster ~]# kubectl get pod -o wide # DaemonSet控制器自动为所有节点上运行Pod副本
[rootmaster ~]# kubectl get daemonsets.apps
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
mynginx 3 3 3 3 3 none 12m
# 测试效果
[rootmaster ~]# curl http://10.244.2.13
this is nginx
[rootmaster ~]# curl http://10.244.1.11
this is nginx
[rootmaster ~]# 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的资源文件上测试
[rootmaster ~]# kubectl delete -f mynginx.yaml //删除资源重新创建
daemonset.apps mynginx deleted
[rootmaster ~]# kubectl describe nodes | grep -P ^Taints [rootmaster ~]# kubectl taint node node-0001 k1v1:NoSchedule //设置污点标签
node/node-0001 tainted
[rootmaster ~]# kubectl describe nodes | grep -P ^Taints [rootmaster ~]# kubectl apply -f mynginx.yaml
daemonset.apps/mynginx created
[rootmaster ~]# kubectl get pods //设置污点标签后只有2节点有POD副本
NAME READY STATUS RESTARTS AGE
mynginx-6j8h4 1/1 Running 0 9s
mynginx-8g2wc 1/1 Running 0 9s
② 删除污点标签
[rootmaster ~]# kubectl taint node node-0001 k1-
node/node-0001 untainted [rootmaster ~]# 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会有不同效果 [rootmaster ~]# 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[rootmaster ~]# kubectl apply -f myapache.yaml //执行Deployment资源
deployment.apps/myapache created
[rootmaster ~]# kubectl scale deployment myapache --replicas3
deployment.apps/myapache scaled
[rootmaster ~]# kubectl get pod -o wide //查看Pod资源信息 [rootmaster ~]# kubectl taint node node-0003 k1v1:NoExecute //设置污点
node/node-0003 tainted
[rootmaster ~]# kubectl get pod -o wide 解释在POD容器运行时为node-0003节点设置NoExecute污点标签后针对Deployment控制器0003节点被驱逐并按照Deployment控制器的规则在另一节点重建Pod副本为满足高可用保证副本为3针对Daemonset控制器0003节点被驱逐但并未创建额外的副本
[rootmaster ~]# kubectl taint node node-0003 k1-
node/node-0003 untainted
[rootmaster ~]# 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资源文件示例
[rootmaster ~]# 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, -Mbignumbpi, -wle, print bpi(2000)] //替换默认启动命令打印输出π到2000位restartPolicy: OnFailure //容器重启策略只支持[OnFailureNerver][rootmaster ~]# kubectl apply -f myjob.yaml
job.batch/pi created
[rootmaster ~]# kubectl get job.batch
NAME COMPLETIONS DURATION AGE
pi 1/1 9s 10s
[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pi-246kc 0/1 Completed 0 19s
# 验证效果
[rootmaster ~]# kubectl logs pi-246kc //打印输出结构显示在终端 补充K8S核心为PODPOD外层使用不同控制器实现不同应用 2、CronJob资源对象
CronJob重复多次任务控制器像是Job的升级版是基于时间管理的Job
典型用法Crontab周期性计划任务 CronJob的本质是在约定的时间创建Job 在Job中会保留最后三次的状态并进行滚动更新其它会被清除 CronJob资源文件模板架构CronJob - Job - Pod 编写CronJob资源文件示例
[rootmaster ~]# 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, -Mbignumbpi, -wle, print bpi(2000)]restartPolicy: OnFailure[rootmaster ~]# kubectl apply -f mycronjob.yaml
cronjob.batch/cronjob-pi created
[rootmaster ~]# kubectl get cronjobs.batch
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
cronjob-pi */1 * * * * False 0 none 5s
[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
cronjob-pi-1625464980-266ss 0/1 Completed 0 9s //Completed完成 其他资源对象
1StatefulSet有状态服务相关POD - 为了解有状态服务设计的一种控制器 - 基于PVC的稳定持久化存储 - 稳定的网络标志基于Headless Service - 有序部署有序扩展/收缩基于init containers实现 2Horizontal Pod Autoscaling控制器 - 自动扩展可以根据业务的高峰和低谷自动水平扩展Pod节点提高资源利用率 四、Service服务与负载均衡
1、服务使用场景
使用Deployment控制器在创建简单WEB集群时多副本会自动调度分配到不同主机上
例如使用scale创建2副本实验
[rootmaster ~]# kubectl apply -f myapache.yaml
deployment.apps/myapache created
[rootmaster ~]# kubectl scale deployment myapache --replicas2
deployment.apps/myapache scaled
[rootmaster ~]# kubectl get pod -o wide [rootmaster ~]# kubectl delete pod myapache-7d689bf8f-rt2vw
pod myapache-7d689bf8f-rt2vw deleted
[rootmaster ~]# 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服务的端口 ① portService开放在前端的Cluster IP上端口是提供给集群内部客户访问Service的入口提供集群内部服务访问使用类似VIP:port ② targetPort是后端Pod上容器服务监听的端口从port或nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort进入容器从而达到访问Pod容器内部服务的目的 编写Service服务资源文件示例
注意服务创建前必须要基于运行的容器应用集群
[rootmaster ~]# 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资源文件中一致mypodtype: ClusterIP //服务类型ClusertIP[rootmaster ~]# kubectl apply -f clusterip.yaml
service/myapache created
[rootmaster ~]# kubectl get service # 访问Service服务 Service服务只有在集群内部才可以访问集群外无法访问服务LVS-NAT网络架构有关 [rootmaster ~]# kubectl get pod -o wide //查看集群容器 [rootmaster ~]# kubectl apply -f mypod.yaml //创建Pod并在Pod容器中访问服务
pod/mypod created
[rootmaster ~]# kubectl exec -it mypod -- /bin/bash
[rootmypod /]# 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[rootmypod /]# 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服务的自动发现和负载均衡
[rootmaster ~]# kubectl delete pod myapache-7d689bf8f-k2vzw
pod myapache-7d689bf8f-k2vzw deleted
[rootmaster ~]# kubectl get pod -o wide [rootmaster ~]# kubectl exec -it mypod -- /bin/bash
[rootmypod /]# 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[rootmypod /]# 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个服务的管理 — 示例多资源文件
① 清除原来的资源文件配置
[rootmaster ~]# kubectl delete -f myapache.yaml
[rootmaster ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
mypod 1/1 Running 0 8h
② 使用重定向方式将2个资源服务写到同一个YAML文件
[rootmaster ~]# 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[rootmaster ~]# kubectl apply -f myapache.yaml
deployment.apps/myapache created
service/myapache created
[rootmaster ~]# kubectl get pod //查看Pod资源 [rootmaster ~]# 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
[rootmaster ~]# kubectl get service cluster.local在Master初始化配置文件中定义
[rootmaster ~]# vim init/kubeadm-init.yaml 示例通过服务名称来代替ClusterIP访问集群容器
[rootmaster ~]# kubectl exec -it mypod -- /bin/bash
[rootmypod /]# curl http://myapache.default.svc.cluster.local
this is apache
# 因/etc/resolv.conf域名配置文件默认已加search搜索头搜索域名后缀自动补齐
[rootmypod /]# cat /etc/resolv.conf
nameserver 10.254.0.10
search default.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options ndots:5[rootmypod /]# curl http://myapache
this is apache
[rootmypod /]# 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规则
[rootmaster ~]# 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地址
[rootmaster ~]# kubectl get pod -o wide 2、服务类型
Service允许指定一个Type类型一般默认是ClusterIP ① ClusterIP通过集群的内部IP暴露服务但服务只能够在集群内部可以访问这也是默认的ServiceType ② NodePort通过每个Node上的IP和静态端口暴露服务NodePort服务会路由到ClusterIP服务可以对外提供服务 ③ LoadBalancer使‘用云提供商的负载均衡器如华为云容器引擎CCE外部的负载均衡器可以路由到NodePort服务和Cluster服务对外提供服务 1nodePort服务
场景之前构建的服务已可以在集群内部运转但集群外还无法访问集群内部的服务有时候服务可能来自第三方或其他团队我们无法把所有服务都放入集群内部里这时就需要集群内部和集群外部的服务能够实现互相访问 - LoadBalancer使用外部的云服务需支持externallPs - nodePort基于端口对外提供服务四层端口映射 - Ingress使用ingress控制器七层本质为Nginx nodePort服务资源文件模板 编写nodePort服务资源文件示例
[rootmaster ~]# vim mynodeport.yaml
---
kind: Service //定义资源的类型
apiVersion: v1
metadata:name: mynodeport //资源的名称
spec:ports:- protocol: TCPport: 80targetPort: 80selector: //选择为哪个deployment提供服务后端myapp: httpd //标签必须与deployment资源文件中一致mypodtype: NodePort //指定服务类型NodePort[rootmaster ~]# kubectl apply -f mynodeport.yaml
service/mynodeport created
[rootmaster ~]# kubectl get service 补充80为访问容器服务的端口30705为对外发布访问集群的端口 # K8S中所有节点都是LVS负载均衡器通过Node节点30705端口均可访问集群容器
[rootecs-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[rootecs-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[rootecs-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
补充集群服务图例 2Headless服务
场景有时候不需要或不想要负载均衡以及单独的Cluster IP可以创建Headless服务
原理Headless服务会把IP通过多个A记录的形式解析到具体的容器IP上多用于有状态的服务
主要目的用户通过headless服务解析到容器IP不需要使用ClusterIP不使用负载均衡直接访问容器 Headless服务资源文件模板 编写headless 服务资源文件示例
[rootmaster ~]# vim myheadless.yaml
---
kind: Service //定义资源的类型
apiVersion: v1
metadata:name: myheadless //资源的名称
spec:ports:- protocol: TCPport: 80targetPort: 80selector: //选择为哪个deployment提供服务后端myapp: httpd //标签必须与deployment资源文件中一致mypodtype: ClusterIP //类型为ClusterIPclusterIP: None //设置None[rootmaster ~]# kubectl apply -f myheadless.yaml
service/myheadless created
[rootmaster ~]# kubectl get service # 进入pod查看解析结果
[rootmaster ~]# kubectl exec -it mypod -- /bin/bash
[rootmypod /]# yum install -y bind-utils //软件包含host命令用来解析域名
[rootmypod /]# 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层的负载均衡控制器上可以实现基于域名的负载均衡每个域名对应一个ServiceCluster IP再对应POD资源 示例配置Ingress控制器
① 安装控制器
# 拷贝云盘 kubernetes/v1.17.6/ingress 文件夹到 master上导入镜像到私有仓库
[rootecs-proxy v1.17.6]# rsync -av ingress 192.168.1.21:/root
[rootmaster ~]# tree ingress/
ingress/
├── ingress-example.yaml
├── ingress-nginx.tar.gz //ingress控制器镜像文件
├── ingress-service.yaml
└── mandatory.yaml //ingress资源文件
0 directories, 4 files
② 导入镜像到私有仓库
[rootmaster ~]# cd ingress/
[rootmaster ingress]# docker load -i ingress-nginx.tar.gz
[rootmaster 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
[rootmaster ingress]# docker push 192.168.1.100:5000/nginx-ingress-controller:0.30.0
[rootmaster ingress]# curl http://192.168.1.100:5000/v2/nginx-ingress-controller/tags/list
{name:nginx-ingress-controller,tags:[0.30.0]}
③ 修改资源配置文件
[rootmaster ingress]# vim mandatory.yaml
221: image: 192.168.1.100:5000/nginx-ingress-controller:0.30.0 //修改为私有镜像地址
④ 执行资源配置文件
# ingress指定创建命名空间ingress-nginx并把所有的Pod放在该命名空间内
[rootmaster ingress]# kubectl apply -f mandatory.yaml
[rootmaster 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
[rootmaster 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服务发布服务
[rootmaster 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
rootmaster ingress]# kubectl apply -f ingress-example.yaml
ingress.extensions/my-app created
[rootmaster ingress]# kubectl get ingresses
NAME HOSTS ADDRESS PORTS AGE
my-app * 192.168.1.33 80 89s
# 测试服务及轮询效果
[rootmaster 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[rootmaster 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毕竟两个人的智慧大于一个人的智慧如果你不理解本章节的内容或需要相关笔记、视频可私信小安请不要害羞和回避可以向他人请教花点时间直到你真正的理解。
