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 strategyRollingUpdate和Recreate 默认RollingUpdate
containers 定义 Pod 中的容器列表
image 使用的容器镜像
resources 字段用于指定Pod或容器可以使用的计算资源量，包括CPU和内存等
type Service 的类型(如 ClusterIP、NodePort、LoadBalancer)
selector 用于选择与 Service 关联的 Pod
ports 定义服务的端口映射
protocol 使用的协议
port Service 的端口
targetPort Pod 的端口
运行
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 使用的协议
port Service 的端口
targetPort Pod 的端口
创建
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 上；
