Kubernetes集群之Service完整知识

Kubernetes集群之Service实战案例——\hKubernetes集群之\hKubernetes集群各节点的规划见表1-1，采用单Master集群部署架构。表1-1节点规划master基础\hIP所有节点安装CentOS7.5_1804系统，并配置主机名和网卡。[root@localhost~]#hostnamectlset-hostname[root@localhost~]#[root@master~]#cat/etc/sysconfig/network-scripts/ifcfg-Service周期。我们知道Pod资源对象在自愿或非自愿终端后，只能被重构的Pod式下，Service为该类Pod其实，就是说Pod存在生命周期，有销毁，有重建，无法提供一个固定的访问接口给客户端。并且为了同类的Pod都能够实现工作负载的价值，由此Service资源出现了，可以为一类Pod资源对象提供一个固定的访问接口和负载均衡，类似于阿里云的负载均衡或者是VS的功能。但是要知道的是，Service和Pod对象的IP地址，一个是虚拟地址，一个是PodIP地址，都仅仅在集群内部可以进行访问，无法接入集群（hostNetwork）以外，还可以使用NodePort或者是LoadBalancer类型的Service资源，或者是有7层负载均衡能力的IngressService是Kubernetes的核心资源类型之一，Service资源基于标签选择器将一组Pod定义成一个逻辑组合，并通过自己的IP地址和端口调度代理请求到组内的Pod对象，如图1-1所示，处理用户请求的Pod资源，使得从客户端上看，就像是由Service直接处理并响应一样，是不是很像负载均衡器呢！Service对象的IP地址也称为ClusterIP，它位于为Kubernetes集群配置指定专用的IP地址范围之内，是一种虚拟的IP地址，它在Service对象创建之后保持不变，并且能够被同一集群中的Pod资源所访问。Service端口用于接受客户端请求，并将请求转发至后端的Pod应用的相应端口，这样的代理机制，也称为端口代理，它是基于TCP/IP协议栈的传输层。service ExternalName的形式。在Kubernetesv1.0版本，代理完全在Userspace。在Kubernetesv1.1版本，新增了Iptables代理，但并不是默认的运行模式。从Kubernetesv1.2起，默认就是Iptables代理。在Kubernetesv1.8.0-beta.0中，添加了Ipvs代理。在Kubernetesv1.0版本，Service是“4层”（TCP/UDPoverIP）概念。在Kubernetesv1.1版本，新增了IngressAPI（Beta版），用来表示“7层”（HTTP）服Kube-proxy这个组件始终监视着APIServer Userspace如图1-2所示的这种模式，当客户端Pod请求内核空间的ServiceIptables后，把请求转到给用户空间监听的Kube-proxy的端口，由Kube-proxy来处理后，再由Kube-proxy将请求转给内核空间的ServiceIP，再由ServiceIptalbes根据请求转给各节点中的的ServicePod。由此可见这个模式有很大的问题，由客户端请求先进入内核空间的，又进去用户空间访问Kube-proxy，由Kube-proxy封装完成后再进去内核空间的Iptables，再根据Iptables的规则分发给各节点的用户空间的Pod。这样流量从用户空间进出内核带来的性能损耗是不可接受的。在Kubernetes1.1版本之前，Userspace是默认的代理模型。Iptables客户端IP请求时，直接请求本地内核ServiceIP，根据Iptables的规则直接将请求转发到到各Pod上，因为使用IptableNAT来完成转发，也存在不可忽视的性能损耗。另外，如果集群中存在上万的Service/Endpoint，那么Node上的IptablesRules将会非常庞大，性能还会再打折扣。Iptables代理模式由Kubernetes1.1版本引入，自1.2版本开始成为默认类型。IpvsIpvs的规则直接分发到各Pod上。Kube-proxy会监视KubernetesService对象和Endpoints，调用Netlink接口以相应地创建Ipvs规则并定期与KubernetesService对象和Endpoints对象同步Ipvs规则，以确保Ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后与Iptables类似，Ipvs基于Netfilter的Hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着Ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外Ipvs为负载均衡算法提供了更多选项，例如：rrlcdhshsednqIpvs模式假定在运行Kube-proxy之前在节点上都已经安装了IPVS内核模块。当Kube-proxy以Ipvs代理模式启动时，Kube-proxy将验证节点上是否安装了IPVS模块，如果未安装，则Kube-proxy将回退到Iptables代理模式。在集群内部对一个服务的访问，主要有两种方式：环境变量与DNS当一个Pod运行在Node上时，Kubelet将为每一个活动的ServiceDockerLink环境变量：相当于 的-link参数实现容器连接时设置的环境变量KubernetesService环境变量：Kubernetes为Service设置的环境变量形式，{SVCNAME}SERVICE_HOST例如，存在一个名称为redies-master的Service（它的ClusterIP地址为1，端口号为6379，协议为TCP），它的环境变量如下所```shellREDIS_MASTER_SERVICE_HOST=1REDIS_MASTER_SERVICE_PORT=6379REDIS_MASTER_PORT_6379_TCP_PROTO=tcpREDIS_MASTER_PORT_6379_TCP_PORT=6379REDIS_MASTER_PORT_6379_TCP_ADDR=1```Service必须在Pod创建之前被创建，否则Service变量不会被设置到PodDNSDNS服务发现是基于ClusterDNS的，DNS服务器会对新服务进行监控，并为每一个服务创建DNS记录，用于域名解析。在集群中，如例如，如果在my-ns命名空间下拥有一个名为my-serivce的服务，则会有一个名为my-service.my-ns的DNS在my-ns命名空间下，Pod将能够通过名称my-service在其它命名空间，Pod必须通过my-serivce.my-ns来发现此服务，此名称选址的结果即为ClusterIPKubernetes也支持端口的DNSSRV记录。如果my-service.my-ns服务拥有一个TCP协议名称为http的端口，就能够通过http.tcp.my-service.my-ns名称来发现http端口的值。KubernetesDNS服务器是发现ExternalName类型服务的唯一途径。Service类型。默认情况下使用ClusterIP。KubernetesClusterIP(default)：将服务暴露在集群内部的IPNodePort：将服务暴露在所选定每一个Node的同一端口，集群外可以通过<NodeIP>:<NodePort>LoadBalancerExternalName：使用一个随意的名称来暴露服务，并会返回一个带有名称的CNAME LoadBalancer服务是暴露服务至\h互联网最标准的方案，除了具有集群内部IP以及在NodePort上公开服务之外，还要求云提供商负载来自外部负载均衡器的流量将被定向到后端Pod，尽管其工作原理取决于云提供商。一些云提供商允许指定LoadBalancerIP。在这些情ExternalName是Service的特例，它没有SelectorEndpoint。对于运行在集群外部的服务，它通过返回该外3.5节点将提供的/chinaskills_cloud_paas.iso上传至/root目录挂载并把内容拷贝到/opt[root@localhost~]#hostnamectlset-hostname[root@localhost~]#[root@master~]#curl-O\h[root@master~]#curl-O\h[root@master~]#curl-O\h[root@master~]#mount-oloopchinaskills_cloud_paas.isomount:/dev/loop0iswrite-protected,mountingread-[root@master~]#cp-rvf/mnt/*[root@master~]#umount[root@master~]#mv/etc/yum.repos.d/*[root@master~]#vibaseurl=file:///opt/kubernetes-[root@master~]#vi localhostlocalhost.localdomainlocalhost4 localhostlocalhost.localdomainlocalhost60 //注意：改为实际分配的master节点IP配置防火墙和SELinux（[root@master~]#systemctlstopfirewalld&&systemctldisable[root@master~]#iptables-[root@master~]#iptables-[root@master~]#iptables-[root@master~]#iptables-[root@master~]#sed-i's/SELINUX=enforcing/SELINUX=disabled/g'进入/opt目录下，执行harbor，k8s-master节点脚本，部署k8s[root@master~]#cd[root@masteropt]#[root@masteropt]#输入镜像仓库地址(不加http/https): //注意：改为实际分配的master节点IP地输入镜像仓库用户名:输入镜像仓库用户密码:您设置的仓库地址为:0,用户名:admin,密码:是否确认(Y/N):[root@masteropt]#创建[root@masteropt]#dockerload-iec5652c3523d:Loadinglayer76d3e24d63f6:Loadinglayerf281464c05be:Loading 7fde79e38c03:Loadinglayer6d4185a1708b:LoadinglayerLoadedimage:[root@masteropt]#dockerimages|grep

02c055ef67f5:Loadinglayer 8months goharbor/redis- 16months [root@masteropt]#dockertagbc8d70f9ef6c //注意：改为实际分配的master节点IP[root@masteropt]#dockerpushThepushreferstorepository6d4185a1708b:7fde79e38c03:f281464c05be:76d3e24d63f6:ec5652c3523d:02c055ef67f5:latest:digest:sha256:51a0aaedaa10f05a229a54e1c2977399be0ed5493e8f47304c9aac7aa4b1af84size:[root@masteropt]#viredis-apiVersion:kind:name:redis-namespace:replicas:app:release:app:release:-name:image: //注意：改为实际分配的master节点IP-name:containerPort:[root@masteropt]#kubectlapply-fredis-deployment.apps/redis-pod[root@masteropt]#kubectlget redis-pod-67dc75b75d- redis-pod-67dc75b75d- redis-pod-67dc75b75d- 清单创建[root@masteropt]#kubectlexplain VERSION:Serviceisanamedabstractionofsoftwareservice(forexample,consistingoflocalport(forexample3306)thattheproxylistenson,theselectorthatdetermineswhichpodswillanswerrequestssentthe APIVersiondefinestheversionedschemaofthisrepresentationofobject.Serversshouldconvertrecognizedschemastothelatestvalue,andmayrejectunrecognizedvalues.Morehttps://git.k8s.io/community/contributors/devel/sig-architecture/api-kind

KindisastringvaluerepresentingtheRESTresourcethisrepresents.Serversmayinferthisfromtheendpointtheclientrequeststo.Cannotbeupdated.InCamelCase.Morehttps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types- Standardobject'smetadata.Morehttps://git.k8s.io/community/contributors/devel/sig-architecture/api-specSpecdefinesthebehaviorofahttps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and- Mostrecentlyobservedstatusoftheservice.PopulatedbytheRead-only.Morehttps://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-创建redis的[root@masteropt]#viredis-apiVersion:kind:name:namespace:app:release:type:-port:targetPort:nodePort:[root@masteropt]#kubectlapply-fredis-service/redis[root@masteropt]#kubectlget CLUSTER- EXTERNAL- [root@masteropt]#kubectldescribesvc Selector: <unset> <unset>Endpoints: 7:80,8:80,9:80Session ExternalTrafficPolicy: 从以上演示可以总结出：Service不会直接到Pod，Service是直接到Endpoint资源，就是地址加端口，再由Endpoint再关联到PodNodePort的ServiceNodePort即节点Port，通常在部署Kubernetes集群系统时会预留一个端口范围用于NodePort，其范围默认为30000~32767之间的端口。定义NodePort类型的Service资源时，需要使用.spec.type进行明确指定。[root@masteropt]#vimyapp-apiVersion:kind:name:myapp-namespace:replicas:app:release:app:release:-name:image:-name:containerPort:[root@masteropt]#kubectlapply-fmyapp-deployment.apps/myapp-pod[root@masteropt]#vimyapp-apiVersion:kind:name:namespace:app:release:type:-port:targetPort:nodePort:[root@masteropt]#dockerload-id39d92664027:Loadinglayer8460a579ab63:Loadinglayerc1dc81a64903:Loadinglayer68695a6cfd7d:Loadinglayer05a9e65e2d53:LoadinglayerLoadedimage:[root@masteropt]#kubectlapply-fmyapp-service/myapp[root@masteropt]#kubectlgetpod-n myapp-pod-559ff5c66- myapp-pod-559ff5c66- myapp-pod-559ff5c66- redis-pod-67dc75b75d- redis-pod-67dc75b75d- redis-pod-67dc75b75d- [root@ma