K8S初探

      K8S是一个容器编排工具，其实也是管理应用的全生命周期的一个工具。从建立应用，应用的部署，应用提供服务，扩容收缩应用，应用更新都很是的方便。并且能够作到故障自愈，例如一个服务器挂了，能够自动将这个服务器上的应用调度到另一个主机上运行，无需人工干预。

       k8s的全生命周期管理：在k8s进行管理应用的时候，基本步骤是：建立集群，部署应用，发布应用，扩展应用，更新应用。

       k8s集群： k8s在物理上进行划分的时候，划分了两种类型的主机，一个是master节点：主要用来调度，控制集群的资源等，另外是node节点：主要用来运行容器的节点，也就是运行服务的节点。

      其实集群都差很少，master用来控制，存储各类元数据，node节点是一个工做节点，真正来干活的。node节点定时与master进行通信，经过kubectl进程进行汇报信息。

      建立集群的目的是为了提供服务，让应用程序可以在集群上运行。

      有了image以后，一条指令就能运行一个应用。因此在开发完应用以后，须要程序打包成image，而后放到registry中，而后可以运行应用了。

       kubectl run key --image=nginx:1.79 --port=80

       kubectl get deployments/kel

      在完成应用部署以后，就能够看到应用的名称，指望状态是运行一个pod，当前有一个pod，活动的也是一个。

      那么什么是pod呢？ 在k8s里面，集群调度的最小单元就是一个pod，一个pod能够是一个容器，也能够是多个容器，例如你使用一个程序，其中使用了nginx,使用了mysql，使用了jetty，那么能够将这三个使用在同一个pod中，对他们提供统一的调配能力，一个pod只能运行在一个主机上，而一个主机能够运行多个pod。

       为何要使用pod，为何不能直接使用容器呢？使用pod至关于一个逻辑主机，还记得建立一个VM，在VM上运行几个进程么，道理是同样的。pod的存在主要是让几个紧密连接的几个容器直接共享，例如ip地址，共享存储信息。若是直接调度容器的话，那么几个容器可能运行在不一样的主机上，这样就增长了系统的复杂性。  

       发布应用

      发布应用就是为对外提供服务，可能会有人提出疑问，我都运行了服务为什还不能提供服务，这是由于在集群中，建立的IP地址等资源，只有在同一个集群中才能访问，每一个pod都会有惟一的ip地址。当有多个pod提供相同的服务的时候，就须要有负载均衡的能力。从而这里涉及到的一个概念就是service，专门用来提供服务。

   基于pod建立一个service：

   kubectl expose deployment kel --type="NodePort" --port=80

   kubectl get services/kel

    服务主要用来提供对外访问的接口，服务能够关联一组pod，这些pod的ip地址各不相同。而service至关于一个负载均衡的vip，用来指向各个pod。当pod的ip地址发生变化的时候，也能作到自动化负载均衡，在关联的时候，service与pod直接主要经过label来关联，也就是标签（-l表示label）

      kubectl get services -l run=kel        

      kubectl get pods -l run=kel    

      kubectl describe   service/kel    

      容器扩容：

      在业务上线以后，怎样进行动态的扩容和收缩呢？ 只要有一个pod，那么就能够产生无数个pod。这样就具有了横行扩展的能力

      kubectl scale deployments/kel --replicas=3

      应用更新： 

      有新版本了，须要发布。滚动更新，根据新的image建立一个pod，分配各类资源。而后自动负载均衡，删除老的pod，而后继续更新，不会中断服务。

      kubectl set image deployments/kel kel=nginx:1.8

      滚动更新：根据新的image建立一个pod,分配各类资源，而后自动负载均衡，删除老的pod，而后继续更新。不会出现中断服务。     

    kubectl rollout undo  deployments/kel

 

DashBoard

1.建立dashboard服务

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml

2. 生成登录token

       kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

3. 启动API Server 

      kubectl proxy 

4.访问dashboard   本地访问URL

       http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/overview?namespace=default

    基于k8s部署的应用如何访问：

       首先了解kubernate 网络模型设计的基础原则：每一个pod拥有一个独立的ip地址，而且假定全部的pod都在一个直接连通的,扁平的网络空间中。

      1.集群内部访问：

        1.1 经过pod的ip访问  这种方式是不可靠的，当pod重启后，它的IP会从新分配。

             不一样的pod的访问方式能够用endpoint方式：pod的IP+容器的端口

        1.2 经过服务访问  经过建立service,能够为一组具备相同功能的容器应用提供统一的入口地址，这个地址不会由于pod的重启而发生变化。

          访问方式：clusterIp+containerPort

     2.集群外表访问

        2.1 直接访问容器  

             在启动pod的rc/deployment中指定容器的hostport，并设置pod级别的hostwork=true，这样直接经过主机ip+hostport就能够实现访问

        2.2 经过service访问。

             2.2.1 NodePort方式

              在service的yaml中配置nodePort参数。这一集群会在每个node上为须要外部访问的service开启一个TCP监听端口，外部系统只须要用任意一个Node的ip地址+具体的NodePort端口号就能够访问此服务。不过这种方式没有解决node层负载均衡问题。（pod层kube-proxy会自动实现负载均衡分发到多个pod上，可是node层不能负载分发到多个node）

           2.2.2 若是使用外部公有云平台,如aws，azure部署时，可使用 loadbalance方式，配置外部负载均衡器，对service的请求

        2.3 Ingress    

            Ingress是k8s单独定义的对象，它的做用就是单独对外暴露负载访问的均衡，它和service的自己的loadbalance区别在于：

            Ingress支持L4，L7负载均衡，LoadBalance设计上支持L4.

            Ingress基于pod部署 ，并将pod设置为external network。

            Ingress controller支持nginx,Haproxy,GCE-L7,可以知足企业内部使用。