Kubernetes(一)：简介

墨蓝 2023-03-06 05:13 1阅读 0赞

### 文章目录 ###

*  一、部署方式
 *  二、容器
 *   *  2.1 容器管理工具
     *  2.2 容器编排部署工具
 *  三、Kubernetes
 *   *  3.1 Kubernetes简介
     *  3.2 Kubernetes架构图
     *  3.3 Kubernetes组件
     *   *  3.3.1 Master
         *  3.3.2 Node
         *  3.3.3 Pod
         *  3.3.4 Service
 *  四、Kubectl命令

> 中文官网：https://kubernetes.io/zh/  
> 中文社区：https://www.kubernetes.org.cn/  
> 官方文档：https://kubernetes.io/zh/docs/home/  
> 社区文档：http://dlocs.kubernetes.org.cn/

# 一、部署方式 #

![在这里插入图片描述][20210527100210977.png]  
**传统部署时代：**

早期，各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且维护许多物理服务器的成本很高。

**虚拟化部署时代：**

作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的`CPU`上运行多个虚拟机（`VM`）。虚拟化允许应用程序在`VM`之间隔离，并提供一定程度的安全，因为一个应用程序的信息不能被另一应用程序随意访问。

虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序而可以实现更好的可伸缩性，降低硬件成本等等。

每个`VM`是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

**容器部署时代：**

容器类似于`VM`，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（`OS`）。因此，容器被认为是轻量级的。容器与`VM`类似，具有自己的文件系统、`CPU`、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和`OS`发行版本进行移植。

# 二、容器 #

> 为了降低虚拟机造成的物理主机资源浪费，提高物理主机的资源利用率，并能够提供像虚拟机一样良好的应用程序隔离运行环境，人们把这种轻量级的虚拟机，称为“容器”。

## 2.1 容器管理工具 ##

容器管理工具类似于虚拟机管理工具，主要用于容器的创建、启动、关闭、删除等。

容器管理工具有：

*  `docker`公司的`docker`
 *  国内阿里公司的`Pouch`
 *  `LXC`、`LXD`、`RKT`等等

## 2.2 容器编排部署工具 ##

容器管理工具可以完成容器的基础管理，但是容器的应用并不是只能进行简单应用部署的，可以使用容器完成企业中更加复杂的应用部署，当需要对多应用的系统进行部署时，就需要更加复杂的工具来完成对容器运行应用的编排，这就是我们所说的容器编排部署工具。

容器编排部署工具有：

*  `docker`三剑客：`docker machine`、`docker compose`、`docker swarm`
 *  `mesos` \+ `marathon`
 *  `kubernetes`

# 三、Kubernetes #

## 3.1 Kubernetes简介 ##

`Kubernetes`（通常写成`k8s`），`Kubernetes`是`Google`开源的容器集群管理系统。其设计目标是在主机集群之间提供一个能够自动化部署、可拓展、应用容器可运营的平台。`Kubernetes`通常结合`docker`容器工具工作，并且整合多个运行着`docker`容器的主机集群，`Kubernetes`不仅仅支持`Docker`，还支持`Rocket`，这是另一种容器技术。

**功能特性：**

*  **自动装箱**：基于容器对应用运行环境的资源配置要求自动部署应用容器
 *  **自我修复**：当容器失败时，会对容器进行重启；当所部署的Node节点有问题时，会对容器进行重新部署和重新调度；当容器未通过监控检查时，会关闭此容器；直到容器正常运行时，才会对外提供服务
 *  **水平扩展**：通过简单的命令、用户`UI`界面或基于`CPU`等资源使用情况，对应用容器进行规模扩大或规模剪裁
 *  **服务发现**：用户不需要使用额外的服务发现机制，就能够基于`Kubernetes`自身能力实现服务发现和负载均衡
 *  **滚动更新**：可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新
 *  **版本回退**：可以根据应用部署情况，对应用容器运行的应用，进行历史版本即时回退
 *  **密钥和配置管理**：在不需要重新构建镜像的情况下，可以部署和更新密钥和应用配置，类似热部署
 *  **存储编排**：自动实现存储系统挂载及应用，特别对有状态应用实现数据持久化非常重要；存储系统可以来自于本地目录、网络存储(`NFS`、`Gluster`、`Ceph`、`Cinder`等)、公共云存储服务等

## 3.2 Kubernetes架构图 ##

![在这里插入图片描述][20200805150644600.png]

## 3.3 Kubernetes组件 ##

### 3.3.1 Master ###

> Master节点上面主要由四个模块组成：APIServer、scheduler、controller manager、etcd

**APIServer**：`APIServer`负责对外提供`RESTful`的`Kubernetes API`服务，它是系统管理指令的统一入口，任何对资源进行增删改查的操作都要交给`APIServer`处理后再提交给`etcd`。如架构图中所示，`kubectl`（`Kubernetes`提供的客户端工具，该工具内部就是对`Kubernetes API`的调用）是直接和`APIServer`交互的。

**scheduler**：`scheduler`的职责很明确，就是负责调度`pod`到合适的`Node`上。如果把`scheduler`看成一个黑匣子，那么它的输入是`pod`和由多个`Node`组成的列表，输出是`pod`和一个`Node`的绑定，即将这个`pod`部署到这个`Node`上。`Kubernetes`目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法。

**controller manager**：如果说`APIServer`做的是“前台”的工作的话，那`controller manager`就是负责“后台”的。每个资源一般都对应有一个控制器，而`controller manager`就是负责管理这些控制器的。比如我们通过`APIServer`创建一个`pod`，当这个`pod`创建成功后，`APIServer`的任务就算完成了。而后面保证`pod`的状态始终和我们预期的一样的重任就由`controller manager`去保证了。

**etcd**：`etcd`是一个高可用的键值存储系统，`Kubernetes`使用它来存储各个资源的状态，从而实现了`Restful`的`API`。

### 3.3.2 Node ###

每个`Node`节点主要由三个模块组成：`kubelet`、`kube-proxy`、`runtime`。

**runtime**：指的是容器运行环境，目前`Kubernetes`支持`docker`和`rkt`两种容器。

**kube-proxy**：该模块实现了`Kubernetes`中的服务发现和反向代理功能。反向代理方面：`kube-proxy`支持`TCP`和`UDP`连接转发，默认基于`Round Robin`算法将客户端流量转发到与`service`对应的一组后端`pod`。服务发现方面，`kube-proxy`使用`etcd`的`watch`机制，监控集群中`service`和`endpoint`对象数据的动态变化，并且维护一个`service`到`endpoint`的映射关系，从而保证了后端`pod`的`IP`变化不会对访问者造成影响。另外`kube-proxy`还支持`session affinity`。

**kubelet**：`Kubelet`是`Master`在每个`Node`节点上面的`agent`，是`Node`节点上面最重要的模块，它负责维护和管理该`Node`上面的所有容器，但是如果容器不是通过`Kubernetes`创建的，它并不会管理。本质上，它负责使`pod`得运行状态与期望的状态一致。

### 3.3.3 Pod ###

`pod`是`k8s`进行资源调度的最小单位，每个`pod`中运行着一个或多个密切相关的业务容器，这些业务容器共享这个`Pause`容器的`IP`和`Volume`，我们以这个不易死亡的`Pause`容器作为`pod`的根容器，以它的状态表示整个容器组的状态。一个`pod`一旦被创建就会放到`etcd`中存储，然后由`Master`调度到一个`Node`绑定，由这个`Node`上的`Kubelet`进行实例化。

每个`pod`会被分配一个单独的`pod IP`，`pod IP` \+ `ContainerPort`组成了一个`Endpoint`。

### 3.3.4 Service ###

`Service`其功能使应用暴露，`Pods`是有生命周期的，也有独立的`IP`地址，随着`Pods`的创建与销毁，一个必不可少的工作就是保证各个应用能够感知这种变化。这就要提到`Service`了，`Service`是`YAML`或`JSON`定义的由`Pods`通过某种策略的逻辑组合。更重要的是，`Pods`的独立`IP`需要通过`Service`暴露到网络中。

# 四、Kubectl命令 #

# 查看所有 pod 列表, -n 后跟 namespace, 查看指定的命名空间
    kubectl get pod
    kubectl get pod -n kube  
    
    
    # 查看 RC 和 service 列表， -o wide 查看详细信息
    kubectl get rc,svc
    kubectl get pod,svc -o wide  
    kubectl get pod <pod-name> -o yaml
    
    
    # 显示 Node 的详细信息
    kubectl describe node 192.168.0.212
    
    # 显示 Pod 的详细信息, 特别是查看 pod 无法创建的时候的日志
    kubectl describe pod <pod-name>
    eg:
    kubectl describe pod redis-master-tqds9
    
    # 根据 yaml 创建资源, apply 可以重复执行，create 不行
    kubectl create -f pod.yaml
    kubectl apply -f pod.yaml
    
    # 基于 pod.yaml 定义的名称删除 pod 
    kubectl delete -f pod.yaml 
    
    # 删除所有包含某个 label 的pod 和 service
    kubectl delete pod,svc -l name=<label-name>kubectl delete namespace xxx
    
    # 删除所有 Pod
    kubectl delete pod --all
    
    # 查看 endpoint 列表
    kubectl get endpoints
    kubectl get namespace
    
    # 执行 pod 的 date 命令
    kubectl exec <pod-name> -- date
    kubectl exec <pod-name> -- bash
    kubectl exec <pod-name> -- ping 10.24.51.9
    
    # 通过bash获得 pod 中某个容器的TTY，相当于登录容器
    kubectl exec -it <pod-name> -c <container-name> -- bash
    eg:
    kubectl exec -it redis-master-cln81 -- bash
    
    # 查看容器的日志
    kubectl logs <pod-name>
    kubectl logs -f <pod-name> # 实时查看日志
    # 容器日志输出到文件
       log_pod release-xxxx 10000 > xxxx.txt

[20210527100210977.png]: /images/20230208/c11e7fa940394b669c8cea8d2f4c4e04.png
[20200805150644600.png]: /images/20230208/763300ab2920456eb4804cbc32362c05.png