matchLabels
ingress
Ingress 是反向代理规则，用来规定 HTTP/S 请求应该被转发到哪个 Service 上，比如根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上。
Ingress Controller 就是一个反向代理程序，它负责解析 Ingress 的反向代理规则，如果 Ingress 有增删改的变动，所有的 Ingress Controller 都会及时更新自己相应的转发规则，当 Ingress Controller 收到请求后就会根据这些规则将请求转发到对应的 Service。
Kubernetes 并没有自带 Ingress Controller，它只是一种标准，具体实现有多种，需要自己单独安装，常用的是 Nginx Ingress Controller 和 Traefik Ingress Controller。
一个集群中可以有多个 Ingress Controller， 在Ingress 中可以指定使用哪一个 Ingress Controller。
Ingress Controller 是部署在集群中的，怎么让 Ingress Controller 本身能够被外面访问到呢？
1、Ingress Controller 用 Deployment 方式部署
给它添加一个 Service，类型为 LoadBalancer，这样会自动生成一个 IP 地址，通过这个 IP 就能访问到了，并且一般这个 IP 是高可用的(前提是集群支持 LoadBalancer，通常云服务提供商才支持，自建集群一般没有)；
2、使用 hostPort；
-
1、Ingress Controller 用 DaemonSet 方式部署，使用集群内部的某个或某些节点作为边缘节点，给 node 添加 label 来标识，使用 nodeSelector 绑定到边缘节点，保证每个边缘节点启动一个 Ingress Controller 实例，用 hostPort 直接在这些边缘节点宿主机暴露端口，然后我们可以访问边缘节点中 Ingress Controller 暴露的端口，这样外部就可以访问到 Ingress Controller 了；
-
2、使用非亲缘性策略，使需要部署 Ingress Controller 的节点，每个节点都有一个 Ingress Controller 部署，然后用 hostPort 直接在这些边缘节点宿主机暴露端口，我们就能通过这些节点的 IP 和 hostPort来访问 Ingress Controller 了。
不过使用 hostPort 这种方式，我们还需要再上面部署一层负载均衡。
什么是 hostPort
这是一种直接定义 Pod 网络的方式。
hostPort 是直接将容器的端口与所调度的节点上的端口路由，这样用户就可以通过宿主机的 IP 加上来访问 Pod 了，比如：
k8s 中的部署过程
首先创建namespace
1、创建命名空间
$ kubectl create namespace study-k8s
2、使用 deployment 部署 pod
apiVersion 版本 v1是版本号
kind 此处创建的是Pod，根据实际情况，此处资源类型可以是Deployment、Job、Ingress、Service等。
metadata 包含Pod的一些meta信息，比如名称、namespace、标签等信息。
creationTimestamp 当前对象创建日期的时间戳
labels 标识当前对象的标签，键值数据，常被用作挑选条件
app 名称
name 容器名称
namespace 命名空间名称
spec 资源的具体规格
replicas Pod 的副本数量
selector 用于选择管理的 Pod
matchLabels matchLabels通常与selector字段一起使用，出现在Deployment、Service、DaemonSet等资源的定义中。它的作用是指定哪些标签(Labels)应该被用来选择和关联Pods
strategy ``strategy字段用于定义Deployment的更新策略，主要包含两种策略：RollingUpdate和Recreate 默认``RollingUpdate
containers 定义 Pod 中的容器列表
image 使用的容器镜像
resources 字段用于指定Pod或容器可以使用的计算资源量，包括CPU和内存等
type Service 的类型(如 ClusterIP、NodePort、LoadBalancer)
selector用于选择与 Service 关联的 Pod
ports定义服务的端口映射
protocol使用的协议
portService 的端口
targetPortPod 的端口
运行
kubectl apply -f go-web.yaml -n study-k8s
查看运行状态
kubectl get pods -n study-k8s
kubectl describe deployment nginx-deploy -n study-k8s
3、为服务创建 service
protocol使用的协议
portService 的端口
targetPortPod 的端口
创建
kubectl apply -f go-web-svc.yaml -n study-k8s
4、配置 ingress 的转发策略
service 已经创建成功了，接下来我们使用 ingress
部署 ingress
通过K8S创建过程大概理解为：
1.创建namespace
2.创建Deployment，定义pod、业务、pod数量、更新方式
3.创建service 为pod 提供外网访问的方式，TCP形式 port：service端口 targetPort: pod端口
4.创建Ingress 利用HTTP/HTTPS 定义转发到哪个service上 根据host 和path 定义哪个service
注意：不管是Deployment service Ingress 都是先后顺序的 里面关联了先后顺序的name名称
总结
1、Pod 是 k8s 中集群部署应用和服务的最小单元；
2、RC 是 k8s 集群中最早的保证 Pod 高可用的 API 对象。它的作用就是保证集群中有指定数目的 pod 运行；
3、RS 是新一代 RC，提供同样的高可用能力，是目前主要使用的对象；
4、Deployment 提供了一种对 Pod 和 ReplicaSet 的管理方式，RS 的使用都是结合 Deployment 来完成的。
5、一般使用 Deployment 来滚动升级一个服务，滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。
6、RC、RS 和 Deployment 只是保证了支撑服务的微服务 Pod 的数量。但是没有解决如何访问这些服务的问题。一个 Pod 只是一个运行服务的实例，随时可能在节点上停止，然后再新的节点上用一个新的 IP 启动一个新的 Pod,因此不能使用确定的 IP 和端口号提供服务。这对于业务来说，就不能根据 Pod 的 IP 作为业务调度。kubernetes 就引入了 Service 的概 念，它为 Pod 提供一个入口，主要通过 Labels 标签来选择后端Pod，这时候不论后端 Pod 的 IP 地址如何变更，只要 Pod 的 Labels 标签没变，那么 业务通过 service 调度就不会存在问题。
7、Service 是后端真实服务的抽象，一个 Service 可以代表多个相同的后端服务；
8、Ingress 是反向代理规则，用来规定 HTTP/S 请求应该被转发到哪个 Service 上，比如根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上；