Ingress-nginx 部署使用

一、在客户端访问咱们k8s服务时，四层调度器自己是没有办法解除ssl会话的，这就意味着客户端必须与后端服务器（pod）之间直接创建ssl会话，这里还有个显著的问题在于若是调度器在ssl会话创建之后的下一个请求被调度到第二台服务器上那么这个ssl还要从新创建，所以咱们只要认为内部网络是安全的那么咱们能够把会话在前端调度器上卸载，可是四层调度是不能卸载的，所以咱们须要七层的负载均衡机制。所以若是他们是http服务咱们又指望构建https，那么咱们只须要他在互联网上这个不安全的网络中传输实现https，内网中使用http，所以咱们须要使用卸载器，可是咱们Service调度时，不管是iptables仍是ipvs都只是四层调度，所以也就意味着若是你想要在k8s上运行一个应用基于https提供服务，咱们就必须得在后端每个pod上配置https，由于只有这样他们才会创建起https联系，因此咱们如今也指望在接入那一层上就可以卸载ssl，向内部调度时就再也不是ssl了。对这种需求，k8s采用一种很独特的方式来实现，咱们在整个集群中，在进行调度时后端被代理的pod资源是不配置https的，就是明文的http，可是我使用一个独特的调度器（运行在pod中），对于此pod来说，其是一个运行在七层（用户空间）的正常的应用程序，好比nginx,haproxy等，当用户试图访问某一服务时，咱们不让他先去到达前端的service，而是先到这个pod，而后pod与pod之间不须要service而是直接通讯来完成反向代理，咱们用一个pod来反代至后端咱们真正提供服务的pod，此前咱们用service代理的，如今用pod，而这个pod若是须要被访问到那么仍是须要通过service，所以客户端通过此pod的service调度之后，与咱们专门配置了https的此pod进行交互，这里的service咱们定义成nodePort，依然没有什么问题，依然老路径仍是存在的，可是等到达这个pod之后由此pod直接代理至两个明文的pod，所以此pod就成为https的会话卸载器了。若是这种方式进行调度那么调度方式以下： client --> LB --> nodePort --> service -->会话卸载器pod --> 后端pod 这种方式性能确定会很是很是差，如图。前端

二、其实咱们还能够这样干，可让咱们pod直接共享咱们节点的网络名称空间，因而，上述中的会话卸载器pod咱们能够直接让他共享节点网络名称空间，这就意味着其监听着宿主机的地址，这样咱们客户端的请求就能够之间到达这个pod，而后再由他进行调度。node

三、在一个节点上运行的容器，容器可使用本身的虚拟网络，也能够共享宿主机的网络，若是这个容器共享宿主机的网络也就意味着这个容器内的进程一旦监听套接字时它监听的是宿主机的地址，至关于一个进程运行在宿主机上同样的，这样一来这个pod在每一个节点上就只能运行一个了，通常来说集群中只有一个，那么其只须要运行在集群的某一个节点便可，可是若是监听在节点的端口时就会有问题，service时不管访问哪个节点的端口都行，由于你访问哪个节点的nodePort他都能经过它的ip地址送达到后端pod上，可是如今这个Pod要监听节点的网络名称空间，而且经过这个节点的网络名称空间直达这个pod，那么若是运行这种类型的pod那么就必定只能运行在一个节点上，访问时客户端就只能访问这个节点，而且若是这个节点挂了呢？linux

　　四、要解决这个问题，咱们能够用DaemonSet控制器，它能够在每一个节点上都运行相应的pod 副本而且只运行一个，这样假如咱们有三个节点那么咱们三个节点上均可以运行这个pod。这样就都能实现代理和负载均衡，可是又回到了调度到哪个节点均可以的问题，这样不管哪一个节点挂掉了都仍是能够访问到，可是若是咱们有太多的节点那么每一个节点都运行一个这样的pod就太占资源。daemonset还可让pod运行在有限的节点的范围上（部分节点），因而再未来作k8s集群时能够这样干，好比咱们有三千个节点，那么咱们专门拿三个节点出来作pod的接入式的负载均衡的专用主机，而且给这三个节点打上污点让其它pod没法调度上来，而后咱们就定义这个DaemonSet控制器上的pod只运行在这三个节点上各自运行一份而且能容忍这些污点，因此这三个主机在集群中只容许这一个类型的pod，专门负责为集群接入外部的七层调度的流量。而这个pod在k8s中有个专门的称呼叫 Ingress Controller。这个Ingress Controller比较独特，以前讲的DaemonSet，deployment,replacSet等控制器都不同，DaemonSet deployment,replaciSet等等都是做为Controller manager的一部分存在，众多控制器都是做为Controller manager的一个子组件做为其组成部分组成的。而Ingress Controller倒是本身独立运行的一个或一组pod资源，它一般就是一个应用程序，这个应用程序就是拥有七层代理能力和调度能力的应用程序，目前k8s上的选择有四种，其中最不受待见的就是Haproxy，通常默认是nginx，如今在服务网格中你们比较倾向Envoy，固然还有其它与nginx相竞争的听说原本就是为微服务而生的Traefik，因此用Ingress Controller时会发现咱们有三种选择：nginx

　　　　b、Traefik：这种设计就是为微服务这种动态生成而生的github

五、做为调度器，有时候要调度不仅一个后端服务，假若有一个调度器pod，后端有一组pod提供电商服务，第二组pod提供了社交服务，第三组pod提供了论坛服务，第四组pod提供了网关服务。那么咱们这四组http服务怎么可以分别调度呢？后端

a、从nginx的角度来说，接入服务端时咱们经过uptream_server便可，可是接入客户端时咱们应该如何标识这四种不一样的请求呢，首先咱们能够在nginx上作四个虚拟主机，在四个主机名上作四个主机，每个主机名对应一组后端的pod。那万一咱们没那么多主机名呢？此时咱们能够经过不一样的路径来作url映射，而后每一组路径就映射到一组后端pod上，可是pod存在生命周期，随时均可能挂掉替换为一个新pod，新pod的ip就会变了，另外咱们pod的应用的规模也能够动态伸缩的，咱们简单改一下副本数其数量也会变，这种一变前面代理的配置也就无效了，咱们service经过关联标签来解决这个问题，并且service随时 watch着api server上的api时刻来关注本身关联的slector的资源是否变更了，只要变更咱们api server就会当即通知service而后service当即改变。因此service经过label selector始终关联着对应label能适配的后端pod，不管怎么变都能应付并且能及时做出反应，那么此处nginx运行在pod中也就意味着这个配置是在pod内部而且后端pod随时还会发生变更，Ingress 也会时刻watch着api 中的后端pod资源的改变。那它怎么知道这是哪一个pod资源呢？Ingress Controller本身没有这个能力，它并不知道目前符合本身条件关联的被代理的pod资源有哪些，它必须借助于service来实现，咱们要想定义一个这种调度能力功能其实仍是须要建service，这个service经过label selector关联至后端的pod上来，但这个service不是被当作被代理时的中间节点，它仅仅是帮忙分类的，这个service 关联了几个pod那么咱们就将这几个pod配置写在这个upstream中，调度时是不会通过service的，service在此处仅仅是帮忙分组的，分完组之后咱们须要获得的也不是service的IP，而是pod的ip，所以此时可使用headless service，可是这个service却没有用，是否是headless都无所谓，它只要帮忙完成分组知道找哪几个pod就能够了，pod一变，service对应的资源也就变了，问题是变了后这个结果怎么反应到这个配置文件中来，此时须要依赖于一个专门的资源 Ingress。api

　　六、在k8s上有一种特殊的资源叫Ingress，Ingress 和Ingress Controller是两回事，咱们定义一个Ingress 时就是说了它其实就是定义咱们指望这个Ingress Controller是如何给咱们建一个前端（多是一个虚拟主机，也多是一个url映射）接入层，同时又给咱们定义一个后端upstream_server，这个upstream_server中有几个主机 Ingress是经过这个service 获得的，而且Ingress有一个特色，做为资源来说他能够经过编辑注入到Ingress Controller里面来，直接把它注入并保存为配置文件，并且一旦Ingress发现Service选定的后端的pod资源发生改变了，这个改变必定会及时返回到Ingress中，这个Ingress会及时注入到这个前端调度器pod中，就是注入到upstream配置文件中，并且还能触发这个pod中的主容器中的进程重载配置文件。因此咱们要想使用这个功能咱们须要在集群中:tomcat

　　　　a、要有个service去对后端某一个特定类型的pod资源进行分类，这个service只是起分类做用的。

　　　　b、Ingress基于这个分类识别出有几个pod，而且识别其ip地址是什么，而且将这个ip地址返回的结果生成配置信息注入到upstream_server(以nginx为例)，可是nginx又不是特别适用这个场景，每次变更都在重载，若是是Traefik和Envoy 等天生就是为这种场景而生的，只要动了就加载生效，不须要重载。（它能够监控这个配置文件发生变化，只要发生变化就会动态重载）。

　　　　a、须要先部署一个Ingress Controller，而后部署一个pod进来，这个pod可能原本是空的，没有什么有效的东西，接下来咱们要根据本身的须要经过虚拟主机的方式或者经过url代理的方式来配置一个前端，而后再根据咱们Service收集到的后端pod的IP定义成upstream_server，把这些信息反应在Ingress当中由Ingress动态注入到Ingress Controller中才能够

　　　　b、从图中咱们能够看到，当访问咱们服务时首先由外部的负载均衡器将请求调度到咱们nodePort的Service上，而nodePort上的Service再将请求调度至咱们内部的一个pod 叫IngressController上来，Ingress Controller根据Ingress中的定义（虚拟主机或url），每个主机名对应后面的一组pod资源（经过service分组），所以此处用到两组Service，第一个Service是帮集群接入外部流量的（固然也能够不用，能够把这个Ingress Controller pod运行为共享网络节点网络名称空间方式而且将其定义为Dameset方式运行在特定节点上就能够了），那么咱们在定义pod资源时只须要在pod的一个配置选项中加入hostnetwork便可。第二个Service只用来作pod归组不被调度时使用。

　　　　c、接下来咱们要使用ingress的功能得先去安装部署Ingress Controller 这个pod，然后再定义Ingress，然后再定义后端pod生成Service，而后再创建关联关系。

Ingress 定义

一、Ingress 也是标准的kubernetes资源对象，所以也拥有相应的对象属性。

部署配置Ingress

1 .部署文件介绍、准备

直接部署在裸机上时要额外加上一项叫作service-nodeport.yaml，若是不加上这一项会发现ingress controller部署完之后在集群内部能够被访问，在集群外部是没法被访问到的，由于ingress controller没法接入外部的流量，若是要接入流量则须要再部署一个nodePort的service，或者也能够将ingress controller部署为直接共享节点网络名称空间的方式，但这个时候咱们须要手动改造with-rbac.yaml这个文件中的kind 类型由Deployent改成DaemonSet，而后去掉replicas，而后在pod template上的spec中加一项hostnetwork用于共享宿主机的网络名称空间，固然须要保证监听的端口不被冲突。

此时访问咱们节点端口显示 default backend - 404 ，此时表示咱们调度器已经正常工做

使用 ingress 规则部署应用

配置 ingress 规则

apiVersion: extensions/v1beta1
kind: Ingress 
metadata:
  name: ingress-myapp
  namespace: default 
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules: 
  - host: myapp.zhangbiao.com
    http:
      paths: 
      - path:  
        backend: 
          serviceName: myapp
          servicePort: 80

ingress-myapp.yaml

部署ingress 应用

kubectl apply -f deploy-demo.yaml
kubectl apply -f ingress-myapp.yaml

查看 ingress

kubectl get ingress

kubectl describe ingress ingress-myapp

修改 hosts 文件

C:\Windows\System32\drivers\etc

访问

http://myapp.zhangbiao.com:30080/

配置ingress https 证书访问

一、起三个tomcat pod，每一个pod监听本身的8080和8009端口，所以咱们在三个pod以前作一个Service做为一个固定访问端点代理，可是这个Service待会儿不会用到，它只是用来识别而已，咱们Service对应的8080和8009端口对应后端pod的8080和8009端口。咱们定义一个deployment来部署这三个tomcat，用来监听8080和8009端口，而后定义一个Service把8080和8009暴露出去，可是没有真正向集群外部暴露，由于其是cluster IP类型的，他只是用来被前端等会儿叫ingress controller定义ingress规则向里面映射的时候所识别后端有哪几个Pod而已。

建立Deployment 和 Service

apiVersion: v1
kind: Service
metadata:
  name: tomcat 
  namespace: default
spec:
  selector: 
    app: tomcat
    release: canary
  ports:
  - name: http
    targetPort: 8080
    port: 8080
  - name: ajp
    targetPort: 8009
    port: 8009
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat-deploy
  namespace: default
spec:
  replicas: 3
  selector: 
    matchLabels:
      app: tomcat
      release: canary
  template:
    metadata:
      labels:
        app: tomcat
        release: canary
    spec:
      containers:
      - name: myapp
        image: tomcat:8.5.32-jre8-alpine
        ports: 
        - name: http
          containerPort: 8080
        - name: ajp
          containerPort: 8009

tomcat-deploy.yaml

配置ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tomcat
  namespace: default
  annotations: #进行说明咱们接下来要用到的规则是nginx,就是靠annotations来识别类型的，只有进行注解了才能转化为对应的与controller相匹配的规则
    kubernetes.io/ingress.class: "nginx"
spec:
  rules: #定义把谁转到谁那儿去
  - host: tomcat.wohaoshuai.com #要确保在外部经过互联网访问时能解析此主机名，而且解析结果恰好能到达咱们Service nodePort映射的主机上去
    http: #定义先后端路径
      paths: #不给默认为/
      - path: #前端路径，空表示默认的/ 
        backend: #匹配后端service 
          serviceName: tomcat
          servicePort: 8080  #咱们没有指ingress因此默认ingress是80端口

ingress-tomcat.yaml

部署应用

kubectl apply -f tomcat-deploy.yaml 
kubectl apply -f ingress-tomcat.yaml

建立私钥和证书　　

openssl genrsa -out tls.key 2048

建立自签证书

openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.wohaoshuai.com

注意生成的证书是不能直接贴到nginx的pod中去的，咱们须要把它先转成特殊格式，这个特殊格式叫secret，它也是标准的k8s集群对象，它能够直接注入到pod中被pod所引用。所以接下来咱们须要把它作成secret

kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls.key
kubectl get secret

建立完之后咱们就能够拿这个secret在ingress.spec.rules中定义了　　

KIND:     Ingress
VERSION:  extensions/v1beta1

RESOURCE: tls <[]Object>

DESCRIPTION:
     TLS configuration. Currently the Ingress only supports a single TLS port,
     443. If multiple members of this list specify different hosts, they will be
     multiplexed on the same port according to the hostname specified through
     the SNI TLS extension, if the ingress controller fulfilling the ingress
     supports SNI.

     IngressTLS describes the transport layer security associated with an
     Ingress.

FIELDS:
   hosts    <[]string> #表示把哪一个主机作成tls格式的
     Hosts are a list of hosts included in the TLS certificate. The values in
     this list must match the name/s used in the tlsSecret. Defaults to the
     wildcard host setting for the loadbalancer controller fulfilling this
     Ingress, if left unspecified.

   secretName    <string> #用哪一个secret来获取证书，私钥等相关信息
     SecretName is the name of the secret used to terminate SSL traffic on 443.
     Field is left optional to allow SSL routing based on SNI hostname alone. If
     the SNI host in a listener conflicts with the "Host" header field used by
     an IngressRule, the SNI host is used for termination and value of the Host
     header is used for routing.

kubectl explain ingress.spec.tls

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tomcat-tls
  namespace: default
  annotations: #进行说明咱们接下来要用到的规则是nginx,就是靠annotations来识别类型的，只有进行注解了才能转化为对应的与controller相匹配的规则
    kubernetes.io/ingress.class: "nginx"
spec:
  tls: 
  - hosts:
    - tomcat.wohaoshuai.com
    secretName: tomcat-ingress-secret
  rules: #定义把谁转到谁那儿去
  - host: tomcat.wohaoshuai.com #要确保在外部经过互联网访问时能解析此主机名，而且解析结果恰好能到达咱们Service nodePort映射的主机上去
    http: #定义先后端路径
      paths: #不给默认为/
      - path: #前端路径，空表示默认的/ 
        backend: #匹配后端service 
          serviceName: tomcat
          servicePort: 8080  #咱们没有指ingress因此默认ingress是80端口

ingress-tomcat-tls.yaml

部署ingress服务

kubectl apply -f ingress-tomcat-tls.yaml
kubectl get ingress

经过https://tomcat.wohaoshuai.com:30443访问便可

Kubernetes相关国外镜像

因为那个啥，因此不少镜像在国内下载不了，因此整理出来方便大伙顺利部署kubernetes集群。

Helm服务
原来镜像地址：gcr.io/kubernetes-helm/tiller:v2.11.0
替换镜像地址：linuxhub/tiller:v2.11.0
镜像仓库地址：https://hub.docker.com/r/linuxhub/tiller

# nginx-ingress-controller:0.24.1
原来镜像地址：quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.24.1
替换镜像地址: linuxhub/nginx-ingress-controller:0.24.1
镜像仓库地址：https://hub.docker.com/r/linuxhub/nginx-ingress-controller

# pod-infrastructure:latest
原来镜像地址：registry.access.redhat.com/rhel7/pod-infrastructure:latest
替换镜像地址：linuxhub/pod-infrastructure:latest
镜像仓库地址：https://hub.docker.com/r/linuxhub/pod-infrastructure
使用文件：/etc/systemd/system/kube-controller-manager.service

# kubernetes-dashboard-amd64:v1.8.3
原来镜像地址：k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3
替换镜像地址：linuxhub/kubernetes-dashboard-amd64:v1.8.3
镜像仓库地址：https://hub.docker.com/r/linuxhub/kubernetes-dashboard-amd64
使用文件：./cluster/addons/dashboard/dashboard-controller.yaml

#kibana:5.6.4
原来镜像地址：docker.elastic.co/kibana/kibana:5.6.4
替换镜像地址：docker pull linuxhub/kibana:5.6.4
镜像仓库地址：https://hub.docker.com/r/linuxhub/kibana
使用文件：/cluster/addons/fluentd-elasticsearch/kibana-deployment.yaml

# elasticsearch:v5.6.4
原来镜像地址：k8s.gcr.io/elasticsearch:v5.6.4
替换镜像地址：linuxhub/elasticsearch:v5.6.4
镜像仓库地址：https://hub.docker.com/r/linuxhub/elasticsearch
使用文件：./cluster/addons/fluentd-elasticsearch/es-statefulset.yaml

# fluentd-elasticsearch:v2.0.4
原来镜像地址：k8s.gcr.io/fluentd-elasticsearch:v2.0.4
替换镜像地址：linuxhub/fluentd-elasticsearch:v2.0.4
镜像仓库地址：https://hub.docker.com/r/linuxhub/fluentd-elasticsearch
使用文件：./cluster/addons/fluentd-elasticsearch/fluentd-es-ds.yaml

# alpine:3.6
原来镜像地址：alpine:3.6
替换镜像地址：linuxhub/alpine:3.6
镜像仓库地址：https://hub.docker.com/r/linuxhub/alpine/
使用文件： ./cluster/addons/fluentd-elasticsearch/es-statefulset.yaml

# metrics-server-amd64:v0.2.1
原来镜像地址：k8s.gcr.io/metrics-server-amd64:v0.2.1
替换镜像地址：linuxhub/metrics-server-amd64:v0.2.1
镜像仓库地址：https://hub.docker.com/r/linuxhub/metrics-server-amd64
使用文件： ./cluster/addons/metrics-server/metrics-server-deployment.yaml

# addon-resizer:1.8.1
原来镜像地址：k8s.gcr.io/addon-resizer:1.8.1
替换镜像地址：linuxhub/addon-resizer:1.8.1
镜像仓库地址：https://hub.docker.com/r/linuxhub/addon-resizer
使用文件： ./cluster/addons/metrics-server/metrics-server-deployment.yaml

# heapster-amd64:v1.5.3
原来镜像地址：k8s.gcr.io/heapster-amd64:v1.5.3
替换镜像地址：linuxhub/heapster-amd64:v1.5.3
镜像仓库地址：https://hub.docker.com/r/linuxhub/heapster-amd64
使用文件：./cluster/addons/cluster-monitoring/influxdb/heapster-controller.yaml

# heapster-grafana-amd64:v4.4.3
原来镜像地址：k8s.gcr.io/heapster-grafana-amd64:v4.4.3
替换镜像地址：linuxhub/heapster-grafana-amd64:v4.4.3
镜像仓库地址：https://hub.docker.com/r/linuxhub/heapster-grafana-amd64
使用文件：cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml

# heapster-influxdb-amd64:v1.3.3
原来镜像地址：k8s.gcr.io/heapster-influxdb-amd64:v1.3.3
替换镜像地址：linuxhub/heapster-influxdb-amd64:v1.3.3
镜像仓库地址：https://hub.docker.com/r/linuxhub/heapster-influxdb-amd64
使用文件：./cluster/addons/cluster-monitoring/influxdb/influxdb-grafana-controller.yaml

# coredns:1.0.6
原来镜像地址：coredns/coredns:1.0.6
替换镜像地址: linuxhub/coredns:1.0.6
镜像仓库地址：https://hub.docker.com/r/linuxhub/coredns使用文件：./cluster/addons/dns/coredns.yaml