微服务之——K8S基本概念+组件

首先先来谈谈Kubernetes 优势：

自我修复

在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

前置说明：

作者/李逸锋

随着微服务、云原生架构的普及，网络通信在容器化部署环境中愈发重要。本文将全面解析容器、Pod、虚拟机（VM）、宿主机之间的通信原理与路径，涵盖常见网络模式（如 Docker 网络模式、Kubernetes Pod 网络、虚拟机桥接/NAT），并结合 Mermaid 图表展示网络结构和通信流程，帮助读者从整体上理解这套复杂的网络体系。

istio-02.png

在上一篇

一、介绍

Operator是CoreOS公司开发，用于扩展kubernetes API或特定应用程序的控制器，它用来创建、配置、管理复杂的有状态应用，例如数据库，监控系统。其中Prometheus-Operator就是其中一个重要的项目。

其架构图如下：

Pod 资源配置

实际上上面几个步骤就是影响一个 Pod 生命周期的大的部分，但是还有一些细节也会在 Pod 的启动过程进行设置，比如在容器启动之前还会为当前的容器设置分配的 CPU、内存等资源，我们知道我们可以通过 CGroup 来对容器的资源进行限制，同样的，在 Pod 中我们也可以直接配置某个容器的使用的 CPU 或者内存的上限。那么 Pod 是如何来使用和控制这些资源的分配的呢？

一、Flannel简介

Flannel 由CoreOS开发，用于解决docker集群跨主机通讯的覆盖网络(overlay network)，它的主要思路是：预先留出一个网段，每个主机使用其中一部分，然后每个容器被分配不同的ip；让所有的容器认为大家在同一个直连的网络，底层通过UDP/VxLAN/Host-GW等进行报文的封装和转发。

问题1：K8S集群服务访问失败？

在K8S中，同一个命名空间（namespace）下的服务之间调用，之间通过服务名（service name）调用即可。不过在更多时候，我们可能会将一些服务单独隔离在一个命名空间中（比如我们将中间件服务统一放在 middleware 命名空间中，将业务服务放在 business 命名空间中）。
遇到这种情况，我们就需要跨命名空间访问，K8S 对service 提供了四种不同的类型，针对这个问题我们选用 ExternalName 类型的 service 即可。