k8s外网如何访问业务应用之Service 池化pod

标签: geek | 发表时间:2019-07-05 00:00 | 作者:
出处:http://itindex.net/relian
一、废话:先讲述一个k8s重要概念,我觉得这个概念是整个k8s集群实现微服务的最核心的概念
概念:Service

Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制,用户不需要了解后台Pod是如何运行。只需要将一组跑同一服务的pod池化成一个service,k8s集群会自动给这个service分配整个集群唯一ip和端口号(这个端口号自己在yaml文件中定义),一个service定义了访问pod的方式,就像单个固定的IP地址和与其相对应的DNS名之间的关系。
Service其实就是我们经常提起的微服务架构中的一个"微服务",每个微服务后端负载均衡多个业务pod,由版本控制(deployment)控制pod数量,保证服务的高可靠性与冗余性。最终我们的系统由多个提供不同业务能力而又彼此独立的微服务单元所组成,服务之间通过TCP/IP(k8s集群分配的整个集群唯一的)进行通信,从而形成了我们强大而又灵活的弹性网络,拥有了强大的分布式能力、弹性扩展能力、容错能力;

理解service这个概念之后,我们跑去service后端看看具体是怎么实现的?
需求:有一个问题就是现在我的业务分配在多个Pod上,那么如果我某个Pod死掉岂不是业务完蛋了,当然也会有人说Pod死掉没问题啊,K8S自身机制Deployment和Controller会动态的创建和销毁Pod来保证应用的整体稳定性,那这时候还会有问题,那就是每个Pod产生的IP都是动态的,那所以说重新启动了我对外访问的IP岂不是要变了,别急,下面我们来解决下这个问题。

可以通过Service来解决如上所遇到的问题

二、Service是kubernetes最核心的概念,通过创建Service,可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求进行负载分发到后端的各个容器应用上。至于如何负载分发,我们不用去担心,k8s自己搞定。

简单来说Service就是一个把所有Pod统一成一个组,然后对外提供固定一个IP,具体是哪些Pod,可以通过之前介绍到的Label标签来进行设置,假设一个pod死掉,副本控制器在生成一个pod,这是pod ip肯定会变,但是我们不去关心你pod ip是多少,我们只知道service ip 没变就好了,因为新的pod 早就加入到我的service中了,各个服务之间通信是通过service 唯一ip来通信的。

上述所有操作,为什么实现了所谓的“”微服务”,举个大家都懂的例子;
一套简单的架构,nginx做反向代理,后端web为8个tomcat实例,在k8s集群中怎么实现呢,我只需要跑8个pod,每个pod运行tomcat容器,service池化这8个pod,而且副本控制会自动动态控制pod数量,少于8个他会创建到8个,多余8个会自动删除到8个。而且我们访问service ip,k8s中的kube-proxy会自动负载均衡后端的8个pod,这一套服务集群内部访问,只需要一个service ip 和端口号就可以;同理,redis集群,同样可以这样实现,每个service相当于微服务,各个服务之间灵活通信。

废话不多说,咱们直接实操演示
三、 创建副本控制资源名为nginx-deployment,运行两个pod,每个pod运行一个nginx容器,容器端口开放80.
   [[email protected] yaml]# cat nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx  
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx  就是说哪些Pod被Service池化是根据Label标签来的,此行nginx字样,后面我们创建Service会用到
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80


kubectl create -f nginx.yaml 
deployment.apps/nginx-deployment created

创建Service 池化刚才的两个nginx pod
   [[email protected] yaml]# cat nginx-svc.yml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 8080  这个资源(svc)开放的端口
    targetPort: 80

selector选择之前Label标签为nginx的Pod作为Service池化的对象,
最后说的是把Service的8080端口映射到Pod的80端口。

kubectl apply -f nginx-svc.yml 
service/nginx-svc created

创建完成之后nginx-svc会分配到一个cluster-ip,可以通过该ip访问后端nginx业务。
那它是怎么实现的呢?答案是通过iptables实现的地址转换和端口转换,自己可以去研究

那这时候有人说了,还是不能外网访问啊,别急下面我们来进行外网地址访问设置。在实际生产环境中,对Service的访问可能会有两种来源:Kubernetes集群内部的程序(Pod)和Kubernetes集群外部,为了满足上述的场景,Kubernetes service有以下三种类型:
1.ClusterIP:提供一个集群内部的虚拟IP(与Pod不在同一网段),以供集群内部的pod之间通信使用。
2.NodePort:在每个Node上打开一个随机端口并且每个Node的端口都是一样的,通过:NodePort的方式Kubernetes集群外部的程序可以访问Service。
3.LoadBalancer:利用Cloud Provider特有的Load Balancer对外提供服务,Cloud Provider负责将Load Balancer的流量导向Service

本篇文章我着重讲下第二种方式,也就是NodePort方式,修改nginx-svc.yml文件,也就是刚才前面创建的Service文件,相信细心的同学会发现在之前截图的时候已经做好了NodePort,因为我的环境已经配置好了所以这样就不在截图了,配置很简单,可以网上看下截图,就是添加一个type:NodePort,然后重新创建下nginx-svc,命令的话和创建的命令一样,我们来看看创建完事的结果。

如果刚开始你没有设置NodePort这个type的时候在端口那只会显示一个8080端口,而设置了之后会看到多了一个端口也就是37884,那8080就是是cluster-ip监听的端口,那37844就是在node节点上新起的一个端口(K8s会从30000~32767中分配一个可用的端口),只用于端口转发,转发到service的端口。
用户访问服务,每个节点都会监听这个端口,并转发给Service,service负载均衡调度后端pod,也就是防止说一个节点挂了影响访问>。
说的再通俗一点,集群内部可以直接通过service的ip+端口访问,而nodeport就是为了外网访问服务,给node开了一个端口,转发到service的ip+端口。
可能有人会问了,说这里的Service可不可以固定?当时可以了,可以在Service nginx-svc.yml文件里面添加一个nodeport。

在这里插入图片描述

当然,这个访问依然是负载均衡的!

相关 [k8s 外网 访问] 推荐:

k8s外网如何访问业务应用之Service 池化pod

- - IT瘾-geek
一、废话:先讲述一个k8s重要概念,我觉得这个概念是整个k8s集群实现微服务的最核心的概念. Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象. Service提供了一个统一的服务访问入口以及服务代理和发现机制,用户不需要了解后台Pod是如何运行. 只需要将一组跑同一服务的pod池化成一个service,k8s集群会自动给这个service分配整个集群唯一ip和端口号(这个端口号自己在yaml文件中定义),一个service定义了访问pod的方式,就像单个固定的IP地址和与其相对应的DNS名之间的关系.

使用kube-proxy让外部网络访问K8S service的ClusterIP

- - zzm
kubernetes版本大于或者等于1.2时,外部网络(即非K8S集群内的网络)访问cluster IP的办法是:. 修改master的/etc/kubernetes/proxy,把KUBE_PROXY_ARGS=”“改为KUBE_PROXY_ARGS=”–proxy-mode=userspace”.

CentOS7 安装 K8S

- - 企业架构 - ITeye博客
前提:VirtualBox CentOS7. 物理机IP   192.168.18.8. 虚拟机1IP:192.168.18.100(VMaster master). 虚拟机2IP:192.168.18.101(VServer1 node1). 虚拟机3IP:192.168.18.102(VServer2 node2).

k8s docker集群搭建 - CSDN博客

- -
一、Kubernetes系列之介绍篇.     - 一次构建,到处运行. 2.什么是kubernetes.   首先,他是一个全新的基于容器技术的分布式架构领先方案. Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg). 在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性.

K8S的SDN容器网络解决方案及其价值

- - SegmentFault 最新的文章
编者按:关于容器网络的解决方案业界已经有较多的讨论,笔者无意继续赘述. K8S及其网络模型体现了鲜明的解耦设计思想,采用SDN技术实现K8S容器网络,并与相应的生态组件形成SDN监管控一体化解决方案,可以更好地提高整个系统的运营水平,更有效地提升企业的核心竞争力. 本文拟抛砖引玉,从K8S的网络实现入手,重点阐述SDN在容器网络中的应用价值.

构建生产就绪的K8S集群的16点清单

- - SegmentFault 最新的文章
Kubernetes是用于构建高度可扩展系统的强大工具. 结果,许多公司已经开始或正在计划使用它来协调生产服务. 不幸的是,像大多数强大的技术一样,Kubernetes也很复杂. 我们整理了以下清单,以帮助你生产环境最佳实践Kubernetes. Kubernetes提供了一种编排容器化服务的方法,因此,如果您没有按顺序实践你的容器,那么集群一开始就不会处于良好状态.

9 个技巧,解决 K8s 中的日志输出问题

- - DockOne.io
作者 | 元乙  阿里云存储服务技术专家. 导读:近年来,越来越多的同学咨询如何为 Kubernetes 构建一个日志系统,或者是来求助在此过程中遇到一系列问题如何解决,授人以鱼不如授人以渔,于是作者想把这些年积累的经验以文章的形式发出来,让看到文章的同学少走弯路. K8s 日志系列文章内容偏向落地实操以及经验分享,且内容会随着技术的迭代而不定期更新,本文为该系列文章的第 3 篇.

在 k8s 中对指定 Pod 进行抓包

- -
Distributed Tracing时,遇到了一些问题,需要深入到底层去进行网络抓包分析报文. 但是应用时运行在 k8s 集群中的,与传统的在一台机器上跑一个进程直接通过 tcpdump 抓包方式略有不同. 最初对容器的理解不深刻认为一定要进入到这个容器抓包,而进入容器内并没有 tcpdump 等基础工具,相当于自己还是把容器当作虚拟机在看待.

K8S故障排除方法 - 笃行之 - 博客园

- -
1.查看pods哪些是有问题的,Runningg正常,其他异常;. 解决办法:参考:https://github.com/kubernetes-sigs/kubespray/issues/2798. 我这边是NotReady状态,经排查发现, node18.147上面的kubelet kube-proxy挂掉了,服务启来后就可以了.

大量海外网盘无法正常访问

- 意大利种马 - Solidot