Hi，大家好，我是 CloudDeveloper，欢迎大家和我一起学习 K8S，这是系列第 8 篇。
K8s定义了一个网络模型，目的是给Pod，service等使用者提供一个简单、一致的网络视图和使用体验，对它们屏蔽宿主机环境的网络拓扑的同时，也屏蔽网络模型实现上的细节。
容器不是模拟一个完整的操作系统，而是对进程进行隔离，对容器里的进程来说它接触到的各种资源都是独享的，比虚拟机启动快、占用资源少。
k8s开源社区的插件太多了，支持插件的的，很早以前docker是不支持网络插件的，k8s的网络插件可以更方便的打通容器和节点。
在k8s中，我们的应用会以pod的形式被调度到各个node节点上，在设计集群如何处理容器之间的网络时是一个不小的挑战，今天我们会从pod（应用）通信来展开关于k8s网络的讨论。
我们在日常工作中，能遇见的情况只有下面三种，k8s集群内部之间的相互连接，k8s集群内部访问k8s集群外部的服务，还有就是k8s集群外部服务访问k8s集群内部的访问。下面我们来讲解下他们都是如何实现的，我们将使用分步的方式来讲解
在做好架构部署，并确认Tungsten Fabric和Kubernetes（K8s）集群的初始状态没有问题后，就可以开始尝试创建虚拟网络了。
Kubernetes 网络使您能够在 k8s 网络内配置通信。它基于扁平网络结构，无需在主机和容器之间映射端口。 Kubernetes 网络支持容器化组件之间的通信。这种网络模型的主要优点是不需要在主机和容器之间映射端口。然而，配置 Kubernetes 网络模型并不是一件容易的事。在本文中，您将了解什么是 Kubernetes 网络，探索常见的实现，并发现关键的 Kubernetes 网络变化。 什么是 Kubernetes 网络？ Kubernetes (k8s) 是一个开源容器编排平台。您可以使用
背景 随着容器、微服务、持续交付等云原生技术普及，大量应用基于K8s容器编排构建。相比传统网络模式，在云原生场景下，存在大量微服务模块间网络调用，集群内东西向通信流量激增，网络边界变得更加模糊。 容器环境中，容器IP和端口变换频繁，应用混合部署带来的通信关系复杂，传统基于静态IP和端口的边界安全规则已无法适用容器环境下细粒度的访问控制要求。默认情况下，K8s集群中不对Pod进行任何请求限制，任意Pod之间可以自由通信。正因此，在面对网络攻击时，没有安全规则的容器网络将给攻击者更多的自由和渗透空间。 如何实施
在Docker容器技术中，通过容器，我们可以很方便的将我们的应用程序打成一个镜像，然后无论我们在哪部署应用，只要这个环境支持Docker，那么我们都可以通过Docker将我们的镜像运行起来，而不需要关心环境的问题。这一点真正做到了 "一次打包，到处运行" 的效果。正是因为有了容器技术，我们可以不再理会应用的运行环境依赖问题，这也给微服务架构的实现带来了极大的便利。
到了k8s的文章了, 博主前面介绍了swarm集群, swarm集群本身相对来说比较简单、 轻量, 所以并没有重点介绍, 但是k8s不太一样, 这玩意还是比较复杂, 一两篇简单介绍不完, 所以博主这边得细说几篇, 最后也会做个实例, 方便大家参考。
BorgMaster:负责请求分发,整个集群的大脑 BorgLet:真正运行的节点,提供计算 sheduler:调度器,将数据写入到Paxos(键值对数据库)BorgLet监听Paxos数据库,如果发现有自己的请求则处理相应的任务
k8s网络模型设计基础原则:每个Pod都拥有一个独立的 IP地址，而且 假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中 。 所以不管它们是否运行在同 一 个 Node (宿主机)中，都要求它们可以直接通过对方的 IP 进行访问。设计这个原则的原因 是，用户不需要额外考虑如何建立 Pod 之间的连接，也不需要考虑将容器端口映射到主机端口等问题。
Docker 虽好用，但面对强大的集群，成千上万的容器，突然感觉不香了。这时候就需要我们的主角 Kubernetes 上场了，先来了解一下 Kubernetes 的基本概念，后面再介绍实践，由浅入深步步为营。 关于 Kubernetes 的基本概念我们将会围绕如下七点展开： 一、Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现，是存在困难的编排、管理和调度问题。于是，我们迫切需要一套管理系统，对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生！Kubernetes，名词源于希腊语，意为「舵手」或「飞行员」。Google 在 2014 年开源了 Kubernetes 项目，建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上，结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写，用 8 替代了 「ubernete」，下文我们将使用简称。 二、什么是 K8s？
距离上次更新已经有一个月了，主要是最近工作上的变动有点频繁，现在才暂时稳定下来。这篇博客的本意是带大家从零开始搭建K8S集群的。但是我后面一想，如果是我看了这篇文章，会收获什么？就是跟着步骤一步一走吗？是我的话我会选择拒绝，所以我加了关于K8S的简单介绍，每一步的步骤都添加了解释。由于篇幅和时间原因，我只介绍了K8S中较为核心的Pod和Service。
打开这篇文章的同学，想必对 docker 都不会陌生。docker 是一种虚拟容器技术，它上手比较简单，只需在宿主机上起一个 docker engine，然后就能愉快的玩耍了，如：拉镜像、起容器、挂载数据、映射端口等等。
K8S目前是业界容器编排领域的事实标准，是几乎所有云原生架构的首选。目前随着云原生架构越来越流行，测试开发人员需要掌握K8S技术栈已经成为越来越迫切的需求。
阿里云K8S集群网络目前有两种方案，一种是flannel方案，另外一种是基于calico和弹性网卡eni的terway方案。Terway和flannel类似，不同的地方在于，terway支持Pod弹性网卡，以及NetworkPolicy功能。
k8s 也是逐步发展过来的，来看看以前和现在支持的 node 数 和 pod 数对比
如果你使用过k8s的话，当然会了解pod的基本使用，但是为了更好的应用，你需要深入了解pod的配置、调度、升级和扩缩容等。本文将会更进一步的介绍pod。
最近在挺哥的指导下学习 Kubernetes，会定期写一些学习总结和大家分享，本篇文章是第一篇，从介绍 k8s 知识点和常见名词开始。
区块链技术被视为一项颠覆性的软件技术，正酝酿着新一轮的技术和产业变革, 作为信息技术的新基建，我们希望能够快速地把它搬到任何需要它的地方，那如何做到呢？我们知道搭建一个软件应用系统核心需要解决问题就是部署，自然而然，我们很容易联想起容器技术，作为软件部署的一套通用解决方案，容器技术应用在区块链领域中也是顺理成章的。
docker技术依赖于linux内核虚拟化技术的发展，对linux内核特性有很强依赖。docker用到的linux技术包括：
Dubbo 在 2011 开源之后，一直是国内最受欢迎的 RPC 框架，之后 Spring Boot 和 Spring Cloud 的面世，助推了微服务的火热程度。计算机的世界变化很快，自从容器和 K8s 登上舞台之后，给原有的 RPC 领域带来了很大的挑战。这个文章主要讲述 RPC 领域遇到的问题，以及 RPC 怎么去拥抱 K8s 怀抱的一些思考。
云原生（Cloud Native），有利于在公有云、私有云和混合云等动态环境中，构建和运行可弹性扩展的应用。云原生包括容器、服务网格、微服务、不可变基础设施和声明式API。 docker swarm的功能，k8s的编排，mesos的调度管理。
Docker 是新时代虚拟化，云原生的基础, 尽管有多种容器化的方案，但是 Docker 目前是事实标准
K8S的集群运行依赖Master节点和Node节点的通信，为了更好的理解第4部分的Pod生命周期，我们这里先给出K8S Master的简单架构图，后续的文章中，我们会分析Master、Node和Pod之间的关系。
本文主要理解的一个核心点，什么是Pod？我们先不关注Pod怎么使用，怎么调度，如何实现最佳实践。这些问题后续继续讨论，在不懂为什么k8s要有Pod的情况下，去先深究最佳实践没有实际意义。
礼记《学者有四失》里说“人之学也，或失则多”，这是给我提醒每篇推文最好只聊一个概念。前一篇文章着重介绍了一下Cilium的各种炫酷的花式玩法，今天我们来看一个最最基本的功能：IPAM（IP Address Management）。
一个目标：容器操作；两地三中心；四层服务发现；五种Pod共享资源；六个CNI常用插件；七层负载均衡；八种隔离维度；九个网络模型原则；十类IP地址；百级产品线；千级物理机；万级容器；相如无亿，K8s有亿：亿级日服务人次。
在云原生领域，Kubernetes (K8s) 已经成为容器编排的事实标准☁️📦。为了支撑其灵活的服务发现和负载均衡🔍🔄，K8s采用了大二层网络的设计理念🕸️。本文将深入探讨大二层网络的工作原理、带来的好处✨，以及面临的挑战和解决方案❗🛠️。
我们在本系列的第一期就提到过，孙猴子的两个重要技能是召唤分身和筋斗云。虚拟化技术的起源也借鉴了这一思想，用户可以基于虚拟机镜像快速批量启动虚拟机，以及虚拟机迁移，来实现虚拟机的便捷调度。
只需要复制多份pod的副本即可，这也是k8s管理的先进之处，k8s如果进行扩容或者缩容，只需控制pod的数量即可。
最近遇到一个docker compose部署的产品（旧版本）想部署到k8s中，而该产品应用的多个容器都在docker compose中设置了ip地址，镜像里的应用配置也是配置的这些预设ip，容器之间通过预设IP进行通信。
k8s进行管理应用的时候，基本步骤是：创建集群，部署应用，发布应用，扩展应用，更新应用。
| 导语 前面介绍了很多K8S的概念以及架构方面的东西，这里我们说说K8S的网络。云计算里面的网络向来是复杂的，因为里面牵扯到硬件网络跟虚拟网络的交互。尤其是虚拟网络，比较抽象，如果不搞清楚，一些问题排障将寸步难行。
之前的文章中，我们对k8s能够解决的问题做了简单介绍，简单来说，它解决的问题是容器的编排与调度，它的核心价值在于：运行在大规模集群的任务之间，实际上存在着各种各样的关系，这些关系的处理，才是任务编排和系统管理最困难的地方，k8s就是为了这个问题而生的。
在容器环境中，K8S管理着拥有数个、数百个甚至数千个节点的容器集群，其配置的重要性不可忽略。K8S的配置选项很复杂，一些安全功能并非默认开启，这加大了安全管理难度。如何有效地使用包括Pod安全策略、网络策略、API服务器、Kubelet及其他K8S组件和功能策略建立安全的K8S环境？整理了以下12个最佳实践，对K8S进行全面加固。
他开始自学Vue3并使用SpringBoot3完成了一个前后端分离的Web应用系统，并打算将其用Docker容器化后用K8s上云。
kubernetes（简称k8s）是一种用于在一组主机上运行和协同容器化应用程序的管理平台，皆在提供高可用、高扩展性和可预测性的方式来管理容器应用的生命周期。通过k8s，用户可以定义程序运行方式、部署升级策略、动态伸缩容，使得用户以一种更灵活可靠的方式来管理应用程序。
Master节点是Kubernetes集群的控制节点，每个Kubernetes集群里至少有一个Master节点，它负责整个集群的决策（如调度），发现和响应集群的事件。一个集群通常运行多个Master控制节点，提供容错性和高可用性。Master节点可以运行在集群中的任意一个节点上，但是最好将Master节点作为一个独立节点，不在该节点上创建容器，因为如果该节点出现问题导致宕机或不可用，整个集群的管理就会失效。
kubernetes github：https://github.com/kubernetes/kubernetes
4.2、Internet-To-Pod（LoadBalancer -- Layer4）
任何技术的诞生，都会经历从架构设计到开发测试的过程，好的技术，往往也会有一套好的架构。架构是个好东西，它能帮助我们站在高处看清楚事物的整体结构，避免过早地进入细节而迷失方向。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
