一 什么是微服务
用控制器来完成集群的工作负载，那么应用如何暴漏出去？需要通过微服务暴漏出去后才能被访问
-
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:
host: www.timinglee.org
http:
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 基于权重的灰度发布
#基于权重的灰度发布
测试：
