#kubernetes

上手Knative的 - 第2部分 在我之前的文章中 ，我谈到了 Knative Serving ，用于快速部署和无服务器容器的自动扩展。 如果您希望HTTP呼叫同步触发您的服务，Knative Serving非常棒。 但是，在无服务器的微服务世界中，异步触发器更常见且更有用。 那是 Knative Eventing 发挥作用的时候。 在Hands on Knative系列的第二部分中，我想介绍Knative Eventing并在我的 Knative Tutorial 中展示如何将其与各种服务集成的 一些示例 。 什么是Knative Eventing？ Knative Eventing与Knative Serving携手合作，为松散耦合的事件驱动服务提供原语。 典型的Knative Eventing架构如下所示： 有4个主要组成部分： Source （aka Producer）从实际源读取事件并将下游转发到Channel或更不常见地直接转发到Service。 频道 从源接收事件，保存到其底层存储（稍后将详细介绍）并向所有订户扇出。 订阅 桥接通道和服务（或另一个通道）。 服务 （又名消费者）是消费事件流的Knative服务。 让我们更详细地看一下这些。 来源，渠道和订阅 Knative Eventing的最终目标是将事件从源路由到服务，并使用我之前提到的原语来实现：Source，Channel和Subscription。 Source 从实际源读取事件并将其转发到下游。 截至今天，Knative支持从 Kubernetes ， GitHub ， Google Cloud Pub / Sub ， AWS SQS主题 ， 容器 和 CronJobs中 读取事件 。 一旦事件被拉入Knative，它需要保存在内存中或更耐用的地方，如Kafka或Google Cloud Pub / Sub。 通道 发生了这种情况。 它有多种 实现 来支持不同的选项。 [Read More]

上手Knative的 - 第1部分 我最近一直在研究 Knative 。这个博客系列由3部分组成，我想解释一下我的学习内容并展示我在GitHub上发布的Knative Tutorial 中的示例 。 什么是Knative？ Knative 是一个开源构建块的集合，用于在Kubernetes上运行的serverless容器。 在这一点上，你可能想知道：“Kubernetes，serverless，发生了什么？”但是，当你想到它时，它是有道理的。Kubernetes是非常受欢迎的容器管理平台。serverless是应用程序开发人员想要运行其代码的方式。Knative将两个世界与一组构建块结合在一起。 谈到构建块，它由3个主要组件组成： Knative Serving 用于快速部署和serverless容器的自动扩展。 Knative Eventing针对松散耦合的事件驱动服务的。 Knative Build 用于无痛的代码到容器的注册表工作流程。 让我们从Knative Serving开始吧。 什么是Knative Serving？ 简而言之，Knative Serving允许serverless容器的快速部署和自动扩展。您只需指定要部署的容器，Knative将详细说明如何创建该容器并将流量路由到该容器。将serverless容器部署为Knative服务后，您将获得自动扩展，每个配置更改的revision，不同revision之间的流量分配等功能。 你好世界服务 要将代码部署为Knative服务，您需要： 包含您的代码并将镜像推送到公共注册表。 创建一个服务yaml文件，告诉Knative在哪里可以找到容器镜像及其具有的任何配置。 在我的Knative教程的 Hello World服务 中，我详细描述了这些步骤，但回顾一下，这是最小的Knative服务定义的 service-v1.yaml 示例： apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: helloworld-csharp namespace: default spec: runLatest: configuration: revisionTemplate: spec: container: # replace {username} with your DockerHub image: docker.io/{username}/helloworld-csharp:v1 env: - name: TARGET value: "C# Sample v1" runLatest 意味着我们希望使用指定的容器和配置立即部署最新版本的代码。部署服务： [Read More]

Cilium 1.4：多集群服务路由，DNS授权，IPVLAN支持，透明加密，Flannel集成，与其他CNI的基准测试，…… 通告 我们很高兴地宣布Cilium 1.4版本。 该版本引入了几项新功能以及优化和可扩展性工作。 重点包括增加全局服务，提供跨多个集群的Kubernetes服务路由、DNS请求/响应感知授权和可见性、透明加密（beta）、IPVLAN支持以获得更好的性能和延迟（beta）、与Flannel集成、GKE在COS上支持、基于AWS元数据的策略实施（alpha）以及优化内存和CPU使用的重要工作。 像往常一样，感谢过去4个月中在版本1.3和1.4之间贡献了1048次提交的Cilium开发人员及整个社区。 Cilium是什么？ Cilium是一个开源软件，用于透明地提供和保护使用Kubernetes、Docker和Mesos等Linux容器管理平台部署的应用程序服务之间的网络和API连接。 Cilium的基础是一种名为BPF的新Linux内核技术，它可以在Linux本身内动态插入强大的安全性、可见性和网络控制逻辑。BPF用于提供诸如多集群路由，负载均衡以取代kube-proxy，使用X.509证书的透明加密以及网络和服务安全性等功能。除了提供传统的网络级安全性之外，BPF的灵活性还可以通过应用程序协议和DNS请求/响应的上下文实现安全性。Cilium与Envoy紧密集成，并提供基于Go的扩展框架。由于BPF在Linux内核中运行，因此可以应用所有Cilium功能，而无需对应用程序代码或容器配置进行任何更改。 有关 Cilium 的更详细的介绍， 请参阅Cilium简介 一节。 多集群服务路由 Cilium 1.3在多个集群之间引入了基本的pod IP路由功能。Cilium 1.4引入了基于标准Kubernetes服务的全局服务概念。全局服务允许用户指定Kubernetes服务在多个集群中可用。然后，该服务可以在多个集群中具有后端pod。 用户体验就像在每个集群中定义具有相同名称和命名空间的Kubernetes服务并添加注释以将其标记为全局一样简单。 当pod向上或向下扩展或变得不健康时，Kubernetes运行状态检查信息可用于自动添加和删除后端服务。 控制平面建立在etcd之上，类似于Kubernetes原生的操作方式，具有弹性和简单性作为其基本设计模式。每个集群继续运行其自己的etcd集群，并且复制以只读方式进行，这可确保集群中的故障不会影响其他集群。 将集群连接在一起就像使用云供应商的标准路由API或基于常规IP地址的VPN网关和隧道的本地基础设施在VPC之间提供路由，然后通过内部Kubernetes负载均衡器暴露Cilium控制平面以将其暴露给内部VPC一样简单。TLS用于使用作为Kubernetes Secret管理的证书和密钥对客户端和服务器进行身份验证。 IPVLAN支持（测试版） 添加了一种新的基于IPVLAN的数据路径模式。与基于veth的体系结构相比，IPVLAN具有低延迟优势。使用netperf在3.40Ghz Xeon上的两个本地容器之间测量了以下基准测试，并使用单核禁用超线程。与veth相比，IPVLAN的P99延迟相对较低（越低越好）： IPVLAN和veth之间的最大吞吐量（越高越好）非常相似，但是通过从内核编译netfilter/iptables可以实现非常显着的性能提升。如果您不使用NodePort服务并且在离开Kubernete worker node时不需要伪装网络流量，则已经可以完全运行您的Kubernetes集群。我们将在接下来的几周内提供有关如何运行iptables和kube-proxy的指南。 IPVLAN是1.4中的beta级功能，有关如何启用和配置该功能的说明，请参阅 IPVLAN入门指南 。 DNS请求/响应的安全性和可见性 Cilium 1.4扩展了现有的DNS安全策略模型，以了解各个pod发出的DNS请求以及它们收到的DNS响应。 这显着提高了访问集群外部服务的pod的安全性： 在执行DNS查找时，可以将Pod限制为具有最小权限，即 pod可以仅限于查找匹配模式的DNS名称，例如 *.domain.com 。 任何超出允许模式的请求都将收到 request refused DNS响应。 DNS查找后的通信可以限制为特定pod接收的DNS响应中返回的IP地址。 这显着降低了受损应用程序的权限，并提高了基于DNS的策略规则的可靠性，因为执行逻辑不再需要知道DNS名称可以映射到的所有可能的IP地址。 特别是对于云供应商提供的流行存储，消息传递和数据库服务，单个DNS名称可以映射到数百或数千个IP地址。 现在可以通过API访问的Cilium授权日志记录层记录DNS查找和响应。 这提供了pod执行的每个DNS请求和响应的精确日志。 上面的示例显示了一个成功的DNS序列，然后是DNS服务器响应的对IP的HTTP请求。 这是应用程序的行为方式和允许的方式。 后续HTTP请求可以使用缓存的DNS信息，允许此类请求。 DNS信息将根据记录中的TTL信息超时。 右侧是应用程序在允许的DNS策略之外执行DNS查找的序列。 它还显示，如果应用程序无法执行DNS查找，则在应用程序无法在以下位置查找DNS名称时，即使IP地址实际映射到允许的DNS名称，也会阻止任何尝试联系IP地址的尝试。一点。 策略示例 apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "egress-domain-wildcard" spec: endpointSelector: matchLabels: app: myService egress: - toEndpoints: - matchLabels: 'k8s:io. [Read More]

Istio 是一个由Google，IBM和Lyft团队合作开发的开源项目，它提供了基于微服务的应用程序复杂性的解决方案，仅举几例： 流量管理 ：超时，重试，负载均衡， 安全性： 最终用户身份验证和授权， 可观察性： 跟踪，监控和记录。 所有这些都可以在应用程序层中解决，但是您的服务不再是“微型”，相对于提供业务价值的资源，实现这些的所有额外工作都是公司资源的压力。我们来举个例子： PM：添加反馈功能需要多长时间？ 开发：两个冲刺（敏捷开发中的术语，一般一个冲刺周期30天）。 PM：什么……？ 那只是一个CRUD！ 开发：创建CRUD很容易，但我们需要对用户和服务进行身份验证和授权。而且由于网络不可靠，我们需要在客户端实施重试和熔断器，并确保我们不会占用整个系统，我们需要Timeout和Bulkheads，另外还要检测我们需要监控的问题，跟踪[… ] PM：那么我们就把它放在产品服务中吧。哎呀！ 你明白了，必须满足所有形式才可以为我们添加一项巨大的服务（有很多不是业务功能的代码）。在本文中，我们将展示Istio如何从我们的服务中删除所有上述交叉问题。 注意： 本文假设您具有Kubernetes的知识。如果不是这种情况，我建议您阅读 我对Kubernetes的介绍，然后继续阅读本文。 关于Istio 在没有Istio的世界中，一个服务向另一个服务直接发出请求，并且在发生故障的情况下，服务需要通过重试，超时，打开熔断器等来处理它。 为了解决这个问题，Istio通过与服务完全分离，并通过拦截所有网络通信来提供一种巧妙的解决方案。这样做可以实现： Fault Tolerance - 使用响应状态代码，它可以在请求失败并重试时理解。 Canary Rollouts - 仅将指定百分比的请求转发到新版本的服务。 监控和指标 - 服务响应所花费的时间。 跟踪和可观察性 - 它在每个请求中添加特殊header，并在集群中跟踪它们。 安全性 - 提取JWT令牌并对用户进行身份验证和授权。 仅举几例（仅举几例），让您感兴趣！ 我们来看一些技术细节吧！ Istio的架构 Istio拦截所有网络流量，并通过在每个pod中注入智能代理作为sidecar来应用一组规则。启用所有功能的代理包括 数据平面， 并且这些代理可由控制平面 动态配置。 数据平面 注入的代理使Istio能够轻松满足我们的要求。举个例子，我们来看看重试和熔断器功能。 总结一下： Envoy将请求发送到服务B的第一个实例，但它失败了。 Envoy sidecar重试。（1） 返回对调用代理的失败请求。 这将打开熔断器并在后续请求中调用下一个服务。（2） 这意味着您不必使用另一个重试库，您不必在编程语言X，Y或Z中开发自己的Circuit Breaking和Service Discovery实现。所有这些都是开箱即用的。这些功能都是通过Istio来实现，你不需要更改代码。 很好！ 现在你想加入Istio的航行，但你仍然有一些疑虑，一些悬而未决的问题。这是一个一刀切的方案，你对它持怀疑态度，因为它总是最终成为一刀切的无解方案！ 你最终低声说了这个问题：“这是可配置的吗？” [Read More]