前言当我们在Kubernetes部署的服务需要暴露给外部用户使用时，有三种选择：LoadBalancer，NodePort，Ingress。LoadBalancer类型得结合各个CloudProvider提供的LB来使用，如果需要暴露的service很多，需要很多LB以及公网IP，比较浪费cost。NodePort 方式一个端口只能一个服务使用，根据端口划分服务，可用端口范围：30000~32767，同样如果在暴露的servicie很多的情况下会导致节点要开的端口越来越多，不好管理，平时测试可以用用。Ingress是自kubernetes1.1版本后引入的资源类型，在这个资源中我们可以去配置我
前言当我们在Kubernetes部署的服务需要暴露给外部用户使用时，有三种选择：LoadBalancer，NodePort，Ingress。LoadBalancer类型得结合各个CloudProvider提供的LB来使用，如果需要暴露的service很多，需要很多LB以及公网IP，比较浪费cost。NodePort 方式一个端口只能一个服务使用，根据端口划分服务，可用端口范围：30000~32767，同样如果在暴露的servicie很多的情况下会导致节点要开的端口越来越多，不好管理，平时测试可以用用。Ingress是自kubernetes1.1版本后引入的资源类型，在这个资源中我们可以去配置我
作者：KaliArch（薛磊），某CloudMSP服务商产品负责人，熟悉企业级高可用/高并发架构，包括混合云架构、异地灾备，熟练企业DevOps改造优化，熟悉Shell/Python/Go等开发语言，熟悉Kubernetes、Docker、云原生、微服务架构等。背景在业务使用Kubernetes进行编排管理时，针对业务的南北流量的接入，在Kuberentes中通常有几种方案，本文就接入的方案进行简单介绍。流量接入方案Kuberentes社区通过为集群增设入口点的方案，解决对外流量的管理。通过kube-proxy进行代理通常在最简单的测试或个人开发环境，可以通过kubectlport-forwa
作者：KaliArch（薛磊），某CloudMSP服务商产品负责人，熟悉企业级高可用/高并发架构，包括混合云架构、异地灾备，熟练企业DevOps改造优化，熟悉Shell/Python/Go等开发语言，熟悉Kubernetes、Docker、云原生、微服务架构等。背景在业务使用Kubernetes进行编排管理时，针对业务的南北流量的接入，在Kuberentes中通常有几种方案，本文就接入的方案进行简单介绍。流量接入方案Kuberentes社区通过为集群增设入口点的方案，解决对外流量的管理。通过kube-proxy进行代理通常在最简单的测试或个人开发环境，可以通过kubectlport-forwa
作者：scwang18，主要负责技术架构，在容器云方向颇有研究。前言KubeSphere是青云开源的基于Kubernetes的云原生分布式操作系统，提供了比较炫酷的Kubernetes集群管理界面，我们团队用KubeSphere来作为开发平台。本文记录了一次KubeSphere环境下的网络故障的解决过程。现象开发同学反馈自己搭建的Harbor仓库总是出问题，偶尔会报net/http:TLShandshaketimeout，通过curl的方式访问harbor.xxxx.cn，也会随机频繁挂起。但是ping的反馈一切正常。原因分析接到错误报障后，经过了多轮分析，才最终定位到原因，应该是安装Kube
作者：scwang18，主要负责技术架构，在容器云方向颇有研究。前言KubeSphere是青云开源的基于Kubernetes的云原生分布式操作系统，提供了比较炫酷的Kubernetes集群管理界面，我们团队用KubeSphere来作为开发平台。本文记录了一次KubeSphere环境下的网络故障的解决过程。现象开发同学反馈自己搭建的Harbor仓库总是出问题，偶尔会报net/http:TLShandshaketimeout，通过curl的方式访问harbor.xxxx.cn，也会随机频繁挂起。但是ping的反馈一切正常。原因分析接到错误报障后，经过了多轮分析，才最终定位到原因，应该是安装Kube
现今有越来越多的企业开始采纳云原生理念进行应用架构转型。而K8s和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。 对多数应用而言，提供对外服务的使命并不会改变，相比于原来的单体应用，微服务架构下的应用的服务出口更多，管理更繁琐，微服务网关也应运而生；而K8s也提供了多种方式来暴露应用的服务，各种Ingress实现百花齐放。面对众多技术方案，我们如何做出合理的选择，规避潜在风险，本文将给出一些选型建议，供大家参考。 云原生网关基本概述 K8s中服务对外访问的方式 对于部署在云服务器上的应用，通常使用负载均衡软件或服务（如SLB）来提供高可用的服务。K8s提供了基于Service的服务发现
现今有越来越多的企业开始采纳云原生理念进行应用架构转型。而K8s和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。 对多数应用而言，提供对外服务的使命并不会改变，相比于原来的单体应用，微服务架构下的应用的服务出口更多，管理更繁琐，微服务网关也应运而生；而K8s也提供了多种方式来暴露应用的服务，各种Ingress实现百花齐放。面对众多技术方案，我们如何做出合理的选择，规避潜在风险，本文将给出一些选型建议，供大家参考。 云原生网关基本概述 K8s中服务对外访问的方式 对于部署在云服务器上的应用，通常使用负载均衡软件或服务（如SLB）来提供高可用的服务。K8s提供了基于Service的服务发现
1.为什么需要Ingress我们使用传统的NodePort类型的Service的确能将集群内的服务暴露给集群外部客户端去访问，但是使用这种类型的Service存在以下问题。一个端口只能使用一个服务，所有通过NodePort暴露的端口都需要提前规划；如果集群上的Service的数量太多的话，暴露的NodePort端口不具有连续性。后期维护成本太大，且不宜于管理；无论是Iptables或者是Ipvs模型的Service都配置在Linux内核中的Netfilter之上进行四层调度。是一种比较通用的调度器。支持调度HTTP、Mysql等应用层服务，不过，也正是工作于传输层从而使得它无法做到类似卸载HT
1.为什么需要Ingress我们使用传统的NodePort类型的Service的确能将集群内的服务暴露给集群外部客户端去访问，但是使用这种类型的Service存在以下问题。一个端口只能使用一个服务，所有通过NodePort暴露的端口都需要提前规划；如果集群上的Service的数量太多的话，暴露的NodePort端口不具有连续性。后期维护成本太大，且不宜于管理；无论是Iptables或者是Ipvs模型的Service都配置在Linux内核中的Netfilter之上进行四层调度。是一种比较通用的调度器。支持调度HTTP、Mysql等应用层服务，不过，也正是工作于传输层从而使得它无法做到类似卸载HT
