最近我们生产环境升级了 contour 到1.4.0版本，用户反映偶发404问题。 经过简单测试，只在通过浏览器访问启用了https的网站上会偶发404。 我们的一个项目httpproxy如下： {代码...} 查看envoy的accesslog 可以看到： {代码...} 考虑是和SNI相关。 此时万能的github 搜索一下。果然已经有其他人踩到坑了。 I've found a s...

容器内的主进程（PID为1的进程）将收到SIGTERM，并在宽限期之后收到SIGKILL。在容器中的应用程序，可以选择忽略和不处理SIGTERM信号，不过一旦达到超时时间，程序就会被系统强行kill掉，因为SIGKILL信号是直接发往系统内核的，应用程序没有机会去处理它。

cdk8s是一个由aws开源的软件开发框架，用于使用熟悉的编程语言和丰富的面向对象的API定义Kubernetes应用程序和可重用的抽象。 cdk8s生成纯Kubernetes YAML--您可以使用cdk8s为在任何地方运行的任何Kubernetes集群定义应用程序。

在Kubernetes中，Ingress是一个组件，可将流量从群集外部路由到群集中的服务和Pod。 简而言之，Ingress充当反向代理或负载平衡器：所有外部流量都路由到Ingress，然后路由到其他组件。 尽管最受欢迎的Ingress是ingress-nginx项目，但是在选择和使用Ingress时还有其他几种选择。 您可以从以下Ingress控制器中选择： 处理...

随着微服务的发展，经常遇到实施身份验证和授权（A＆A）的问题。我们需要一个强大且集中管理的身份验证和授权策略。但是，应用程序的分布式性质使其难以实现。在本文中，我将探讨Open Policy Agent如何帮助简化授权问题。

在讲contour之前，我们先讲什么是ingress？ Ingress 公开了从集群外部到集群内 services 的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。 可以将 Ingress 配置为提供服务外部可访问的 URL、负载均衡流量、终止 SSL / TLS，以及提供基于名称的虚拟主机。 Ingress 不会公开任意端口或协议。 将 HTTP ...

在过去的几年中，容器的普及和采用猛增，并且Kubernetes容器编排平台也被广泛采用。通过这些更改，在处理现实世界中部署在Kubernetes集群上的应用程序时，出现了一系列新的挑战。挑战之一是如何处理可能位于不同网络（甚至是私有网络），防火墙之后的多个群集之间的通信。

在本文中，我们将提出一种我们认为满足这些约束的解决方案，称为服务镜像。为了符合Linkerd的“保持简单”的设计原则，我们已竭尽全力以纯Kubernetes原语构建此解决方案，并消除了对Linkerd本身的任何依赖。这使我们能够使任何解决方案尽可能接近Kubernetes本身。换句话说，网格应该做的更少，而不是更多。

在我们多年使用kubernetes的经验中，我们有幸看到了很多集群（在GCP，AWS和Azure上都是托管的和非托管的），并且我们看到一些错误在不断重复。

Knative的一个问题是在本地运行它。 Kubernetes非常庞大，在它之上运行另一个平台是一个非常困难的事情。今天，我们将介绍一些不同的方法来测试Knative，而不会过多占用您的计算机。

在过去的几天中，我的某些Pod持续panic，并且OS Syslog显示OOM Killer杀死了容器进程。我做了一些研究，以找出这些东西是如何工作的。

这是从Kubernetes Patterns本书综合的初学者必知的十大设计模式。熟悉这些模式将帮助您理解Kubernetes的基本概念，从而在讨论和设计基于Kubernetes的应用程序时为您提供帮助。

互联网上有很多很棒的机器学习教程。但是，它们大多数都专注于机器学习的特定部分，例如，探索数据，建立模型，训练和评估。其中很少有人介绍构建机器学习模型的完整步骤。

在一般的大型IT组织中，很少有人会构建完全隔离的新应用程序，而该应用程序会与所有其他旧系统或新系统完全分离。许多实时用例要求新旧系统共享和交换数据。

可观察性，即监视服务和检查跟踪的能力，对于任何事件驱动的分布式系统而言，都是至关重要的体系结构。 安装 安装可观察性功能，以在服务和事件组件中启用日志记录，指标和请求跟踪。 所有可观察性插件都要求您首先安装core： {代码...} 安装core后，您可以选择安装以下一个或所有可观察性插件： metrics 1：运行以下命...

Knative Eventing是一个旨在满足云原生开发的常见需求的系统，并提供可组合的原语以启用后期绑定事件源和事件使用者。具备以下设计目标：

本文主要利用Knative Serving 部署一个gRPC服务。 此示例可用于在knative服务中试用gRPC，HTTP / 2和自定义端口配置。 容器镜像由两个二进制文件构建：服务器和客户端。这样做是为了便于测试，不建议将其用于生产容器。 构建和部署示例代码 1：clone代码仓库 {代码...} 使用Docker来为此服务构建容器镜像，并将其推送到D...

本文演示了使用蓝/绿部署模式将应用程序更新到新版本。使用Knative，您可以通过更改路由配置将流量从应用程序的实时版本安全地重新路由到新版本。

Knative共用单个共享自动缩放器。默认情况下，这是Knative Pod自动缩放器（KPA），开箱即用即可提供基于请求的快速自动缩放功能。

在我们部署Knative Serving service 之前，重要的是要了解其部署模型和构成Knative服务的Kubernetes资源。

Knative 组件包含两个大的领域，分别是Serving和Event。今天我们主要部署Serving部分。Serving，即服务，基于Kubernetes的crd提供缩容至零、请求驱动的计算功能。它本质上是无服务器平台的执行和扩展组件。主要有以下特性：

如同许多新的概念一样，Serverless目前还没有一个普遍公认的权威的定义。最新的一个定义是这样描述的：“无服务器架构是基于互联网的系统，其中应用开发不使用常规的服务进程。相反，它们仅依赖于第三方服务（例如AWS Lambda服务），客户端逻辑和服务托管远程过程调用的组合。”

在[链接]，我们使用的思想是“每个Docker容器一个进程”。当然，我们也将这种思想应用于运行集成组件。因此，我们的每个集成组件实际上都是一个Docker容器内部的一个进程，并且每个Docker容器都在Mesosphere和Kubernetes上运行。

Ingress是现有的各种负载均衡器的Kubernetes抽象。例如，有本地负载平衡器，Amazon ELB / ALB，Google Cloud Platform负载平衡器，Digital Ocean负载平衡器，此列表不胜枚举。用户只需编写一个Ingress规范，然后由IngressController负责配置负载均衡器。配置后，将为用户提供一个IP地址，可以在其中访问其服务。

通过水平Pod自动缩放器支持Kubernetes中的自动缩放。使用HPA，可以直接进行横向扩展，HPA可以为部署增加副本，并可以创建其他worker来共享工作负载。但是，伸缩是问题所在，伸缩过程会根据Pod在节点上的位置对它们进行排序，从而选择要终止的Pod。因此，如果有一个Pod仍在进行某些处理，则无法保证它不会被终止。

之前说过由于Prometheus强大的exporter生态和服务发现等诸多优点，其他各种长期存储，只能选择融入到Prometheus的生态中。

在介绍CNI Chaining之前，我们先简单介绍一下Cilium。要说现在最火的容器网络，莫过于Cilium了。Cilium 是一个基于 eBPF 和 XDP 的高性能容器网络方案，代码开源在[链接]。其主要功能特性包括

Spring Boot 是常用 Java 微服务框架之一。Spring Cloud 拥有一组丰富的、良好集成的 Java 类库，用于应对 Java 应用程序堆栈中发生的运行时问题；而 Kubernetes 则提供了丰富的功能集来运行多语言微服务。这些技术彼此互补，为 Spring Boot 应用程序提供了强大的平台。

BuildKit是Docker官方社区推出的下一代镜像构建神器--可以更加快速，有效，安全地构建docker 镜像。Docker v18.06已经集成了该组件。BuildKit可用于多种导出格式（例如OCI或Docker）以及前端支持（Dockerfile），并提供高效缓存和运行并行构建操作等功能。BuildKit仅需要容器运行时就能执行，当前受支持的运行时包括cont...

在典型的Kubernetes部署中，所有流向Kubernetes服务的流量都通过一个ingress进行。Ingress将代理从Internet到后端服务的流量，因此，入口处于性能的关键路径上。有多种基准测试方法并衡量效果。