K8S + RANCHER 随记

rancher中快速部署应用 · 志云的博客 (zhenglin.work)

Docker+Rancher容器部署Spring Cloud项目_ThinkMore-CSDN博客

Rancher+Docker实现SpringCloud容器部署 - 程序员大本营 (pianshen.com)

NodePort 只能在当前node节点上访问，集群其他node或外网无法访问 - 水中的火柴盒 - 博客园 (cnblogs.com)

解决：在各node上配置iptables，执行下面命令就行了 sudo iptables -P FORWARD ACCEPT

k8s外网如何访问业务应用 - 简书 (jianshu.com)

包含K8s-Service各种端口含义的重要概念:

K8s-Service：nginx-svc，图中可见当前服务有两个POD(Endpoints)。

Nginx-svc  Cluster-ip：10.0.0.27 (k8s分配的内部不变的虚拟ip)。

Port：nginx-svc的宿主机端口，通过此端口访问到此k8s-Service(集群内访问service)。

Targetport：映射的docker容器端口。

Selector：Pod选择器，Pod-Lable的条件过滤器。图中Selector表示，Service查找Lable中app=nginx的Pod。

Endpoints：nginx-svc各个pod的真实物理地址。

NodePort ：各个pod的宿主机(node)上的nginx-svc代理端口，访问任意一个宿主机的37844端口，都能负载均衡访问nginx-svc服务(集群外访问service)。

k8s集群内部访问service：Cluster-ip:port、服务名.命名空间:port

k8s集群外部访问service：任意Node-ip:nodeport

Service的三种端口：

port：service暴露在cluster ip上的端口，port 是提供给集群内部客户访问service的入口。

nodePort：nodePort是k8s提供给集群外部客户访问service入口的一种方式，nodePort 是提供给集群外部客户访问service的入口。

targetPort：targetPort是pod上的端口，从port和nodePort上到来的数据最终经过kube-proxy流入到后端pod的targetPort上进入容器。

port、nodePort总结：
总的来说，port和nodePort都是service的端口，前者暴露给集群内客户访问服务，后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理kube-proxy流入后端pod的targetPod，从而到达pod上的容器内。

k8s集群内部访问service：Cluster-ip:port、服务名.命名空间:port

k8s集群外部访问service：任意Node-ip:nodeport

K8S中几种IP：

POD IP: pod的IP地址，是虚拟地址，无法ping通。

Cluster IP：Service的IP地址，是虚拟地址，无法ping通。他只能结合service：port一起使用。

Node IP：物理机IP地址。K8S集群外节点访问集群内节点，都需要通过Node IP。

k8s名词解释 | Rancher文档

Rancher 名词解释 | Rancher文档

K8S中的重要角色：

1. NameSpace：划分虚拟集群，便于隔离项目、团队、业务的资源。
2. Pod：最小调度单元，一个POD相当于一个运行的docker镜像容器服务。由RC/DM的配置创建POD。同一个POD内应用可以用localhost相互访问。
3. Node：一台服务器资源，物理机。
4. Replication Controller(RC)：Pod控制器，监控指定条件(一般是指相同服务/lable)的Pod实例状态与数量。配置pod的docker镜像路径，设置pod的lable，创建/监控/维持pod运行数量，pod总量扩容缩容，配置pod的创建模板，配置pod环境变量，pod部署的主机调度，pod资源限制等。
5. Deployment(DM)：RC的升级版Pod控制器。增加版本控制、版本回滚、升级控制等。
6. ReplicaSet代表一个版本的Pod服务组合。
7. Service：相当于一个微服务的概念。为一组相同功能服务的Pod(RC\DM)提供对外访问、通过selector进行Pod选择，定义了一组Pods的逻辑集合。实现pod路由的能力、配置网络模式、服务发现、负载均衡等。
8. Lable：标签。使一组Pod与Service、RC、DM等产生关联。Pod定义lable，Service、RC、DM通过lable选择器(selector) 选择运行中的Pod。也可以为Node配置标签，实现主机调度策略等。

rancher中的工作负载workload：相当于Service+Deployment(还有其他选项)+Pod的综合配置。

Kubernetes Service NodePort 外网访问_小楼一夜听春雨，深巷明朝卖杏花-CSDN博客

上图中Replication Controller可以替换为Deployment。

k8s几种网络模式：

1. 域名负载均衡
   1. 负载策略是轮询
   2. 外部访问（互联网、K8S集群以外）容器，推荐这种。减少一次解析。
2. HostPort   :  在宿主机上直接开端口映射到pod。访问<宿主机NodeIP>: 
   1. 只能通过容器的宿主机IP才可以访问。
   2. 一个Node宿主机上，同一个k8s-Service，只能部署一个pod。所以rancher为service扩容增加pod时，pod会部署到集群中不同服务器上。
      1. 原因 ：端口占用，不可以重复
   3. 不具备k8s负载均衡功能

 hostNetWork=ture , POD所有容器的端口直接映射到物理机端口。

      3. NodePort （所有主机的NodePort 均可访问到Service）。一个k8s-Service在每一个部署此Service的Pod的Node宿主机上开设一个相同的固定Port，外部访问任意一个Node上的此Port时，都可以通过kube-proxy实现这个k8s-Service的负载均衡访问。 Cluster 外部可以通过 <任意NodeIP>: 访问 Service。

如果没有为Service手工指定NodePort，则k8s随机分配一个端口，NodePort随机端口范围：30000-32767。

1. 一个宿主机上，同一个docker镜像可运行多个pod，不存在端口占用的情况
2. 具备负载功能，通过kube-proxy实现。
   1. 不是轮询，也不是随机，目前并未确定到底是什么
   2. 目前已知的 负载策略（修改kube-proxy配置）

• rr: round-robin
• lc: least connection
• dh: destination hashing
• sh: source hashing
• sed: shortest expected delay
• nq: never queue

--proxy-mode=ipvs //将kube-proxy的模式设置为IPVS	
--ipvs-scheduler=rr //设置ipvs的负载均衡算法，默认是rr	
--ipvs-min-sync-period=5s // 刷新IPVS规则的最小时间间隔	
--ipvs-sync-period=30s // 刷新IPVS规则的最大时间间隔

1. 情况说明
   1. 不同的客户端，访问的容器不相同
   2. 一个宿主机IP ，在请求次数少的情况下很长一段时间内会只转发到一个容器上。
   3. 当请求数量变多后，开始负载到其他容器中。

HostPort  与 NodePort 一个重要区别是，HostPort是宿主机端口直接映射POD。而 NodePort是访问到主机的kube-proxy，再通过服务的clusterip转发到任意pod中。

kube-proxy

服务发现

k8s中Service通过selector筛选Pod-lable，定义了一组Pods的逻辑集合和一个用于访问它们的策略。实现pod路由、配置网络模式、服务发现、负载均衡等。

服务与服务之间调用，可以直接通过Cluster-IP:服务端口  或 http://服务名.命名空间:服务端口(svc-port是内网端口，不是nodeport)。

又上可见k8s-Service会创建一个固定域名(服务名.命名空间)。

CoreDNS: K8S集群内部通过CoreDNS为服务提供域名解析服务。将Service域名解析成服务的ClusterIp。

Service级别灰度发布

创建两个Deployment，分别对应两个版本docker镜像，Lable设置相同的标签，比如：app=service1。两个Deployment启动后，会创建两种POD，且Lable都有app=service1。

单独创建一个Service，pod-selector设置为app=service1。

或者修改现有Service的pod-selector条件，让其可以调度两个不同Deployment创建的POD。

这样通过一个Service+两个Deployment，控制同一个服务下两个版本Pod的比例。

Ingress代理服务

对集群内/外部提供负载均衡访问（轮序），ingress-nignx还支持权重路由、http-header/cookies路由、Session关联路由、灰度发布、URL重写转发、限流等功能。Ingress 注释 annotations 说明

使用场景：1 为所有service提供对外统一出口 2 为某一个service提供代理

环境变量

Deployment环境变量优先级大于应用内自身配置。

Headless-Service

无头服务没有Cluster-ip，不对外直接提供服务。

无头服务通过Selector选择POD，并为选中的POD创建固定DNS域名：PodName.无头服务名.命名空间(同一命名空间下的Pod可以省略命名空间)。被无头服务select的POD之间可以通过域名相互访问。

StatefulSet

 k8s之StatefulSet详解_k8s statefulset

StatefulSet是Deployment的特别版，也是一种创建和管理POD的控制器。

特性：

Pod一致性：包含次序（启动、停止次序，先启动-pod0，最后关闭-pod0）、网络一致性。此一致性与Pod相关，与被调度到哪个node节点无关；
稳定的次序：对于N个副本的StatefulSet，每个Pod都在[0，N)的范围内分配一个数字序号，且是唯一的；
稳定的网络：Pod-name模式为(statefulset名称)−(序号)；通过Headless服务，为每一个POD提供固定的DNS域名：PodName.无头服务名.命名空间。
稳定的存储：通过VolumeClaimTemplate为每个Pod创建一个PV。删除、减少副本，不会删除相关的卷。

组成：

Headless Service：用来定义Pod网络标识域名( DNS domain)，使POD可以通过固定域名相互访问。 

StorgeClass：创建一个存储类。

PV：创建N个PV并且绑定刚创建的StorgeClass，一个POD对应一个PV。

volumeClaimTemplates ：存储卷申请模板，绑定StorgeClass，并指定每个PVC申请存储大小。POD初始化时会根据模板创建PVC，PVC从存储类StorgeClass中绑定可用PV；

StatefulSet ：定义具体应用，名为Nginx，有三个Pod副本，并为每个Pod定义了一个域名部署statefulset。

注意：

Headless Service与StatefulSet要有相同的POD-Selector，这样Headless Service才能为StatefulSet的POD创建固定域名。