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.
   [root@master 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
   [root@master 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水平扩容

- - Bboysoul's Blog
k8s 的好处就是可以弹性水平扩容和纵向扩容,平时纵向扩容用的不太多,所以今天说说水平扩容,在创建hpa之前你要确定集群中已经安装了metrics-server,我使用的是k3s,直接自带. 首先创建需要的容器,下面是dockerfile. 原理就是当你访问index.php的时候会进行一个循环计算来提高cpu的使用率.

# [k8s] HPA: Horizontal Pod Autoscaling

- - V2EX - 技术
HPA 是 K8S 的一大利器. 通过 HPA, 我们可以让服务的 pod 数量根据特定指标自动增加或减少, 使得在高峰期有足够的资源服务请求, 在低峰期又可以避免占用过多的资源. 同时, 在 SOA 架构下, 我们也习惯通过 HPA 来避免劳心劳力的为每个微服务计算所需的资源.. minReplicas: 允许的最小 pod 数量.

k8s 使用rolebinding限制或增加访问命名空间以及可执行操作权限_直到世界的尽头-CSDN博客

- -
权限控制原理 RBAC——基于角色的访问控制. 基于角色的访问控制(Role-Based Access Control, 即”RBAC”). k8s使用”rbac.authorization.k8s.io” API Group实现授权决策,允许管理员通过Kubernetes API动态配置策略. 也就是说 每个k8s用户调用k8s的api时,都会经过一层角色的权限校验,比如 我当前的用户或者 服务账户(serviceaccount)关联的是哪一个角色,就拥有这一个角色的访问权限.

K8S 1.24.0 安装部署

- - Share
在 v1.2x 版本中, Kubernetes 支持的最大节点数为 5000. 更具体地说,我们支持满足以下所有条件的配置:. 每个节点的 pod 数量不超过. Kubernetes v1.20 开始,默认移除 docker 的依赖,如果宿主机上安装了 docker 和 containerd,将优先使用 docker 作为容器运行引擎,如果宿主机上未安装 docker 只安装了 containerd,将使用 containerd 作为容器运行引擎;.

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

- 意大利种马 - Solidot

k8s docker集群搭建 - CSDN博客

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

深入掌握K8S Pod - Yabea - 博客园

- -
K8S configmap介绍. Pod是k8s中最小的调度单元,包含了一个“根容器”和其它用户业务容器. 如果你使用过k8s的话,当然会了解pod的基本使用,但是为了更好的应用,你需要深入了解pod的配置、调度、升级和扩缩容等. pod包含一个或多个相对紧密耦合的容器,处于同一个pod中的容器共享同样的存储空间、IP地址和Port端口.