k8s架构中kube proxy组件的学习总结。

Kubernetes，简称k8s，相信大家都不陌生了，它是专门为容器编排管理提供的一套解决方案。本质上就是一套集群环境。这个集群环境中，有两个角色，一个是master，一个是work，其中master充当着领导者的角色，work充当着干活的角色。大白话也就是，接到任务之后领导者负责任务管理指挥，work接受到任务之后，去执行，真正的去把工作落实。

master角色中又进行了分工，根据任务的不同，细分为以下组件：API server、scheduler、etcd、controller manager。

work角色中也是一样，根据任务的不同划分为：kubelet、kube proxy.

本文要介绍的就是kube proxy这个组件，它是个啥呢？

我们知道，k8s的初衷就是对容器进行管理编排，但是k8s不直接去管理容器，而是通过自己定义的pod去管理它，也就是说k8s管理的最小单元就是pod,而容器是跑在pod里面的。所以也是间接的管理容器了。

学过docker的人应该知道，容器其实就是类似虚拟化了一套操作系统，它是虚操作系统，和vmware不一样，VMware是虚硬件，是将整个硬件等全部划分，最后在这个上面装操作系统，虚机和虚机之间资源是隔离的。而容器不是，容器是公用硬件，只是操作系统隔离，他们公用宿主机上的一套硬件。既然有了操作系统，那么在操作系统上装上应用程序就可以跑起来了。

以上忽略，我其实也没有系统的学习过容器，就是知道容器和虚机都是虚拟化技术的两种方式，知道他们的大概区别。（后面学习了再更新容器和docker的相关文章）

回到正题。。。。。
kube proxy是个啥？pod是有ip的，这个ip是随机分配的，只要pod重启，那么这个ip地址就会变动，那么如果外部想要访问它，就很麻烦了，所以为了解决这个问题，对外提供一个统一的代理服务，用来接受请求，代理服务拿到请求之后，会根据映射关系把请求发到对应的pod上，那么这个代理就叫service，对应的k8s组件干活的就是kube proxy。

因为k8s中的资源都是通过yaml文件进行创建的，那么kube proxy是如何去工作呢？是通过yaml文件进行service参数声明，并进行创建之后，kube proxy这个组件就会按照这个模板就行工作，去把请求分发到不同的pod上。

下面来看下service这个资源的yaml文件中声明的参数：

kind: Service #资源类型
apiVersion: v1 #资源版本
metadata： #元数据
	name: service #资源名称
	namespace：dev
spec: #描述
	selector：#标签选择器，用于确定当前service代理哪些pod
		app:nginx
	type:#service类型，指定service的访问类型。
	clusterIP:#虚拟服务ip地址，会被k8s默认分配，只能集群内部访问
	sessionAffinity: #session亲和性，支持clientIP、None两个选项
	ports: #端口信息
		- protocol:TCP
		- Port：3017 #service端口
		- targetPort：5003 #pod端口
		- nodePort:31122 #主机端口

service和pod之间是怎么建立关联呢？是通过标签选择器，也就是上面的selector。

[admin@uc12 ~]$ kubectl describe svc test-alarm -n dev
Name:                     itom-alarm-dm-svc
Namespace:                dev
Labels:                   name=test-alarm
                          role=service
Annotations:              <none>
Selector:                 app=job-alarm
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv6
IP:                       fd00:10:96::f1cf
IPs:                      fd00:10:96::f1cf
Port:                     receiver  162/UDP
TargetPort:               162/UDP
NodePort:                 receiver  162/UDP
Endpoints:                [fd00:177:177:0:3ce3:e42f:5490:117d]:162,[fd00:177:177:0:a97b:6ba7:f54e:71f3]:162,[fd00:177:177:0:ad55:f79a:1f73:dbe3]:162
Port:                     check  162/TCP
TargetPort:               162/TCP
NodePort:                 check  162/TCP
Endpoints:                [fd00:177:177:0:3ce3:e42f:5490:117d]:162,[fd00:177:177:0:a97b:6ba7:f54e:71f3]:162,[fd00:177:177:0:ad55:f79a:1f73:dbe3]:162
Session Affinity:         None
External Traffic Policy:  Local
Events:                   <none>

上面的endpoints其实就是service映射的pod的ip地址和端口号。
Type：表示的是这个服务访问的权限范围，取值为：clusterIP和NodePort，loadbalancer和externalname.如果是clusterIp那么这个只能集群内部访问，不在集群内的节点是无法访问的，声明为NodePort的话，就是可以被不在集群内的节点访问。loadbalancer是在nodeport的外部再加个负载均衡的设备，外部服务器访问请求到这个负载均衡设备上之后，进行一个负载分发之后，后面就和nodeport一样了，这里就不做介绍了。externalname的作用就是指定一个外部服务的地址，然后在集群内部访问此service就可以访问到外部服务了。

session affinity—负载分发策略：
如果不设置，默认使用k8s的策略，比如随机或者是轮询。
用户可以通过设置为基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都转发到固定的一个pod上，此模式可以使在spec中添加session affinity：clientIP选项

下面再来说一个知识点，就是我们的service是有一个集群ip，叫做clusterIP，这个地址可以自己配，可以不配，k8s会自动给我们生成。也可以配成None，那么这个时候就变成了没有iP地址，那么怎么访问呢，是通过域名来访问，当配置成None，就叫做无头服务。也就是，headliness类型。

下面再来介绍一下type，取值可以是clusterIP和NodePort.
声明为前者的话，那么pod只能在内部集群中访问，声明为NodePort，那么pod可以被外部服务器访问。
工作原理：既然是外部服务器可以访问，首先外部服务器的网络肯定是和集群内的节点的ip是通的，想访问的话，最简单的方式就是访问节点ip+端口号，这个端口号就是nodePort，那么只要把这个端口号和pod的service的端口号（也就是上面yaml文件中的Port做个映射），就可以访问pod了，后面的事就交给service了。

大概就是上面那样。
type是externalname:
配置如下：

spec:
	type: ExternalName
	externalName: www.baidu.com#ip 也是可以的。

表示将外部服务暴露给内部pod使用。