kubernetes介绍

  在使用kubenetes技术前，需要我们了解一下云原生（Cloud Native Computing Foundation，简称CNCF）的前世今生以及概念

一、云原生简介

官网：cncf.io

　　2004年开始，Google已在内部大规模地使用容器技术。

　　2008年，Google将 Cgroups合并进入了Linux内核。

　　2013年，Docker项目正式发布。

　　2014年，Kubernetes项目正式发布。

　　2015年，由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了CNCF(Cloud Native Computing Foundation)云原生计算基金会。 2017年，CNCF达到170个成员和14个基金项目；

　　2018年，CNCF成立三周年有了195个成员，19个基金会项目和11个孵化项目。

2022年，全球187国家、820+企业成员、130+项目、16万以上开发者。

二、云原生定义：

  云原生是一种提供了可应用于生产环境的方法论，方便企业快速运行应用程序，企业不需要将人效用于放在底层运行环境，而是主要聚焦在业务层功能开发，从而实现产品的快速交付、迭代及稳定性，从而整体降低成本支出并提高交付效率。

 

三、kubernetes基础概念

  Kubernetes最初源于谷歌内部的Borg，Borg是谷歌内部的大规模 集群管理系统，负责对谷歌内部很多核心服务的调度和管理,Borg的目的是让用户能够不必操心资源管理的问题，让他们专注于自己的核心业务，并且做到跨多个数据中心的资源利用率最大化。

  kubernetes官网：

  https://kubernetes.io/zh/

 

  kubernetes github开源项目：

  https://github.com/kubernetes/kubernetes #github

 

  Borg主要由BorgMaster、Borglet、borgcfg和Scheduler组成:

 

 

四、Kubernetes集群节点组成：

  1、主节点，它承载着Kubernetes控制和管理整个集群系统的控制面板

  2、工作节点，它们运行用户实际部署的应用

  集群节点组件：

 

五、控制面板

       控制面板用于控制集群并使它工作。它包含多个组件，组件可以运行在单个主节点或者通过副本分别部署在多个主节点以确保高可用性。这些组件是：

• Kubernetes API服务器，你和其他控制面板组件都要和它通信；Kubernetes API server 提供了k8s各类资源对象的增删改查及watch等HTTP Rest接口，这些对象包括pods、 services、replicationcontrollers等，API Server为REST操作提供服务，并为集群的共享状态提供前端，所有其他组 件都通过该前端进行交互。

  API服务组件官网介绍：

　　https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/

 

• RESTful API: 是REST风格的网络接口，REST描述的是在网络中client和server的一种交互形式 

   RESTful API github项目地址：

   https://github.com/Arachni/arachni/wiki/REST-API

 

• REST: 是一种软件架构风格，或者说是一种规范，其强调HTTP应当以资源为中心，并且规范了URI的风格,规范了HTTP请求动作。(GET/PUT/POST/DELETE/HEAD/OPTIONS)的使用,具有对应的语义。

 

• Scheculer，它调度你的应用（为应用的每个可部署组件分配一个工作节点）；负责介绍任务，选择合适的节点进行分配任务。

 

• Controller Manager，它执行集群级别的功能，如复制组件、持续跟组工作节点、处理节点失败等；维持副本期望数目。

 

• etcd，一个可靠的分布式数据存储，它能持久化存储集群配置。

  控制面板的组件持有并控制集群状态，但是它们不运行你的应用程序。这是由工作节点完成的。

 

六、逻辑结构：

 

七、k8s底层运行时（runtime流程）

  客户端请求api-server，api-server将数据写入etcd分部署数据库。

       pod的请求调度都是由api-server来调度controller-manager和scheduler。

  k8s v1.24版本之前使用dockershim调用dockerd，dockerd传递给containerd来执行runc，最后由runc来实际运行容器container。

  k8s v.1.24版本之后切分初三个分支来利用其他组件（cri、cri-dockerd、CRI-O）来调度使用pod。CRI是谷歌提出的方案来直接调用containerd。cri-dockerd是替换dockerd的另一种方案，使用dockerd来调用containerd。cri-o是红帽提出的一种方案，直接使用crio来直接调度使用pod。

八、工作节点

       工作节点是运行容器化应用的机器。高可用集群副本数据最好是奇数。运行、监控和管理应用服务的任务是由以下节点完成的：

• Docker、rtk或其他的容器类型；
• Kubelet，它与API服务器通信，并管理它所在节点的容器；直接跟容器引擎交互实现容器的生命周期管理。
• Kubernetes Service Proxy（kube-proxy），它负责组件之间的负载均衡网络流量。

 

九、kubernetes认证流程

       客户端连接kubernetes的api-server一般是https连接。经由api-server进行传递校验当前客户端使用的证书秘钥信息是否与config文件进行匹配。匹配通过后接受客户端请求在通过api-server调度其他组件进行处理实际的使用。

  

  kubernetes master节点下/root/.kube/config文件提供集群初始化的凭据信息。包括context、api-server地址、集群信息、kubenetes用户凭据和公钥信息

 

十、Kubernetes网络模型

  Kubernetes的网路模型假定了所有pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，kubernetes假定这个网络已经存在。而在私有云里搭建kubernetes集群，就不能假定这个网络存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问打通，然后运行kubernetes

  三种 IP 定义

   1、Node IP：Node节点的IP地址，即物理机(虚拟机)的IP地址。

   2、Pod IP：Pod的IP地址，即docker容器的IP地址，此为虚拟IP地址。

   3、Cluster IP：Service的IP地址，此为虚拟IP地址。

 

  三种 IP 的理解

  Node IP：是物理机的IP（或虚拟机IP）。每个Service都会在Node节点上开通一个端口，外部可以通过http://NodeIP:NodePort

      即可访问Service里的Pod提供的服务。

 

  Pod IP：是每个Pod的IP地址，Docker Engine根据docker网桥的IP地址段进行分配的，通常是一个虚拟的二层网络。

  同Service下的pod可以直接根据PodIP相互通信

      不同Service下的pod在集群间pod通信要借助于cluster ip

      pod和集群外通信，要借助于node ip

    

  Cluster IP: 是Service的IP地址，此为虚拟IP地址，外部网络无法ping通，只有k8s集群内部访问使用。

  Cluster IP仅仅作用于K8s Service这个对象，并由K8es管理和分配IP地址。ClusterIP无法被ping，他没有一个“实体网络对象”来响应。Cluster IP只能结合ServicePort组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于K8s集群这样一个封闭的空间。

在不同Service下的pod节点在集群间相互访问可以通过Cluster IP

 

  以上是kubernetes的基础概念介绍。如果对你有帮助或有建议疑问可以评论区留言！