k8s中的微服务

一 什么是微服务

用控制器来完成集群的工作负载,那么应用如何暴漏出去?需要通过微服务暴漏出去后才能被访问

  • 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 设定

示例:

#生成控制器文件并建立控制器

#生成微服务yaml追加到已有yaml中

root@master \~\]# cat timinglee.yaml apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: timinglee name: timinglee spec: replicas: 2 selector: matchLabels: app: timinglee template: metadata: creationTimestamp: null labels: app: timinglee spec: containers: - image: reg.timinglee.org/library/myapp:v1 name: myapp --- apiVersion: v1 kind: Service metadata: creationTimestamp: null labels: app: timinglee name: timinglee spec: ports: - port: 80 protocol: TCP targetPort: 80 selector:

微服务默认使用iptables调度

三 ipvs模式

  • Service 是由 kube-proxy 组件,加上 iptables 来共同实现的

  • kube-proxy 通过 iptables 处理 Service 的过程,需要在宿主机上设置相当多的 iptables 规则,如果宿主机有大量的Pod,不断刷新iptables规则,会消耗大量的CPU资源

  • IPVS模式的service,可以使K8s集群支持更多量级的Pod

3.1 ipvs模式配置方式

1 在所有节点中安装ipvsadm

2 修改master节点的代理配置

3 重启pod,在pod运行时配置文件中采用默认配置,当改变配置文件后已经运行的pod状态不会变化,所以要重启pod

切换ipvs模式后,kube-proxy会在宿主机上添加一个虚拟网卡:kube-ipvs0,并分配所有service IP

四 微服务类型详解

4.1 clusterip

特点:

clusterip模式只能在集群内访问,并对集群内的pod提供健康检测和自动发现功能

示例:

4.2 ClusterIP中的特殊模式headless

headless(无头服务)

对于无头 Services 并不会分配 Cluster IP,kube-proxy不会处理它们, 而且平台也不会为它们进行负载均衡和路由,集群访问通过dns解析直接指向到业务pod上的IP,所有的调度有dns单独完成

示例:

无ip

#开启一个busyboxplus的pod测试

IP 都是后端ip直接暴露不走ipvs

4.3 nodeport

通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:<port>来访问pod业务

其访问过程为:

示例:

nodeport在集群节点上绑定端口,一个端口对应一个服务

nodeport默认端口是30000-32767,超出会报错

直接指定端口:

如果需要使用这个范围以外的端口就需要特殊设定

vim /etc/kubernetes/manifests/kube-apiserver.yaml

--service-node-port-range=30000-40000

添加"--service-node-port-range=" 参数,端口范围可以自定义

修改后api-server会自动重启,等apiserver正常启动后才能操作集群

集群重启自动完成在修改完参数后全程不需要人为干预

4.4 loadbalancer

云平台会为我们分配vip并实现访问,如果是裸金属主机那么需要metallb来实现ip的分配

默认无法分配外部访问IP

LoadBalancer模式适用云平台,裸金属环境需要安装metallb提供支持

4.5 metalLB

metalLB功能为LoadBalancer分配vip

部署方式

1.设置ipvs模式

root@k8s-master \~\]# kubectl edit cm -n kube-system kube-proxy apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: "ipvs" ipvs: strictARP: true \[root@k8s-master \~\]# kubectl -n kube-system get pods \| awk '/kube-proxy/{system("kubectl -n kube-system delete pods "$1)}'

2.下载部署文件

wget https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml

3.修改文件中镜像地址,与harbor仓库路径保持一致

4.上传镜像到harbor

部署服务

配置分配地址段

#通过分配地址从集群外访问服务

4.6 externalname

  • 开启services后,不会被分配IP,而是用dns解析CNAME固定域名来解决ip变化问题

  • 一般应用于外部业务和pod沟通或外部业务迁移到pod内时

  • 在应用向集群迁移过程中,externalname在过度阶段就可以起作用了。

  • 集群外的资源迁移到集群时,在迁移的过程中ip可能会变化,但是域名+dns解析能完美解决此问题

示例:

五 Ingress-nginx

5.1 ingress-nginx功能

  • 一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层

  • Ingress由两部分组成:Ingress controller和Ingress服务

  • Ingress Controller 会根据你定义的 Ingress 对象,提供对应的代理能力。

  • 业界常用的各种反向代理项目,比如 Nginx、HAProxy、Envoy、Traefik 等,都已经为Kubernetes 专门维护了对应的 Ingress Controller。

5.2 部署ingress

5.2.1 下载部署文件

上传ingress所需镜像到harbor

5.2.2 安装ingress

在ingress-nginx-controller中看到的对外IP就是ingress最终对外开放的ip

5.2.3 测试ingress

#生成yaml文件

root@master ingress\]# cat ingress1.yml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: myappv1 spec: ingressClassName: nginx rules: - http: paths: - backend: service: name: myappv1 port: number: 80 path: / pathType: Prefix #Exact(精确匹配),ImplementationSpecific(特定实现),Prefix(前缀匹配),Regular expression(正则表达式匹配)

#修改微服务为loadbalancer

kubectl -n ingress-nginx edit svc ingress-nginx-controller

#建立ingress控制器

5.3 ingress 的高级用法

5.3.1 基于路径的访问

建立用于测试的控制器myapp

建立ingress的yaml

#测试:

5.3.3 建立tls加密

#建立证书

#建立加密资源类型secret

#建立ingress3基于tls认证的yml文件

#测试

5.3.4 建立auth认证

#建立认证文件

#建立认证类型资源

#建立ingress4基于用户认证的yaml文件

#测试:

5.3.5 rewrite重定向

#指定默认访问的文件到hostname.html上

#测试:

#解决重定向路径问题

apiVersion: networking.k8s.io/v1

name: myapp

annotations:

nginx.ingress.kubernetes.io/rewrite-target: /$2

nginx.ingress.kubernetes.io/use-regex: "true"

spec:

ingressClassName: nginx

rules:

paths:

  • backend:

service:

name: myappv1

port:

number: 80

path: /

pathType: Prefix

  • backend:

service:

name: myappv1

port:

number: 80

path: /lee(/|$)(.*)

pathType: ImplementationSpecific

#测试

六 Canary金丝雀发布

6.1 么是金丝雀发布

金丝雀发布(Canary Release)也称为灰度发布,是一种软件发布策略。

主要目的是在将新版本的软件全面推广到生产环境之前,先在一小部分用户或服务器上进行测试和验证,以降低因新版本引入重大问题而对整个系统造成的影响。

是一种Pod的发布方式。金丝雀发布采取先添加、再删除的方式,保证Pod的总量不低于期望值。并且在更新部分Pod后,暂停更新,当确认新Pod版本运行正常后再进行其他版本的Pod的更新。

6.2 Canary发布方式

其中header和weiht中的最多

6.2.1 基于header(http包头)灰度

示例:

#建立版本1的ingress

#建立基于header的ingress

#测试:

6.2.2 基于权重的灰度发布

#基于权重的灰度发布

测试:

相关推荐
点PY1 小时前
构建rknn的docker镜像
运维·docker·容器
佚名涙2 小时前
k8s调度机制:亲和性,污点,容忍
云原生·容器·kubernetes
2301_779503763 小时前
K8s的部署
linux·容器·kubernetes
时雨h3 小时前
微服务分层架构技术解析:从 API 到数据访问的全方位探秘
java·微服务·dubbo
啾啾Fun3 小时前
[微服务设计]3_如何构建服务
运维·微服务·架构
roman_日积跬步-终至千里5 小时前
【Docker compose】neo4j容器安装apoc插件
docker·容器·neo4j
你可以叫我仔哥呀7 小时前
k8s学习记录(三):Pod基础-Node选择
学习·docker·kubernetes
alden_ygq8 小时前
k8s 配置两个deployment主机级别互斥部署
云原生·容器·kubernetes
喵叔哟10 小时前
11.【.NET 8 实战--孢子记账--从单体到微服务--转向微服务】--微服务基础工具与技术--Ocelot 网关--整合日志
java·微服务·.net