近期工作中出现了一个问题：某个旧服务中用到了redis，但是在前期项目容器化改造部署阶段研发同事并没有说明需要用到redis，直至部署生产prod环境出现问题。 那么疑问来了，为什么在qa环境没有问题呢？经沟通排查发现，源码中也就是qa环境连接的是一个古老的虚拟机运行的redis，所以自然研发测试环境都没问题，至于为什么会连接到这个地址，不得而知！
Kubectl：客户端命令行工具，作为整个系统的操作入口。 kube-apiserver：以REST API服务形式提供接口，作为整个系统的控制入口。 kube-controller-manager：控制器管理器，用来检测控制器健康状态，检查pod的健康状态，比如故障检测，自动扩展，滚动更新，包括节点状态状况、Pod个数、Pods和Service的关联等。 kube-scheduler：负责节点资源管理，接收来自kube-apiserver创建Pods任务，并分配到某个节点。 etcd：是一个key/value形式的键值存储，保存整个k8s集群状态，在k8s中使用etcd时，需要对etcd做备份，保证高可用，整个k8s系统中一共有两个服务需要 用到etcd用来协同和存储配置 分别是： 1.网络插件calico,对于其他网络插件也需要用到etcd存储网络的配置信息 2.k8s本身，包括各种对象的状态和元信息配置 注意：网络插件操作etcd使用的是v2的API，而k8s操作etcd使用的v3的API，所以在下面我们执行etcdctl的时候需要设置ETCDCTL_API环境变量，该变量默认值为2，表示使用v2版本的etcd api，v3表示使用v3的版本etcd api kube-proxy：运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。 Kubelet：运行在每个计算节点上，作为agent，接收分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。 Fluentd：主要负责日志收集、存储与查询。 Calico：是一个纯三层的网络插件，calico的bgp模式类似flannel的host-gw，calico在kubernetes中可提供网络功能和网络策略 三种网络模式： Flannel 常见采取 UDP Overlay 方案，VxLAN 性能比 TUN 强一点，一个是内核态一个是用户态 Calico 是一个纯三层的方案，不需要 Overlay，基于 Etcd 维护网络准确性，也基于 Iptables 增加了策略配置 Cilium 就厉害了，基于 eBPF 和 XDP 的方案，eBPF/XDP 处理数据包的速度可以和 DPDK 媲美，零拷贝直接内核态处理，缺点就是用户不太容易进行配置，而 cilium 解决了这个问题，毕竟 yaml 开发工程师都会写 yaml。。。可以支持 L3/L4/L7 的策略 Coredns：k8s1.11之前使用的是kube dns，1.11之后才有coredns是一个DNS服务器，能够为kubernetes services提供DNS记录
Service 是 k8s 网络部分的核心概念，在 k8s 中，Service 主要担任了四层负载均衡的职责。本文从负载均衡、外网访问、DNS 服务的搭建及 Ingress 七层路由机制等方面，讲解 k8s 的网络相关原理。
k8s的文章一共写了十八篇，是一个比较全面的学习日志。从八月二十九开始发的第一篇文章，到现在十二月份了，从看《Kubernetes权威指南 第4版》开始，总共耗时接近四个月。
Admission Webhook Admission Webhook 是 api-server 对外提供的一个扩展能力，api-server 作为 kub
本文为3月26日灵雀云Kubernetes专家刘梦馨在Dockone社区的主题分享。他从Kubernetes网络的局限性、OVS和OVN网络方案的能力、OVN和Kubernetes的结合、Kubernetes网络增强的未来方向等方面分享了他本人的思考，以及灵雀云在此方面的产品进展。灵雀云近期研发的基于OVN的Kubernetes网络将很快与大家见面。欢迎各位关注！
基于3月26号，在 Dockone 社区的分享整理的内容，效果还不错，最后的QA环节问题超级多，据说是之前最多一次的两倍。这次只是基本概念的介绍，具体我们的架构实现以及开源的信息会之后放出来。
kubernetes（简称k8s）是一种用于在一组主机上运行和协同容器化应用程序的管理平台，皆在提供高可用、高扩展性和可预测性的方式来管理容器应用的生命周期。通过k8s，用户可以定义程序运行方式、部署升级策略、动态伸缩容，使得用户以一种更灵活可靠的方式来管理应用程序。
PS：（梳理概念）pod里面包括N个容器，service里面包括pod，Deployment可能包括service或者是pod。
【注：下载本文PDF版本以及本文源代码，可关注本公众号：亨利笔记，后台发送消息“区块链即服务” 或 “baas”即可。】
本文基于 kubernetes v1.19 文档，并主要关注 2019 年 以及之后（v1.14-v1.19）出现或者变化状态(比如 alpha -> beta)的特性 容器与工作负载 容器引擎 cri-containerd 已经成熟，在主流的云厂商新建 k8s 集群时大都(如google clout、腾讯云、阿里云)提供了基于 containerd 的创建选项 (另一个选项为 docker)。关于 docker 和 containterd 的关系和区别可以参考这篇文章 docker 推荐安装 19.03.
我们都知道，在K8S集群中，每个Pod都有自己的私有IP地址，并且这些IP地址不是固定的。这意味着其不依赖IP地址而存在。例如，当我们因某种业务需求，需要对容器进行更新操作，则容器很有可能在随后的启动运行过程中被分配到其他IP地址。此外，在K8S集群外部看不到该Pod。因此，Pod若单独运行于K8S体系中，在实际的业务场景中是不现实的，故我们需要通过其他的策略去解决，那么解决方案是什么？ 由此，我们引入了Serivce这个概念以解决上述问题。
一个目标：容器操作；两地三中心；四层服务发现；五种Pod共享资源；六个CNI常用插件；七层负载均衡；八种隔离维度；九个网络模型原则；十类IP地址；百级产品线；千级物理机；万级容器；相如无亿，K8s有亿：亿级日服务人次。
新的一年还是要学习一些新技术的，先从k8s开始吧。 作为一个想成为“微服务技术专家”，除了上层类spring cloud的解决方案，服务治理方案之外，k8s作为底层基础设施，所承担的自动扩缩容，devops等功能也是微服务架构中很重要的一环。
安全策略可以通过限制端口、网络协议等方式控制任意pod之间的访问，以及pod与service之间的访问。在K8s集群中安全策略对应的是Network Policy，在Tungsten Fabric中安全策略对应的Firewall Rule，两者是会实时同步的。
k8s为每个pod分配了唯一的IP地址，一个pod里的多个容器共享pod IP。 pod其实有两种类型：普通的pod和静态pod，后者比较特殊，它并不存放在etcd存储中，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行。而普通的pod一旦被创建，就会被放入etcd中存储。随后被master调度到某个具体的Node上并进行绑定，随后该pod被对应的Node上的kubelet进程实例化成一组相关的docker容器并启动起来。 每个pod都可以对其使用的服务器上的计算资源设置限额，当前可以设置限额的源有CPU和memory两种。其中CPU的资源单位为CPU的数量。 一般而言，一个CPU的配额已经算是相当大的一个资源配额，所以在k8s中，通常以千分之一的CPU配额为最小单位，以m来表示，通常一个容器的CPU配额为100-300m，即占用0.1-0.3个CPU。这个配额是个绝对值，不是占比。 在k8s中，一个计算资源进行配额限定需要设定两个参数： requests，资源的最小申请量，系统必须满足要求 limits，资源最大允许使用的量。
Kubernetes Pod 是有生命周期的，它们可以被创建，也可以被销毁，然而一旦被销毁生命就永远结束。 通过 ReplicationController 能够动态地创建和销毁 Pod（例如，需要进行扩缩容，或者执行）。 每个 滚动升级 Pod 都会获取它自己的 IP 地址，即使这些 IP 地址不总是稳定可依赖的。 这会导致一个问题：在 Kubernetes 集群中，如果一组 Pod（称为 backend）为其它 Pod （称为 frontend）提供服务，那么那些 frontend 该如何发现，并连接到这组 Pod 中的哪些 backend 呢？
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
在做好架构部署，并确认Tungsten Fabric和Kubernetes（K8s）集群的初始状态没有问题后，就可以开始尝试创建虚拟网络了。
在上一篇文章里我们主要介绍worker组件kube-proxy的安装，这里我们开始介绍安装k8s集群内的一些基础服务，所有的基础服务都创建在kube-system这个namesapce里，我们从coredns开始。coredns提供k8s集群内部service的fqdn服务，是以deployment的方式运行在k8s集群内部的。image镜像从我们的private repo pull下来(以前文章里介绍过harbor private repo的创建，以及镜像的push和pull)。当然原始image来源于官方的k8s.gcr.io/coredns:1.3.1，不过要下载它需要科学上网或者搭个梯子。
在k8s中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。
前言 本文仅代表作者魏新宇的个人观点；在书写过程中，笔者与同事郭跃军进行了技术讨论，大有裨益，在此表示感谢！ 一、K8S vs OCP, 网络端口访问方式 我在上一篇文章《深度理解：Openshif
今天我们进入 Cilium 安全相关主题, 介绍 CiliumNetworkPolicies 相比于 Kubernetes 网络策略最大的不同: 7 层网络策略能力.
本篇文章来自《华为云云原生王者之路训练营》黄金系列课程第3课，由华为云容器批量计算首席架构师马达主讲，介绍云原生技术体系中Kubernetes的相关概念和技术架构。
1.大规模 IoT 边缘容器集群管理的几种架构-0-边缘容器及架构简介[1]2.大规模 IoT 边缘容器集群管理的几种架构-1-Rancher+K3s[2]3.大规模 IoT 边缘容器集群管理的几种架构-2-HashiCorp 解决方案 Nomad[3]4.大规模 IoT 边缘容器集群管理的几种架构-3-Portainer[4]5.大规模 IoT 边缘容器集群管理的几种架构-4-Kubeedge[5]6.大规模 IoT 边缘容器集群管理的几种架构-5-总结[6]
服务发现是 K8s 的一项很重要的功能。K8s 的服务发现有两种方式，一种是将 svc 的 ClusterIP 以环境变量的方式注入到 pod 中；一种就是 DNS，从 1.13 版本开始，coreDNS 就取代了 kube dns 成为了内置的 DNS 服务器。这篇文章就来简单分析一下 coreDNS。
kubernetes —— 工业级的容器编排平台，简称K8S（“k-s之间有8个字母），因为有了这个编排工具之后，不仅在给运维大大提升了运维的效率，也给应用稳定性提供了有力的保障。解决了出现容器时 、容器 网络 及运维管理成本。
大家都知道历史上有段佳话叫“司马相如和卓文君”。“皑如山上雪，皎若云间月”。卓文君这么美，却也抵不过多情女儿薄情郎。 司马相如因一首《子虚赋》得汉武帝赏识，飞黄腾达之后便要与卓文君“故来相决绝”，寄来给家乡留守的妻子一封《两地书》，上面只有一行数字：“一二三四五六七八九十百千万。”意义是：无亿，我已经无意于你啦。 卓文君看了这封信也不示弱，回了一首《怨郎诗》，司马相如看了发现虽然我是靠写诗吃饭的。要说写诗还是我媳妇厉害，于是亲自将卓文君迎回长安。 卓文君其实是个二婚。头婚的丈夫结婚不久就死了
OpenShift的OVS网络组件有三种模式：ovs-subnet、ovs-multitenant、ovs-networkpolicy。
在短短两年的时间里，Kubernetes在集装箱管道战场上给其竞争对手带来了浪费。令人遗憾的是，Docker Swarm自2016年以来并未成为主要的竞争者，并且像AWS一样，承诺通过承诺K8的支持和整合而失败。
https://blog.csdn.net/hguisu/category_9999400.html
大家都知道历史上有段佳话叫“司马相如和卓文君”。“皑如山上雪，皎若云间月”。卓文君这么美，却也抵不过多情女儿薄情郎。
https://github.com/kubernetes/heapster/tree/master/deploy
虽然 Docker 已经很强大了，但是在实际使用上还是有诸多不便，比如集群管理、资源调度、文件管理等等。那么在这样一个百花齐放的容器时代涌现出了很多解决方案，比如 Mesos、Swarm、Kubernetes 等等，其中谷歌开源的 Kubernetes 是作为老大哥的存在。
自从7月份发布Kubernetes 1.3以来，用户已经能够在其集群中定义和实施网络策略。这些策略是防火墙规则，用于指定允许流入和流出的数据类型。如果需要，Kubernetes可以阻止所有未明确允许的流量。本文针对K8s的网络策略进行介绍并对网络性能进行测试。 网络策略 K8s的网络策略应用于通过常用标签标识的pod组。然后，可以使用标签来模拟传统的分段网络，这些网络通常用于在多层应用程序中隔离层：例如，您可以通过特定的“段”标签来标识前端和后端pod。策略控制这些段之间的流量，甚至控制来自外部源的流量。
虽然 Docker 已经很强大了，但是在实际使用上还是有诸多不便，比如集群管理、资源调度、文件管理等等。那么在这样一个百花齐放的容器时代涌现出了很多解决方案，比如 Mesos、Swarm、Kubernetes 等等，其中谷歌开源的 Kubernetes 是作为老大哥的存在。也可参考：k8s 和 Docker 关系简单说明
在平台工程理念中，平台，也被称为内部开发者平台（Internal Developer Platform，简称IDP），是一种基础设施，使开发团队能够更快、更轻松、更一致地交付应用程序。Kubernetes本身是一个强大的平台，但是将其作为IDP交给开发团队，并期望他们都能成功，会引入过多的复杂性和太多的功能。因此，非常重要的是建立一些防护措施，使他们能够有效地使用K8s，同时不增加与可靠性、成本效率和安全性相关的风险。
导读：近两年，DevOps的概念一直非常火爆，但是在具体的落地上，CI/CD的实施一直缺乏非常好的案例。本文根据蓝鲸容器服务负责人陈睿所做的《蓝鲸DevOps方案在游戏中的实现》主题演讲内容整理而成，希望能给大家以借鉴与启发。
Kubernetes 为 Service 和 Pod 创建 DNS 记录。 你可以使用一致的 DNS 名称而非 IP 地址访问 Service。
对外暴露了Kubernetes API。它是的 Kubernetes 核心控制层。它被设计为水平扩展，即通过部署更多实例来横向扩展。API Server 负责和 etcd 交互（其他组件不会直接操作 etcd，只有 API Server 这么做），是整个 kubernetes 集群的数据中心，所有的交互都是以 API Server 为核心的。API Server 提供了以下的功能：
k8s单机版，主要目的是快速部署，供我们试验和学习k8s之用。 时间匆忙,没什么技巧,一键部署.1.18.3 Kubernetes主要由以下几个核心组件组成： etcd保存了整个集群的状态； apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制； controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等； scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上； kubelet负责维护容器的生命周期，同时也负
K8S是第一个将“一切以服务为中心，一切围绕服务运转”作为指导思想的创新型产品，它的功能和架构设计自始至终都遵循了这一指导思想，构建在K8S上的系统不仅可以独立运行在物理机、虚拟机集群或者企业私有云上，也可以被托管在公有云中。
Kubernetes 也称为 K8s，是用于自动部署、扩缩和管理容器化应用程序的开源系统。Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。
在混合多云的世界里，Kubernetes是如此流行，已经成为应用统一部署和管理的事实标准，而Tungsten Fabric与Kubernetes的集成，更增强了后者的网络性能和安全性，帮助实现业务落地。
一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件，依然先放上经典的K8S架构图：
Kubernetes 最初源于谷歌内部的 Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理/虚拟计算、网络和存储等基础设施资源的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
在本教程中，你将学习如何一起运行Linkerd和Cilium，以及如何使用Cilium将L3和L4网络策略应用到运行Linkerd的集群。
作者 | 刘燕，核子可乐 我们成功了，找到了一条适合自己的迁移道路”。 1 37signals 的“去云”和“去 K8s”行动 根据 37signals 公布的一组数据显示，2022 年，37signals 在所有 AWS 云服务上总共花费了 3,201,564 美元，这相当于每月 266,797 美元。 这一巨额支出令 37signals 决定，通过“去云”的方式大幅削减费用。 2022 年 10 月，37signals 公司首席技术官兼 Ruby On Rails 之父 David Heine
领取专属 10元无门槛券
手把手带您无忧上云
