Ingress

service 支持会话粘性
kubectl explain svc.spec.sessionAffinity
Headless　service 无Cluster IP
ClusterIP： serviceName --> ClusterIP
ClusterIP Node: serviceName --> PodIP

# headless service
kind: Service
apiVersion: v1
metadata:
  name: myapp-headless-svc
spec:
  clusterIP: None
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80
    name: httpport

service: proxy,lb 如要改service的为ipvs，则需改kube-proxy配置
kubectl get cm -n kube-system //其中所有容器统一配置，配置中心
lsmod | grep ip_vs
yum -y install ipvsadm
kubectl edit cm kube-proxy -n kube-system
kubectl delete pods -l k8s-app=kube-proxy -n kube-system //让其重新加载kube-proxy配置文件，其中kube-proxy的pod是由daemon-set这个控制器决定的
ipvsadm -L 查看ipvs规则，在node节点上
service是四层代理，如果后端Pod要http会话，service无法完成，因为service在内核中工作
http7层，一般7层就是进程，运行在一个Pod中

image.png

因为我们所有的Pod（client）都要指向（pod）7层调度，极大不方便
Ingress：可以理解为一个7层的调度规则，就是把一个URL的访问，代理成另一个URL的访问
其中7层代理的Pod,这个Pod 是Ingress Controller 时刻watch Api server的变动
Ingress controller 没有被master上的controller-manager所管理，其中Ingress controller是个守护进程，也可以运行为Pod
简单的Ingress示例

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: www.ikubernetes.io
    http:
      paths:   /test/path  
      - backend:
          serviceName: myapp-svc
          servicePort: 80

paths: 是后端url路径
serviceName: 关联后端的service资源
servicePort： 它的标签选择器匹配到各Pod对象，将成为反代服务的后端

Ingress 自身不支持使用标签选择器挑选真正提供服务的Pod对象，因此它需要由service对象的辅助功能完成此类功能。此处有service提供标签选择器功能
还有当Pod增加时，service会捕获到增加的Pod信息，传给ingress
如用到Ingress 外部引用

image.png

在Ingress pod IP前加一个Nodeport类型的service来对Ingress Pod做代理

image.png
Ingress Pod使用Pod控制器，再使用hostport对外暴露特定端口
Ingress pod 直接共享节点的网络名称空间节点具有公网

部署ingress-nginx 由于网络的原因暂时下载不了Pod，有待更新

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.35.0/deploy/static/provider/cloud/deploy.yaml
kubectl get pods -n ingress-nginx -o wide  //查看pod