容器概述在学习 Containerd 之前我们有必要对 Docker 的发展历史做一个简单的回顾，因为这里面牵涉到的组件实战是有点多，有很多我们会经常听到，但是不清楚这些组件到底是干什么用的，比如 libcontainer、runc、containerd、CRI、OCI 等等。 Docker从 Docker 1.11 版本开始，Docker 容器运行就不是简单通过 Docker Daemon 来启动了，而是通过集成 containerd、runc 等多个组件来完成的。虽然 Docker Daemon 守护进程模块在不停的重构，但是基本功能和定位没有太大的变化，一直都是 CS 架构，守护进程负责和 Docker Client 端交互，并管理 Docker 镜像和容器。现在的架构中组件 containerd 就会负责集群节点上容器的生命周期管理，并向上为 Docker Daemon 提供 gRPC 接口。 当我们要创建一个容器的时候，现在 Docker Daemon 并不能直接帮我们创建了，而是请求 containerd 来创建一个容器，containerd 收到请求后，也并不会直接去操 ...

SecretSecret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。 由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。 Secret 类似于 ConfigMap 但专门用于保存机密数据。 注意: 默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。 此外，任何有权限在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何 Secret； 这包括间接访问，例如创建 Deployment 的能力。 为了安全地使用 Secret，请至少执行以下步骤： 为 Secret 启用 ...

ConfigMapConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时， Pods 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。 ConfigMap 将你的环境配置信息和 容器镜像 解耦，我们知道许多应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求，这样就便于配置信息的修改。 ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过1MiB(这其实是ETCD的要求哈哈哈)。如果你需要保存超出此尺寸限制的数据，你可能希望考虑挂载存储卷 或者使用独立的数据库或者文件服务。 创建ConfigMapConfigMap 资源对象使用 key-value 形式的键值对来配置数据，这些数据可以在 Pod 里面使用，如下所示的资源清单： 123456789101112kind: ConfigMapapiVersion: v1metadata: name: cm-demo namespace: defaultdata: data.1: hello data.2: world confi ...

Linkerd 介绍Linkerd 是 Kubernetes 的一个完全开源的服务网格实现。它通过为你提供运行时调试、可观测性、可靠性和安全性，使运行服务更轻松、更安全，所有这些都不需要对你的代码进行任何更改。 Linkerd 通过在每个服务实例旁边安装一组超轻、透明的代理来工作。这些代理会自动处理进出服务的所有流量。由于它们是透明的，这些代理充当高度仪表化的进程外网络堆栈，向控制平面发送遥测数据并从控制平面接收控制信号。这种设计允许 Linkerd 测量和操纵进出你的服务的流量，而不会引入过多的延迟。为了尽可能小、轻和安全，Linkerd 的代理采用 Rust 编写。 功能概述 自动 mTLS：Linkerd 自动为网格应用程序之间的所有通信启用相互传输层安全性 (TLS)。 自动代理注入：Linkerd 会自动将数据平面代理注入到基于 annotations 的 pod 中。 容器网络接口插件：Linkerd 能被配置去运行一个 CNI 插件，该插件自动重写每个 pod 的 iptables 规则。 仪表板和 Grafana：Linkerd 提供了一个 Web 仪表板，以及预配置的 ...

Istio 可观察性前面我们学习了 Istio 中的流量管理功能，本节我们来学习如何配置 Istio来自动收集网格中的服务遥测。Istio为网格内所有的服务通信生成详细的遥测数据，这种遥测技术提供了服务的可观察性，使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。通过 Istio，运维人员可以全面了解到受监控的服务如何与其他服务以及Istio组件进行交互。 网站会自动生成以下类型的遥测数据，以提供对整个服务网格的可观察性: 指标:Istio 基于 4 个监控的黄金标识(延迟、流量、错误、饱和)生成了一系列服务指标，Isti 还为网格控制平面提供了更详细的指标，除此以外还提供了一组默认的基于这些指标的网格监控仪表板。 延迟表示服务一个请求所需的时间。这个指标应该分成成功请求（如 HTTP 200）和失败请求（如 HTTP 500）的延迟。 流量是衡量对系统的需求有多大，它是以系统的具体指标来衡量的。例如，每秒的 HTTP 请求，或并发会话，每秒的检索量，等等。 错误用来衡量请求失败的比率（例如 HTTP 500）。 饱和度衡量一个服务中最紧张的资源 ...

实例架构该应用由四个单独的微服务构成。 这个应用模仿在线书店的一个分类，显示一本书的信息。 页面上会显示一本书的描述，书籍的细节（ISBN、页数等），以及关于这本书的一些评论。 Bookinfo 应用分为四个单独的微服务： productpage. 这个微服务会调用 details 和 reviews 两个微服务，用来生成页面。 details. 这个微服务中包含了书籍的信息。 reviews. 这个微服务中包含了书籍相关的评论。它还会调用 ratings 微服务。 ratings. 这个微服务中包含了由书籍评价组成的评级信息。 reviews 微服务有 3 个版本： v1 版本不会调用 ratings 服务。 v2 版本会调用 ratings 服务，并使用 1 到 5 个黑色星形图标来显示评分信息。 v3 版本会调用 ratings 服务，并使用 1 到 5 个红色星形图标来显示评分信息。 Bookinfo 是一个异构应用，几个微服务是由不同的语言编写的。这些服务对 Istio 并无依赖，但是构成了一个有代表性的服务网格的例子：它由多个服务、多个语言构成，并且 review ...

Ingress Gateway简介传统上，Kubernetes使用Ingress控制器来处理从外部进入集群的流量。使用Istio时，情况不再如此。 Istio已用新的Gateway和VirtualServices资源替换了熟悉的Ingress资源。它们协同工作，将流量路由到网格中。在网格内部，不需要Gateway，因为服务可以通过集群本地服务名称相互访问。 Istio流量分发控制环境准备 主机名 IP 角色 k8s-master eth0:10.1.1.100、docker：172.17.100.0/24 K8S-master k8s-node1 eth0:10.1.1.120、docker：172.17.120.0/24 K8S-node k8s-node2 eth0:10.1.1.130、docker：172.17.130.0/24 K8S-node nginx-proxy eth0:10.1.1.11 代理节点 场景模型图目前我们实现了后台服务层面，前端front调用后端service的流量策略，现在实现下客户访问前端的流量 ...

Envoy简介什么是Envoy envoy 是作为微服务服务架构中以独立进程方式实现高级网络功能的，轻量级的7层服务代理程序，通常以sidecar的方式运行在应用程序的周边，也可以作为网络的边缘代理来运行。 envoy 的特性 进程外体系结构 ，L3/L4过滤器体系结构，HTTP L7过滤器体系结构， 一流的HTTP/2支持， HTTP/3支持(目前为alpha)，HTTP L7路由，gRPC支持，服务发现和动态配置，健康检查，高级负载平衡，前端/边缘代理支持， 一流的可观察性 服务网格细节剖析宏观分析执行的操作： 使用istioctl为pod注入了sidecar 创建了virtualservice和destinationrule 如何最终影响到了pod的访问行为？ 宏观角度nginx的配置中，可以提供类似如下的配置片段实现按照权重的转发： 因为nginx是代理层，可以转发请求，istio也实现了流量转发的效果，肯定也有代理层，并且识别了前面创建的虚拟服务中定义的规则。 1$ istioctl kube-inject -f front-t ...

Istio使用场景 在业务更新迭代快速发展时代，更新版本只靠Kubernetes实现简单的更新发布是不行的，如果想要实现对业务流量访问限制还需要借用Istio的能力，比如升级到v2版本，将v2版本接入流量占比要到10%，Kubernetes是无法实现。下面就是整个实现过程。 快速入门环境准备 主机名 IP 角色 k8s-master eth0:10.1.1.100、docker：172.17.100.0/24 K8S-master k8s-node1 eth0:10.1.1.120、docker：172.17.120.0/24 K8S-node k8s-node2 eth0:10.1.1.130、docker：172.17.130.0/24 K8S-node 场景一模型图 创建资源配置清单Front-tomcatBill-service-V1Service12345678910111213141516171819202122232425cat > front-tomcat-dpl-v1.yaml <<EOFapiV ...

Istio简介Istio：一个连接，管理和保护微服务的开放平台。 按照isito文档中给出的定义: Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。简单的说，有了Istio，你的服务就不再需要任何微服务开发框架（典型如Spring Cloud，Dubbo），也不再需要自己手动实现各种复杂的服务治理功能（很多是Spring Cloud和Dubbo也不能提供的，需要自己动手）。只要服务的客户端和服务端可以进行简单的直接网络访问，就可以通过将网络层委托Istio，从而获得一系列的完备功能。可以近似的理解为： Istio = 微服务框架 + 服务治理。 Istio的关键功能HTTP/1.1，HTTP/2，gRPC和TCP流量的自动区域感知负载平衡和故障切换。 通过丰富的路由规则，容错和故障注入，对流行为的细粒度控制。 支持访问控制，速率限制和配额的可插拔策略层和配置API。 集群内所有流量的自动量度，日志和跟踪，包括集群入口和出口。 安全的服务到服务身份验证，在集群中的服务之间具有强大的身 ...

前言最近有一个需求，如何禁用ssl证书，只用于Nginx 443端口转发流量？https服务器A和B 有 https 服务并提供两个 IP 以实现高可用。 例如https服务器 A[ip1:443] 和 B[ip2:443] 被路由到Nginx代理服务器上。 Nginx代理服务器没有 ssl_certificate 和 ssl_certificate_key使用 Nginx 代理模块将请求代理到实际的https服务器上。如何在没有SSL验证的情况下将443端口流量简单转发到后端。 使用nginx的stream、 stream_ssl_preread模块参考资料 Module ngx_stream_ssl_preread_module Module ngx_stream_core_module 准备工作 nginx版本1.11.5及以上 由于stream和stream_ssl_preread模块非默认引入，需要在编译安装nginx时引入；编译时添加配置参数 --with-stream 、--with-stream_ssl_preread_module。 配置stream 惊为天人的 ...