Kubernetes 概念入门

本文主要归纳了K8s入门的一些必须熟知的概念，具体的还是需要自己去看相关文档学习，建议过一遍本文了解概念后深入学习。

整体架构

在一个K8s应用中，简单来讲我们主要需要以下：

• Container: 基本容器，可以是Docker，甚至也可以是其他容器！
• Pod: K8s基本单元，简单理解为就是一个管理着多容器的集装箱，能做到对多个Container的管理
• Deployment: 对Pod进行管理
• Service: 集群内虚拟出来的一个网络层，通过修改路由实现，实际上网络并不存在这一层
• Ingress: 集群外访问的网络层

参考链接

Kubernetes 对象

该对象包含了我们对该应用正常运行时的预期状态和现在状态。

即对象规约（Spec）与状态（Status）

如同 Deployment 对象，通过指定spec 来设置其预期状态，K8S便会自动化的去更新 status 到我们的预期状态：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:    # Deployment 的预期状态
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:        # Pod 的模板？
    metadata:
      labels:
        app: nginx
    spec: # Pod 的预期状态
      containers:
      - name: nginx    
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Kubernetes 对象管理方式

K8s的运行需要Deployment等对象 如何去新增修改删除K8s对象等都需要一个管理API来操作

如上述是通过YAML文件来管理K8s对象的，但同时还可以通过其他方式来管理Kubernetes 对象

Shell命令

简单的部署通过 kubectl 来管理即可

kubectl run nginx --image nginx
kubectl create deployment nginx --image nginx

命令式对象配置

一般性的部署可以通过配置YAML或JSON文件来实现

kubectl create -f nginx.yaml    # 新增
kubectl delete -f nginx.yaml -f redis.yaml    # 删除
kubectl replace -f nginx.yaml    # 更新

声明式对象配置

使用声明式对象配置时，用户对本地存储的对象配置文件进行操作，但是用户未定义要对该文件执行的操作。kubectl 会自动检测每个文件的创建、更新和删除操作。这使得配置可以在目录上工作，根据目录中配置文件对不同的对象执行不同的操作。

处理 configs 目录中的所有对象配置文件，创建并更新活动对象。可以首先使用 diff 子命令查看将要进行的更改，然后在进行应用：

kubectl diff -f configs/
kubectl apply -f configs/

递归处理目录：

kubectl diff -R -f configs/
kubectl apply -R -f configs/

架构

节点

Node: 一个虚拟机或者物理机器，主要用于运行Pods

每个节点都包含：

• kubelet: 节点代理，相当于一个控制单元，和ApiServer通信保证容器运行
• container-runtimes: 主要是运行的相关环境如Docker
• kube-proxy: 网络代理

注册方式：

• 节点上的 kubelet 向控制面执行自注册： 首选模式。
• 你，或者别的什么人，手动添加一个 Node 对象。

ApiServer通信

ApiServer和集群的通信方式中，集群和ApiServer通信通常采用的是HTTPS链接通信，并通过令牌等身份认证方式保证两端安全通信。

而对于ApiServer到集群的通信一般有以下方案：

ApiServer到 kubelet

从 ApiServer 到 kubelet 的连接用于：

• 获取 Pod 日志
• 挂接（通过 kubectl）到运行中的 Pod
• 提供 kubelet 的端口转发功能。

Apiserver 到节点、Pod 和服务

从 Apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 https: 来运行在安全的 HTTPS 连接上。 不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。 因此，虽然连接是加密的，仍无法提供任何完整性保证。 这些连接 目前还不能安全地 在非受信网络或公共网络上运行。

Konnectivity 服务

作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。 Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理，分别运行在 控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。

控制器

控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。

每个控制器（Job、Deployment等）都致力于去实现期望状态，他们分管不同的集群状态，通过使用某类资源将另一类资源变为期望状态。