在谷歌发明 Kubernetes 后的几年中，它彻底改变了 IT 运维的方式，并逐渐成为了事实标准，可以帮助组织寻求高级容器编排。那些需要为其应用程序提供 最高级别可靠性、安全性和可扩展性 的组织选择了谷歌 Kubernetes 引擎（Google Kubernetes Engine, GKE）。光是 2020 年二季度，就有 10 多万家公司使用谷歌的应用现代化平台和服务（包括 GKE）来开发和运行他们的应用。到目前为止， Kubernetes 还需要手工装配和修补程序来优化它才能满足用户需求。如今，谷歌推出了 GKE Autopilot，这是一个管理 Kubernetes 的革命性运营模式，让用户专注于软件开发，而 GKE Autopilot 则负责基础架构。
毛艳清，富士康工业互联网科技服务事业群运维中心主管，现负责公有云和私有云的运维工作，聚焦在云计算和云原生领域，主要关注企业迁云的策略与业务价值、云计算解决方案、云计算实施与运维管理，以及云原生技术的布道和落地实践。
Kubernetes 真正的超级功能之一是其开发者优先的网络模式，它提供了易于使用的功能，如 L3/L4 服务和 L7 入口，将流量引入集群，以及用于隔离多租户工作负载的网络策略。随着越来越多的企业采用 Kubernetes，围绕多云、安全、可视性和可扩展性的新要求，用例的范围也在扩大。此外，服务网格和 serverless 等新技术对 Kubernetes 底层的定制化提出了更多要求。这些新需求都有一些共同点：它们需要一个更加可编程的数据平面，能够在不牺牲性能的情况下执行 Kubernetes 感知的数据包操作。
客座撰稿人：Karen Bruner，StackRox技术专员。原文可以在这里找到。
数字化时代下，企业的发展与数据库的建设息息相关。如果搭建云下数据库，不仅要通过大量的运维投入保证数据库稳定运行，随着企业规模与数据量的发展，还要应对数据库扩容、弹性、运维、备份等各种各样的问题，云下数据库对企业提出的要求日益增长。此时有两种应对之法，一是凭借扩充技术团队解决问题，但这无疑将会带来不菲的运维与人员成本，二则是把一切交给云服务。
随着更多的组织开始拥抱云原生技术，Kubernetes已成为容器编排领域的行业标准。向 Kubernetes转变的这股潮流，很大程度上简化了容器化应用程序的部署、扩展和管理，并实现了自动化，为传统的单体式系统提供了胜于传统管理协议的众多优势。
Envoy/Istio 1.1 中有个有趣的新特性：负载均衡提供了区域感知的能力。简单说来，就是在分区部署的较大规模的集群，或者公有云上，Istio 负载均衡可以根据节点的区域标签，对调用目标做出就近选择。在跨区部署的应用中，原始的 Kubernetes 负载均衡可能会把来自 A 区的请求发送给远在 B 区的服务，造成高成本的跨区调用。要缩减这种损耗，通常都需要实现更多的逻辑，Istio 的区域感知特性在某种程度上提供了一种解决办法。
Prometheus 是为 Kubernetes 这样的动态环境而生的。它的服务发现能力和查询语言非常强大，Kubernetes 运维过程中，用户可以借 Prometheus 解决监控问题。
关注容器圈的朋友一定会注意到最近一年的高频词：Service Mesh。这么绕口的词，到底是什么意思？引用一篇文章里对其的解释：
互联网后台架构技术的发展一日千里。身处技术变革浪潮的后台同学，应该都深切地感受到了云原生技术在公司内外的蓬勃发展。云原生技术正在逐渐成为后台工程师与架构师们的必修课，而 kubernetes 正是云原生的基石，聚光灯下的焦点。
最近看到了一份收集Kubernetes故障案例的资料，资料由ZalandoTech的高级首席工程师Henning Jacobs加以维护。这个由社区驱动的项目全面介绍了Kubernetes反模式以及为何导致Kubernetes运行错误的原因。
我们将为搜索工程师介绍在Kubernetes（k8s）上运行Solr的基础知识。 具体来说，我们涵盖以下主题：
自Google Anthos推出以来在混合云领域受到极大关注，作为Google进入ToB混合云市场的战略级产品，Anthos集成了如GKE （Google Kubernetes Engine）、GKE On-Prem、Istio on GKE等……引起业界的关注。可以说这又是Google又一大利器。那么混合云作为企业数字化转型的重要基础设施建设，既留了核心数据，降低了迁移风险，又能在原来资源的基础上增加公共云的弹性，一举多得，成为当前云计算发展的热门话题。而作为数字化转型的另外一个风向标DevOps如何与当前的混合云发展进行协作，带向企业进入云原生时代，将会成日今后数字化建设的一个重要主题。
随着软件供应链攻击的增加，保护我们的软件供应链变得更加重要。此外，在过去几年中，容器的采用也有所增加。有鉴于此，对容器镜像进行签名以帮助防止供应链攻击的需求日益增长。此外，我们今天使用的大多数容器，即使我们在生产环境中使用它们，也容易受到供应链攻击。在传统的 CI/CD 工作流中，我们构建镜像并将其推入注册中心。供应链安全的一个重要部分是我们构建的镜像的完整性，这意味着我们必须确保我们构建的镜像没有被篡改，这意味着保证我们从注册中心中提取的镜像与我们将要部署到生产系统中的镜像相同。证明镜像没有被篡改的最简单和最好的方法之一（多亏了 Sigstore）是在构建之后立即签名，并在允许它们部署到生产系统之前验证它。这就是 Cosign 和 Kyverno 发挥作用的地方。
在 Kubernetes 集群边缘对外提供网络服务的时候，通常需要借助 Ingress 对象，这个对象提供了暴露 Service 所必须的核心要素，例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候，往往会有更多的具体需求，这时 Ingress 对象所提供的核心功能就有些力不从心了，各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解，来完成对 Ingress 特定行为的控制，完成各自的个性化功能，例如认证、路径变更、黑白名单等，这就让 Ingress 对象变成了一个奇怪的东西：结构化的核心结构，和非结构化的标注结合起来形成各种 Ingress 方言，并且后期还出现了 Traefik Middleware 这样的 CRD 配置，这给 Ingress 功能的集中管理造成了一个较大的困扰；另外 Ingress 中可以随意定制主机名、路径以及后端服务，也给共享集群的用户造成了一定的安全隐患。包括 Cotour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达，客观上也让 Ingress 世界更为分裂。 例如要移除路径前缀，Nginx Ingress 控制器需要使用 nginx.ingress.kubernetes.io/rewrite-target 注解，而 Traefik 1.7 中则需要使用 traefik.ingress.kubernetes.io/rule-type: PathPrefixStrip 注解。
容器技术所提供的解耦能力，让应用程序及其依赖程序不用再和操作系统耦合在一起。和处理虚拟机镜像方式不同，容器技术并不会将操作系统同应用程序打包在一起，这给我们节约了相当多的硬件资源，不管是cpu、内存，还是磁盘空间。同时，容器的下载，更新，部署和迭代的速度，也远比虚拟机镜像要快。因此，容器技术已经在技术圈中引起不小的变革。类似谷歌、微软和亚马逊这样子的公司都已经开始使用这项技术。
Kube-Bench是一款针对Kubernete的安全检测工具，从本质上来说，Kube-Bench是一个基于Go开发的应用程序，它可以帮助研究人员对部署的Kubernete进行安全检测，安全检测原则遵循CIS Kubernetes Benchmark。
Google 声明[2]将选择 Cilium[3] 作为 GKE 网络的数据面 V2 以便增加其容器安全性和可观测性。
KubeArmor是一个支持容器的运行时安全实施系统，它可以从系统级别限制容器的行为（如进程执行、文件访问、网络操作和资源利用率）。
渐进式交付是持续交付的下一步， 它将新版本部署到用户的一个子集，并在将其滚动到全部用户之前对其正确性和性能进行评估， 如果不匹配某些关键指标，则进行回滚。
Beam 是一个函数即服务平台，允许开发人员快速在云上运行他们的 AI 应用程序。用户主要在我们的平台上运行 AI 和数据工作负载，我们目前在我们的 Python SDK 中暴露了两种自动缩放策略。
上个月，Kubernetes（世界上最受欢迎的容器编排器）生态系统因发现Kubernetes的第一个主要安全漏洞而动摇。该漏洞（CVE-2018-1002105）使攻击者能够通过Kubernetes API服务器破坏集群，允许他们运行代码来安装恶意软件等恶意活动。
作者 | Nic Cope 译者 | 平川 在过去的几个月里，Crossplane 支持的自定义资源数量突破了 Kubernetes 的限制。在这篇文章中，我们将探讨下由 Upbound 工程师发现的限制，以及我们如何帮助克服它们。 本文最初发布于 Upbound Newsletter。 在过去的几个月里，Crossplane 支持的自定义资源数量突破了 Kubernetes 的限制。在这篇文章中，我们将探讨下由 Upbound 工程师发现的限制，以及我们如何帮助克服它们。 背 景 Upbound 创
docker毫无疑问是一个优秀的开源工具。但是，仅靠docker引擎和容器就不能进行复杂的应用程序部署。对于部署复杂的应用程序体系结构的容器群集，必须进行适当的配置。容器化的应用程序应该能够根据应用程序资源需求进行扩展和缩小。
最近，有人问我 NodePort，LoadBalancer 和 Ingress 之间的区别是什么。 它们是将外部流量引入群集的不同方式，并且实现方式不一样。 我们来看看它们是如何工作的，以及什么时候该用哪种。
使用的CNCF项目包括：Envoy、Fluentd、Helm、Kubernetes、Prometheus
metrics-server 是一个采集集群中指标的组件，类似于 cadvisor，在 v1.8 版本中引入，官方将其作为 heapster 的替代者，metric-server 属于 core metrics(核心指标)，提供 API metrics.k8s.io，仅可以查看 node、pod 当前 CPU/Memory/Storage 的资源使用情况，也支持通过 Metrics API 的形式获取，以此数据提供给 Dashboard、HPA、scheduler 等使用。
微信关注了很多的技术公众号，早上醒来看各位大佬分析的文章是个人的习惯。虽然忘了很多公众号是怎么关注的了......早上偶然看到一篇分享文章：当前 Kubernetes 发行版比较，忍不住想要吐槽一把。这写的是啥玩意？也好意思分享？
本文介绍了部署 Kubernetes 的三种主要方式：作为 Kubernetes-as-a-Service，使用公共云提供商，以及本地部署。作者还讨论了每种方法的优缺点，并提供了相关示例和部署指南。最后，文章介绍了 Kubernetes 的终极指南，包括沙箱和集群管理。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/aixiaoyang168/article/details/88664263
Network policy（下文简称为np）的本质是通过Kubernetes（下文简称k8s）的网络插件，创建一系列的网络规则，实现细粒度控制出入口流量，从而解决应用访问隔离的问题。因此选用哪种k8s网络方案很重要，如果这个方案没有实现np，那么k8s就不具备应用访问隔离的能力了，具体可以参见官方文档。
https://buoyant.io/2020/09/16/linkerds-ci-kubernetes-in-docker-github-actions/
如今如果没有提及容器，就很难谈论云计算。无论技术新手还是经验丰富的专家，都需要了解与云中容器相关的这些关键术语。 随着云计算中容器的普及，更多的组织选择不考虑采用外部的容器。 容器已经存在了一段时间，但Docker最近帮助他们成为企业使用的焦点。随着云计算的发展，越来越多的企业看到采用混合和多云模型的好处，但确保软件在从一个环境转移到另一个环境时可靠运行是所面临的一个挑战。容器已经通过将应用程序及其所有组件包装到一个更便携的软件包来解决问题。 而且，随着云计算中容器的日益普及，包括亚马逊网络服务(AWS)
随着Google发布了其混合云服务：云服务平台（Cloud Service Platform，以下简称CSP）测试版，正式进军混合云领域，公有云三巨头全部拥有了混合云相关产品，云巨头角力混合云的时代正式开启。早在2015年，微软率先推出Auzre Stack混合云产品；2018年年底，AWS则跟进推出了其混合云产品OutPosts。
在Kubernetes集群上运行多个服务和应用程序时，统一的日志收集不可或缺，Elasticsearch、Filebeat和Kibana（EFK）堆栈是目前较受欢迎的日志收集解决方案。在本教程中，我们将为部署在集群中的应用和集群本身设置生产级Kubernetes日志记录。将使用Elasticsearch作为日志后端，同时Elasticsearch的设置将具有极高的可扩展性和容错性。本教程一共有两篇，这是第一篇。
Prometheus是一个用于监控和告警的开源系统。一开始由Soundcloud开发，后来在2016年，它迁移到CNCF并且称为Kubernetes之后最流行的项目之一。从整个Linux服务器到stand-alone web服务器、数据库服务或一个单独的进程，它都能监控。在Prometheus术语中，它所监控的事物称为目标（Target）。每个目标单元被称为指标（metric）。它以设置好的时间间隔通过http抓取目标，以收集指标并将数据放置在其时序数据库（Time Series Database）中。你可以使用PromQL查询语言查询相关target的指标。
Kubernetes是当前最为流行的开源容器编排平台，成为众多企业构建基础架构的首选。在本文中，我们将探讨针对你的用例构建基础设施的最佳方式，以及你可能要根据各种限制条件做出的各种决定。
Kubernetes这个自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。因其具有对容器集群的方便部署，自动伸缩扩容，以及便于维护等功能和特性，为开源圈的开发者们所青睐。
从 Kubernetes 1.8 开始，资源使用指标（如容器 CPU 和内存使用率）通过 Metrics API 在 Kubernetes 中获取。 这些指标可以直接被用户访问(例如通过使用 kubectl top 命令)，或由集群中的控制器使用(例如，Horizontal Pod Autoscale 可以使用这些指标作出决策)。
原文链接：https://medium.com/@jdrawlings/serverless-jenkins-with-jenkins-x-9134cbfe6870
Kubestriker是一款针对Kubernetes的快速安全审计工具，Kubestriker可以对Kubernetes的infra容器执行大量深入检测，以帮助研究人员识别其中存在的安全错误配置以及其他安全问题。这些安全问题可能是工程师或开发人员在使用Kubernetes会遇到的，尤其是在大规模生成环境之中，一个小小的安全问题可能会带来严重的安全风险。
根据 CAST AI 对 4000 个 Kubernetes 集群的分析，Kubernetes 集群通常只使用 13% 的 CPU 和平均 20% 的内存，这表明存在严重的过度配置。
原文：http://mp.weixin.qq.com/s/dHaiX3H421jBhnzgCCsktg 当我们使用k8s集群部署好应用的Service时，默认的Service类型是ClusterIP，这种类型只有 Cluster 内的节点和 Pod 可以访问。如何将应用的Service暴露给Cluster外部访问呢，Kubernetes 提供了多种类型的 Service，如下： ClusterIP ---- ClusterIP服务是Kuberntets的默认服务。它在集群内部生成一个服务，供集群内的其他应用
Cluster API是一个Kubernetes项目，它将声明式Kubernetes风格的API用于集群的创建、配置和管理。它在核心Kubernetes之上，提供可选的附加功能来管理Kubernetes集群的生命周期。
在本指南中，我们将介绍如何将Linkerd安装到Kubernetes集群中。然后，我们将部署一个示例应用程序来展示Linkerd可以为你的服务做些什么。
本文档介绍了一些用于创建具有弹性和可扩展性的应用程序的模式和实践，这是许多现代架构练习的两个基本目标。设计良好的应用程序会随着需求的增加和减少而上下扩展，并且具有足够的弹性以承受服务中断。构建和运行满足这些要求的应用程序需要仔细规划和设计。
最近，很多人问我 NodePorts，LoadBalancer和 Ingress 之间的区别是什么？它们是将外部流量引入集群的不同方式，而且它们的运行形式各不相同。接下来，请你跟我一起，来看看他们是如何工作的，以及它们各自的适用情况。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
