Kubernetes，简称K8s，是一个开源系统，用于自动化部署、扩展和管理容器化应用程序。它提供了基本机制来部署、维护和扩展应用程序，支持跨多个主机的容器应用。K8s是Go语言开发的，建立在Docker之上，可以看作是Docker的上层架构。它的主要功能包括应用部署、维护、扩展，集群管理、安全防护、准入机制、多应用支撑、服务注册与发现、智能负载均衡、故障发现与自我修复、服务滚动升级、在线扩容、资源配额管理等。K8s通过容器的方式来管理应用程序，使得容器集群能够运行在用户期望的状态，并解决容器跨机器通信的问题。

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

容器技术是k8s中最关键的技术，通过容器技术可以将一台实体服务器资源虚拟化为多个隔离的容器，容器之间有较高的隔离级别，可像一台独立的服务器般部署程序并对外提供服务。简单来说，可以把容器简单视为一个特殊的进程，该进程与其他进程相隔离，在自己的命名空间下使用网络接口和文件，并且该进程只能使用硬件的部分资源。容器技术的基础是linux命令空间和cgroups，其中：

（1）容器的隔离是基于linux命令空间来实现的，命名空间提供了一种内核级别隔离系统资源的方法，通过将系统的全局资源放在不同的命名空间中，来实现资源隔离的目的。不同命名空间的进程，可以享有一份独立的系统资源。

（2）硬件资源的限制是通过cgroups实现的，cgroups是一个linux内核功能，它被用来限制一个进程或者一组进程的资源（cpu、内存、带宽等）使用，被限制的进程不能过分使用为其他进程保留的资源。

容器技术与微服务概念相得映彰，微服务概念强调将一个大的系统拆分为若干微服务，每个微服务实现系统的特定功能，通过这个方式来减少系统的耦合。一般而言，一个微服务所需的系统资源并不需要很多，使用一个容器来部署一个微服务便成了一件很合适的事情，毕竟容器创建简单、资源可控，隔离性好、扩容方便。

Kubernetes中的CRD（Custom Resource Definition，自定义资源定义）允许用户扩展API服务器以支持新的自定义资源。使用CRD，用户可以定义自己的Kubernetes API资源类型，并在Kubernetes集群中创建、管理和操作这些自定义资源。

CRD的创建和使用通常涉及以下几个步骤：

创建CRD定义：创建一个CRD定义文件，例如customresource.yaml，其中包含自定义资源的结构和属性。CRD定义文件使用Kubernetes API对象的规范来定义自定义资源的模式、版本和行为。
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mycustomresources.samples.example.com
spec:
  group: samples.example.com
  versions:
    - name: v1
      served: true
      storage: true
  scope: Namespaced
  names:
    plural: mycustomresources
    singular: mycustomresource
    shortNames:
    - mcr

kube-scheduler调度过程和原理
kube-scheduler是Kubernetes集群中的一个核心组件，负责根据预定义的调度策略将Pod分配到集群中的合适节点上运行。下面是kube-scheduler的调度过程和原理的简要描述：

获取未调度的Pod：kube-scheduler会定期从Kubernetes API服务器获取所有未调度的Pod的列表。

筛选：kube-scheduler会对未调度的Pod进行筛选，剔除不符合调度要求的Pod。这包括检查系统保留节点、Pod的亲和性和反亲和性要求（如NodeSelector、NodeAffinity等）、污点（Taints）等。只有符合筛选条件的Pod才会进入下一步的调度过程。

评分：对于剩下的可调度Pod，kube-scheduler会对每个节点进行评分，根据一系列算法为每个节点计算出一个分数。评分算法可以根据用户自定义的策略进行配置，常见的因素包括节点资源利用率、节点的可用性、亲和性和反亲和性等。

选择节点：根据评分结果，kube-scheduler会选择具有最高分数的节点来运行Pod。如果多个节点具有相同的最高分数，kube-scheduler会根据预定义的调度策略（如最少负载、随机选择等）来决定最终的调度结果。

更新调度结果：获取到调度结果后，kube-scheduler将更新Pod的调度信息，并将其更新到Kubernetes API服务器中。这样其他组件（如kubelet）就会根据调度结果来将Pod放置到相应的节点上运行。

监控和重调度：kube-scheduler会定期监控已调度的Pod以确保其正常运行。如果发现某个节点不可用或Pod处于非运行状态，kube-scheduler将重新进行调度，将Pod迁移到其他合适的节点上。

kubernetes内部需要5套证书，手动创建或者自动生成，分别为：
1. etcd内部通信需要一套ca和对应证书。
2. etcd与外部通信也要有一套ca和对应证书。
3. APIserver间通信需要一套证书。
4. apiserver与node间通信需要一套证书。
5. node和pod间通信需要一套ca证书。
目前来说还不能实现把所有的业务都迁到kubernetes上，如存储，因为这个是有状态应用，出现错误排查很麻烦，所以目前kubernetes主要是运行无状态应用。
所以一般而言，负载均衡器运行在kubernetes之外，nginx或者tomcat这种无状态的应用运行于kubernetes集群内部，而数据库如mysql，zabbix，zoopkeeper等有状态的，一般运行于kubernetes外部，通过网络连接，实现kubernetes集群的pod调用这些外部的有状态应用。

Kubernetes 引入 Pod 主要基于下面两个目的：
- 可管理性
有些容器天生就是需要紧密联系, 一起工作。Pod 提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes 以 Pod 为最小单位进行调度、扩展、共享资源、管理生命周期。
- 通信和资源共享
Pod 中的所有容器使用同一个网络 namespace，即相同的 IP 地址和 Port 空间。它们可以直接用 localhost 通信。同样的，这些容器可以共享存储，当 Kubernetes 挂载 volume 到 Pod，本质上是将 volume 挂载到 Pod 中的每一个容器。