山东城市建设学院网站,公司企业宣传片制作公司,网站优化是做什么的,上海小企业网站建设微服务#xff1a;用控制器来完成集群的工作负载#xff0c;那么应用如何暴漏出去#xff1f;需要通过微服务暴漏出去后才能被访问
- Service是一组提供相同服务的Pod对外开放的接口。
- 借助Service#xff0c;应用可以实现服务发现和负载均衡。
- service默认只支持…微服务用控制器来完成集群的工作负载那么应用如何暴漏出去需要通过微服务暴漏出去后才能被访问
- Service是一组提供相同服务的Pod对外开放的接口。
- 借助Service应用可以实现服务发现和负载均衡。
- service默认只支持4层负载均衡能力没有7层功能。可以通过Ingress实现 微服务类型
微服务类型 | 作用描述 |
| ------------ | ------------------------------------------------------------ |
| ClusterIP | 默认值k8s系统给service自动分配的虚拟IP只能在集群内部访问 |
| NodePort | 将Service通过指定的Node上的端口暴露给外部访问任意一个NodeIP:nodePort都将路由到ClusterIP |
| LoadBalancer | 在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器并将请求转发到 NodeIP:NodePort此模式只能在云服务器上使用 |
| ExternalName | 将服务通过 DNS CNAME 记录方式转发到指定的域名通过 spec.externlName 设定 | 示例
#生成控制器文件并建立控制器
kubectl create deployment timinglee --image myapp:v1 --replicas 2 --dry-runclient -o yaml timinglee.yaml
生成微服务yaml追加到已有yaml中 kubectl expose deployment timinglee --port 80 --target-port 80 --dry-runclient -o yaml timinglee.yaml
vi timinglee.yaml 查看策略 iptables -t nat -nL IPVS模式
配置方式
在所有节点安装ipvsadm
yum install ipvsadm -y 修改master 节点的代理配置
kubectl -n kube-system edit cm kube-proxy 修改后重启pod 切换ipvs模式后kube-proxy会在宿主机上添加一个虚拟网卡kube-ipvs0并分配所有service IP 微服务类型详解
clusterip
特点
clusterip模式只能在集群内访问并对集群内的pod提供健康检测和自动发现功能
示例
vi myapp.yml service创建后集群DNS提供解析 ClusterIP中的特殊模式headless
headless(无头服务)
对于无头 Services 并不会分配 Cluster IPkube-proxy不会处理它们 而且平台也不会为它们进行负载均衡和路由集群访问通过dns解析直接指向到业务pod上的IP所有的调度有dns单独完成
vim timinglee.yaml测试 dig timinglee.default.svc.cluster.local 10.96.0.10 nodeport
通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:port来访问pod业务
其访问过程为 示例
vim timinglee.yaml在集群节点上绑定端口一个端口对应一个服务 注意 nodeport默认端口
nodeport默认端口是30000-32767超出会报错
如果需要使用这个范围以外的端口就需要特殊设定
vim /etc/kubernetes/manifests/kube-apiserver.yaml
- --service-node-port-range30000-40000
这里需要注意的是
添加“--service-node-port-range“ 参数端口范围可以自定义 修改后api-server会自动重启等apiserver正常启动后才能操作集群
集群重启自动完成在修改完参数后全程不需要人为干预
loadbalancer
云平台会为我们分配vip并实现访问如果是裸金属主机那么需要metallb来实现ip的分配 示例 默认无法分配外部访问 LoadBalancer模式适用云平台裸金属环境需要安装metallb提供支持
metalLB
官网https://metallb.universe.tf/installation/ 功能 为LoadBalancer分配vip
部署方式 kubectl edit cm -n kube-system kube-proxy设置ipvs模式 上传metallb 镜像到harbor仓库 部署服务 配置分配地址段
vim configmap.yml 两个不同的kind中间必须加分割 查看 通过分配地址从集群外访问服务 externalname
开启services后不会被分配IP而是用dns解析CNAME固定域名来解决ip变化问题
一般应用于外部业务和pod沟通或外部业务迁移到pod内时
在应用向集群迁移过程中externalname在过度阶段就可以起作用了。
集群外的资源迁移到集群时在迁移的过程中ip可能会变化但是域名dns解析能完美解决此问题
示例 ingress-nginx
官网https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal-clusters
功能 一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层
Ingress由两部分组成Ingress controller和Ingress服务
Ingress Controller 会根据你定义的 Ingress 对象提供对应的代理能力。
业界常用的各种反向代理项目比如 Nginx、HAProxy、Envoy、Traefik 等都已经为Kubernetes 专门维护了对应的 Ingress Controller。
部署
下载文件 上传镜像 安装ingress
vim deploy.yaml kubectl apply -f deploy.yaml kubectl -n ingress-nginx get svc 修改微服务为loadbalancer
kubectl -n ingress-nginx edit svc ingress-nginx-controller 注意 在ingress-nginx-controller中看到的对外IP就是ingress最终对外开放的ip
测试
kubectl create ingress webcluster --rule */timinglee-svc:80 --dry-runclient -o yaml timinglee-ingress.yml建立ingress控制器 for n in {1..5}; do curl 172.25.254.50/hostname.html; done
ingress必须和输出的service资源处于同一namespace
高级用法
kubectl create deployment myapp-v1 --image myapp:v1 --dry-runclient -o yaml myapp-v1.yaml kubectl create deployment myapp-v2 --image myapp:v2 --dry-runclient -o yaml myapp-v2.yaml
在文件中加入 建立ingress的yaml文件、 #nginx.ingress.kubernetes.io/rewrite-target: / 的功能实现 基于域名的访问
在测试主机中设定解析
vi /etc/hosts172.25.254.50 www.timinglee.org myappv1.timinglee.org myappv2.timinglee.org
建立基于域名的yml文件
vim ingress2.yml 利用文件建立ingress
在测试主机中测试 建立tls加密
注意
secret通常在kubernetes中存放敏感数据他并不是一种加密方式 openssl req -newkey rsa:2048 -nodes -keyout tls.key -x509 -days 365 -subj /CNnginxsvc/Onginxsvc -out tls.crt建立ingress3基于tls认证的yml文件 测试 建立认证
下载安装
http-tools 建立认证类型资源 测试 重定向 describe 测试 金丝雀发布
金丝雀发布Canary Release也称为灰度发布是一种软件发布策略。
主要目的是在将新版本的软件全面推广到生产环境之前先在一小部分用户或服务器上进行测试和验证以降低因新版本引入重大问题而对整个系统造成的影响。
是一种Pod的发布方式。金丝雀发布采取先添加、再删除的方式保证Pod的总量不低于期望值。并且在更新部分Pod后暂停更新当确认新Pod版本运行正常后再进行其他版本的Pod的更新。 canary发布方式 基于headerhttp包头灰度 通过Annotaion扩展
- 创建灰度ingress配置灰度头部key以及value
- 灰度流量验证完毕后切换正式ingress到新版本
- 之前我们在做升级时可以通过控制器做滚动更新默认25%利用header可以使升级更为平滑通过key 和vule 测试新的业务体系是否有问题。
示例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:name: myapp-v1-ingress
spec:ingressClassName: nginxrules:- host: myapp.timinglee.orghttp:paths:- backend:service:name: myapp-v1port:number: 80path: /pathType: Prefix建立基于header的ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:nginx.ingress.kubernetes.io/canary: truenginx.ingress.kubernetes.io/canary-by-header: versionnginx.ingress.kubernetes.io/canary-by-header-value: 2name: myapp-v2-ingress
spec:ingressClassName: nginxrules:- host: myapp.timinglee.orghttp:paths:- backend:service:name: myapp-v2port:number: 80path: /pathType: Prefix基于权重的灰度发布 apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:nginx.ingress.kubernetes.io/canary: truenginx.ingress.kubernetes.io/canary-weight: 10 #更改权重值nginx.ingress.kubernetes.io/canary-weight-total: 100name: myapp-v2-ingress
spec:ingressClassName: nginxrules:- host: myapp.timinglee.orghttp:paths:- backend:service:name: myapp-v2port:number: 80path: /pathType: Prefix
