k8s 详解

最新推荐文章于 2024-09-27 16:20:44 发布

飞001

最新推荐文章于 2024-09-27 16:20:44 发布

阅读量295

点赞数

分类专栏： k8s和docker 文章标签： kubernetes docker 容器

本文链接：https://blog.csdn.net/qq_33868316/article/details/128847680

版权

k8s和docker 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1.pod是什么，为什么需要pod？

容器的本质是进程，Kubernetes 本质就是操作系统。pod只是一个逻辑概念，也就是说Kubernetes 真正处理的，还是宿主机操作系统上 Linux 容器的 Namespace 和 Cgroups，而并不存在一个所谓的 Pod 的边界或者隔离环境。Pod其实是一组共享了某些资源的容器。具体的说：Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。

2.k8s控制器有哪些？

ReplicationController 和 ReplicaSet

ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收；在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector；

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括；

定义 Deployment 来创建 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment

DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod 使用 DaemonSet 的一些典型用法：

运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph
在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、 New Relic 代理，或 Ganglia gmond
特性：服务是无状态的。服务必须是守护进程(如果一个进程永远都是以后台方式启动，并且不能受到Shell退出影响而退出，一个正统的做法是将其创建为守护进程（daemon）。守护进程值得是系统长期运行的后台进程，类似Windows服务。)。

StatefulSet

StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用场景包括：

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有 Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到 N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除（即从N-1到0）

Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

3.Pod 里的容器可以共享哪些 Namespace？

namespace是对内核内的全局资源的封装，使得每一个namespace中都有一份独立的资源，因此不同进程在各自的namespace中对同一份资源进行操作互不影响。

Mount Namespace：通过隔离文件系统挂载点对隔离文件系统提供支持，隔离后，不同mount namespace中的文件结构发生变化也互不影响。

Network Namespaces：主要提供了关于网络资源的隔离，包括网络设备、IPv4、IPv6协议栈、IP路由表、防火墙、/proc/net目录、/sys/class/net目录、套接字（socket）等。一个物理的网络设备最多存在于一个network namespace中，可以通过创建veth pair在不同的network namespace间创建通道，以达到通信目的。

User Namespaces：主要隔离了安全相关的标识符（identifier）和属性（attribute），包括用户ID、用户组ID、root目录、key（密钥）以及特殊权限。

UTS Namespaces：提供主机名和域名的隔离，这样每个docker容器就可以拥有独立的主机名和域名，在网络上可以被视作一个独立的节点，而非宿主机上的进程了。

PID Namespace： Linux内核为所有的PID namespace维护了一个树状结构，最顶层的是系统初始时创建的，被称为root namespace。它创建的新的PID namespace称为child namespace（树的子节点），而原先的PID namespace就是新创建的PID namespace的parent namespace（树的父节点）。通过这种方式，不同的PID namespace会形成一个层级体系。所属的父节点可以看到子节点中的进程，并可以通过信号等方式对子节点中的进程产生影响，反过来，子节点却不能看到父节点PID namespace中的任何内容。

IPC Namespaces：进程间通信（Inter-Process Cmmunication,IPC）涉及的IPC资源包括常见的信号量、消息队列和共享内存。申请IPC资源就申请了一个全局唯一的32位ID，所以IPC namespace中实际上包含系统IPC标识符以及实现POSIX消息队列的文件系统。在同一个IPC namespace下的进程彼此可见。

4.docker和传统linux有啥区别？

5.k8s基础组件有哪些？

Master 组件

kube-apiserver :Kubernetes API 集群的统一入口，各组件的协调者，以RESTful API提供接口方式，所有的对象资源的增删改查和监听操作都交给APIServer处理后再提交给etcd数据库做持久化存储。

Kube-controller-manager：处理集群中常规后台任务，一个资源对应一个控制器，而controllerManager就是负责处理这些控制器的

kube-scheduler:根据调度算法为新创建的pod选择一个Node节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同的节点上

etcd:分布式键值存储系统，用于保存集群状态数据，比如Pod，Service等对象信息

Node组件

kubelet:kubelet 是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器，Pod挂载数据卷，下载secret，获取容器和节点状态等工作，kubelet 将每个Pod转换成一组容器

kube-proxy:在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。实现让Pod节点（一个或者多个容器）对外提供服务。

6.可以讲讲sidecar 的设计模式？

7.cgroup 中的 cpu 有哪几种限制方式。k8s 是如何使用实现 request 和 limit 的。

8.k8s滚动升级。

对于多实例服务，滚动更新采用对各个实例逐批次进行单独更新而非同一时刻对所有实例进行全部更新，来达到不中断服务的更新升级方式。

对于Kubernetes集群来说，一个service可能有多个pod，滚动升级（Rolling update）就是指每次更新部分Pod，而不是在同一时刻将该Service下面的所有Pod shutdown，然后去更新（例如replace --force方案），逐个更新可以避免将业务中断，（但是也可能带来数据不一致的问题，本文就不过多讨论了）。

spec:
  minReadySeconds: 5
  strategy:
      type: RollingUpdate
      rollingUpdate:
         maxSurge: 1
         maxUnavailable: 1

9.cgroups资源限制

cgroups是Linux内核提供的一种机制，这种机制可以根据需求把一系列系统任务及其子任务整合（或分隔）到按资源划分等级的不同组内，从而为系统资源管理提供一个统一的框架。

本质上来说，cgroups是内核附加在程序上的一系列钩子（hook)，通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。

cgroups的作用

资源限制：cgroups可以对任务使用的资源总额进行限制，如任务使用资源超出配额就会发出OOM（out of memory)的提示。
优先级分配：通过分配的CPU时间片数量及磁盘IO带宽大小控制任务运行的优先级。
资源统计：cgroups可以统计系统的资源使用量，如CPU使用时长、内存用量等。
任务控制：cgroups可以对任务执行挂起、恢复等操作。

10.谈谈Service与Ingress

11.容器持久化存储

PersistentVolume（PV）是集群之中的一块网络存储。跟 Node 一样，也是集群的资源。PV 跟 Volume (卷) 类似，不过会有独立于 Pod 的生命周期。这一 API 对象包含了存储的实现细节，例如 NFS、iSCSI 或者其他的云提供商的存储系统。

PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。

PersistentVolumeClaim (PVC) 是用户的一个请求。他跟 Pod 类似。Pod 消费 Node 的资源，PVCs 消费 PV 的资源。Pod 能够申请特定的资源（CPU 和内存）；Claim 能够请求特定的尺寸和访问模式（例如可以加载一个读写，以及多个只读实例）

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。

PV 和 PVC 的生命周期：PV 是集群的资源。PVC 是对这一资源的请求，也是对资源的所有权的检验。PV 和 PVC 之间的互动遵循如下的生命周期。