简介

Calico是一个基于BGP的纯三层的网络方案,与OpenStack,Kubernetes,AWS,GCE等云平台都能够良好地集成.

Calico在每个计算节点利用Linux kernel实现了一个高效的vrouter来负责转发.每个vrouter通过BGP1协议把在本节点上运行的容器的路由信息向整个calico网络广播,并自动设置到达其它节点的路由转发规则.

CustomResourceDefinition简介

在 Kubernetes 中一切都可视为资源，Kubernetes 1.7 之后增加了对 CRD 自定义资源二次开发能力来扩展 Kubernetes API，通过 CRD 我们可以向 Kubernetes API 中增加新资源类型，而不需要修改 Kubernetes 源码来创建自定义的 API server，该功能大大提高了 Kubernetes 的扩展能力。 当你创建一个新的CustomResourceDefinition (CRD)时，Kubernetes API服务器将为你指定的每个版本创建一个新的RESTful资源路径，我们可以根据该api路径来创建一些我们自己定义的类型资源。CRD可以是命名空间的，也可以是集群范围的，由CRD的作用域(scpoe)字段中所指定的，与现有的内置对象一样，删除名称空间将删除该名称空间中的所有自定义对象。customresourcedefinition本身没有名称空间，所有名称空间都可以使用。

了解pause

Kubernetes 中所谓的 pause 容器有时候也称为 infra 容器，它与用户容器”捆绑“运行在同一个 Pod 中，最大的作用是维护 Pod 网络协议栈（当然，也包括其他工作，下文会介绍）。

都说 Pod 是 Kubernetes 设计的精髓，而 pause 容器则是 Pod 网络模型的精髓，理解 pause 容器能够更好地帮助我们理解 Kubernetes Pod 的设计初衷。为什么这么说呢？还得从 Pod 沙箱（Pod Sandbox）说起。

使用场景 当我们需要进行服务端认证，甚至双向认证时，我们需要生成密钥对和服务信息，并使用ca对公钥和服务信息进行批准签发，生成一个证书。

我们简单描述下单向认证和双向认证的场景流程

基础原则

• 每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中，不管是否运行在同一Node上都可以通过Pod的IP来访问。
• 对于支持主机网络的平台,其Pod若采用主机网络方式,则Pod仍然可以不通过NAT的方式访问其余的Pod
• k8s中Pod的IP是最小粒度IP。同一个Pod内所有的容器共享一个网络堆栈，该模型称为IP-per-Pod模型。
• Pod由docker0实际分配的IP，Pod内部看到的IP地址和端口与外部保持一致。同一个Pod内的不同容器共享网络，可以通过localhost来访问对方的端口，类似同一个VM内的不同进程。
• IP-per-Pod模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看，Pod可以看作是一台独立的VM或物理机。

Kubernetes网络地址4大关注点

1. Pod内的容器可以通过loopback口通信
2. 集群网络为Pods间的通信提供条件
3. Service API暴露集群中的Pod的应用给外部,以便外部使用
4. 也可只使用Services在集群内部使用

从外面看Pod IP地址之Kubernetes API

1. kubectl get pod或者kubectl describe pod就可以
2. 如果运行在容器内的进程希望获取该容器的IP,可以通过环境变量的方式来获取IP

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

spec:
  containers:
    - name: env-pod
      image: busybox
      command: ["/bin/sh", "-c","env"]
      env:
      - name: POD_IP
        valueFrom:
          fieldRef:
            fieldPath: status.podIP

从外面看Pod IP之docker命令

假设容器的ID是6e8147cd2f3d, 一般情况下可以通过以下命令查询容器的IP地址:

k8s网络模型设计的一个基础原则是：每个Pod都拥有一个独立的IP地址，而且假定所有Pod都在一个可以直接连通的、扁平的网络空间中。

所以不管他们是否运行在同一个Node（宿主机中），都要求他们可以直接通过对方的IP进行访问。 设计这个原则的原因是，用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑将容器端口映射到主机端口等问题。

ConfigMap

使用ConfigMap 的限制条件如下。

• ConfigMap 必须在Pod 之前创建。

• ConfigMap 受Namespace 限制，只有处于相同Namespaces 中的Pod 可以引用它。

• ConfigMap 中的配额管理还未能实现。

k8s核心原理

API Server

总体来看， Kubemetes API Server 的核心功能是提供了Kubemetes 各类资源对象（如Pod 、RC 、Service 等〉的增、删、改、查及Watch 等HTTP Rest 接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。 除此之外，它还有以下一些功能特性。

Pod 生命周期

Pod 在整个生命周期过程中被系统定义为各种状态 Pod 的状态如表2.14 所示。 表2.14 Pod 的状态

Pod重启策略

Pod 的重启策略（ RestartPolicy ）应用于Pod 内的所有容器，井且仅在Pod 所处的Node上由kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查（详见下节）失败时， kubelet将根据RestartPolicy 的设置来进行相应的操作。 Pod 的重启策略包括Always、OnFailure和Never， 默认值为Always：

Service

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

参考文章：https://developer.aliyun.com/learning/course/572/detail/7866

如何开发自己的CNI插件

CNI插件的实现通常包含两个部分：

参考文章：https://zhuanlan.zhihu.com/p/102897620

CRI是什么

CRI： Container Runtime Interface，容器运行时接口；

CRI包括Protocol Buffers、gRPC API、运行库支持及开发中的标准规范和工具，是以容器为中心设计的API，设计CRI的初衷是不希望向容器（比如docker）暴露pod信息或pod的api。

Service

在k8s中，Service（服务）是分布式集群架构的核心，一个Service对象拥有如下关键特征：

• 拥有一个唯一指定的名字（比如mysql-server）
• 拥有一个虚拟IP（Cluster IP、service IP或VIP）和端口号。
• 能够提供某种远程服务能力。
• 被映射到了提供这种服务能力的一组容器应用上。

为了建立Service和Pod之间的关联关系，k8s给每个Pod贴上标签（Label），如运行MySQL的Pod贴上name=mysql标签。然后给相应的Service定义标签选择器（Label Selector）