Kubernetes 组件

CNCF云原生的定义：

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

云原生技术栈：

容器化: 以docker、containerd为代表的容器运行技术。

服务网格: 比如Service Mesh等

微服务: 在微服务体系结构中，一个项目是由多个松耦合且可独立部署的较小组件或服务组成。
不可变基础设施:不可变基础设施可以理解为一个应用运行所需要的基本运行需求，不可变最基本的就是指运行服务的服务器在完成部署后，就不在进行更改，比如镜像等。

声明式APl: 描述应用程序的运行状态，并且由系统来决定如何来创建这个环境，例如声明一个pod，会有k8s执行创建并维持副本。

Kubernetes 简介：

Kubernetes最初源于谷歌内部的Borg，Borg是谷歌内部的大规模集群管理系统，负责对谷歌内部很多核心服务的调度和管理,Borg的目的是让用户能够不必操心资源管理的问题，让他们专注于自己的核心业务，并且做到跨多个数据中心的资源利用率最大化。
Borg主要由BorgMaster、Borglet、borgcfg和Scheduler组成:
https://kubernetes.io/zh/ #官网
https://github.com/kubernetes/kubernetes #github

Kuberntes组件简介：

kube-apiserver:
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/
Kubernetes APl server 提供了k8s各类资源对象的增删改查及watch等HTTP Rest接口，这些对象包括pods.services、replicationcontrolers等，API Server为REST操作提供服务，并为集群的共享状态提供前端，所有其他组件都通过该前端进行交互。
RESTful API:
是REST风格的网络接口，REST描述的是在网络中client和server的一种交互形式
REST:是一种软件架构风格，或者说是一种规范，其强调HTTP应当以资源为中心，并且规范了UI的风格,规范了HTTP请求动作(GET/PUT/POST/DELETE/HEAD/OPTIONS)的使用,具有对应的语义，
https://github.com/Arachni/arachni/wiki/REST-API

Kubernetes逻辑架构：

运行时简介：

0Cl(Open Container nitiative): 2015年Google、 docker、Redhat、IBM共同成立，定义了运行标准和镜像标准，

CRI(Container Runtime lnterface): 2016 年12月Kubernetes 发布 CRI(客器运行时接口)可以支持rkt等不同的运行时

CRI-O: 由redhat发起并开源，用于替代docker成为kubernetes的运行时，2016年开发,2019年4月8号进入CNCF孵化。

　　unix:///var/run/dockershim.sock( k8s version ≤1.23 default)　　unix:///var/run/docker.sock

　　unix:///run/containerd/containerd.sock　　unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock

运行时简介：

Kubernetes管理认证流程：

Kubernetes API Server简介：

该端口默认值为6443，可通过启动参数“--secure-port”的值来修改默认值

默认IP地址为非本地 (Non-Localhost) 网络端口，通过启动参数“--bind-address”设置该值

该端口用于接收客户端、dashboard等外部HTTPS请求,

用于基于Tocken文件或客户端证书及HTTP Base的认证

用于基于策略的授权

Kubernetes API 测试

kubernetes API测试:
># curl -cacert /etc/kubernetes/ssl/ca.pem -H "Authorization: Bearer $/TOKEN) https://172.16.0.4:6443# curl 127.0.0.1:6443/ #返回所有的API列表
# curl 127.0.0.1:6443/apis #分组API
# curl 127.0.0.1:6443/api/v1 #带具体版本号的API
# curl 127.0.0.1:6443/version #API版本信息
# curl 127.0.0.1:6443/healthz/etcd #与etcd的心跳监测
# curl 127.0.0.1:6443/apis/autoscaling/v1 #API的详细信息
# curl 127.0.0.1:6443/metrics #指标数据
API的版本:
Alpha: 预览版，可能包含bug或错误，后期版本会修复且不兼容之前的版本，不建议使用。Beta: 测试版,如storage.k8s.io/v1betal,该版本可能存在不稳定或者潜在的bug，不建议生产使用v1: 稳定版，如apps/v1，经过验证的stable版本，可以生产环境使用

Kubernetes组件简介：

kube-scheduler:

https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-scheduler
Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。调度器之后对所有合法的节点进行排序，将 Pod 绑定到一个合适的节点。在同一个集群中可以使用多个不同的调度器；kube-scheduler 是其参考实现。

通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最适合的Node，并将信息写人etcd中
node节点上的kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应的Pod清单下载Image，并启动容器.
策略:
LeastRequestedPriority：优先从备选节点列表中选择资源消耗最小的节点 (CPU+内存)

CalculateNodel abelPriority：优先选择含有指定Label的节点
BalancedResourceAllocation：优先从备选节点列表中选择各项资源使用率最均衡的节点

kube-controller-manager:

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

>kube-controller-manager: Controller Manager还包括一些子控制器(副本控制器、节点控制器、命名空间控制器和服务账号控制器等)，控制器作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点(Endpoint) 、命名空间(Namespace) 、服务账号 (ServiceAccount) 、资源定额ResourceQuota) 的管理当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群中的pod副本始终处于预期的工作状态。
>controller-manager控制器每间隔5秒检查一次节点的状态

>如果controller-manager控制器没有收到自节点的心跳，则将该node节点被标记为不可达

>controller-manager将在标记为无法访问之前等待40秒

>如果该node节点被标记为无法访问后5分钟还没有恢复，controller-manager会删除当前node节点的所有pod并在其它可用节点重建这些pod.

>pod 高可用机制:node monitor period:

>节点监视周期,5snode monitor grace period:

>节点监视器宽限期,40spod eviction timeout:

>pod驱逐超时时间,5m

Kube-proxy:

https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-proxy/
>kube-proxy: Kubernetes 网络代理运行在 node 上，它反映了 node 上 Kubernetes API 中定义的服务，并可以通过一组后端进行简单的 TCP、UDP 和 SCTP 流转发或者在一组后端进行循环 TCP、UDP 和 SCTP 转发，用户必须使用 apiserver API创建一个服务来配置代理，其实就是kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务访问.
>kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化，再通过管理 IPtables或者IPVS规则来实现网络的转发。
>Kube-Proxy 不同的版本可支持三种工作模式:
　　> UserSpace: k8s v1.1之前使用,k8s 1.2及以后就已经淘汰
　　> IPtables : k8s 1.1版本开始支持，1.2开始为默认
　　>IPVS: k8s 1.9引人到1.11为正式版本，需要安装ipvsadm、ipset 工具包和加载 ip_vs 内核模块

>有Node、pod、service网络。

>IPVS 相对 IPtables 效率会更高一些，使用 IPVS 模式需要在运行 Kube-Proxy 的节点上安装 ipvsadm、ipset 工具包和加载 ip_vs 内核模块，当 Kube-Proxy 以 IPVS 代理模式启动时，Kube-Proxy 将验证节点上是否安装了IPVS模块，如果未安装，则 Kube-Proxy 将回退到 IPtables 代理模式。
>使用IPVS模式，Kube-Proxy会监视Kubernetes Service对象和Endpoints，调用宿主机内核Netlink接口以相应地创建IPVS规则并定期与Kuberetes Service对象 Endpoints对象同IPVS规则，以确保IPVS状态与期望一致，访问服各时，流量将被重定向到其中一个后端 POd.PVS使用哈希表作为底层数据结构并在内核空间中工作。这意味着IPVS可以更快地重定向流量，并且在同步代理规则时具有更好的性能，此外，IPVS 为负载均衡算法提供了更多选项，例如: rr (轮询调度)、Ic(最小连接数)、dh (目标哈希)、sh (源哈希)、sed(最短期望延迟)、nq（不排队调度)等。

配置使用IPVS及指定调度算法:

https://kubernetes.io/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1/#ClientConnectionConfiguration

# cat /var/lib/kube-proxy/kube-proxy-config.yaml
kind: KubeProxyConfiguration
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 172.31.7.111
clientConnection:
  kubeconfig:"/etc/kubernetes/kube-proxy.kubeconfigclusterCIDR:"10.100.0.0/16"conntrack:
clusterCIDR:"10.100.0.0/16"
  maxPerCore: 32768
  min: 131072
  tcpCloseWaitTimeout: 1h0mOs
  tcpEstablishedTimeout: 24h0m0s
healthzBindAddress: 172.31.7.111:10256
hostnameOverride:"172.31.7.111"
metricsBindAddress: 172.31.7.111:10249
mode:"ipvs”#指定使用ipvs及调度算法
ipvs:
   scheduler: sh

开启会话保持：

#cat nginx-service.yaml
kind: Service
apiVersion: v1
metadata:
  labels:
    app: magedu-nginx-service-label
  name: magedu-nginx-service
  namespace: magedus
spec:
  type: NodePort
  ports:
    - name: http
    port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 30004
  selector:
    app: nginx
  sessionAffinity: ClientlP
  sessionAffinityConfig:
    clientlP:
      timeoutSeconds: 1800

Kubelet:

https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet
kubelet是运行在每个worker节点的代理组件，它会监视已分配给节点的pod，具体功能如下

>向master汇报node节点的状态信息
>接受指令并在Pod中创建 docker容器
>准备Pod所需的数据卷
>返回pod的运行状态
>在node节点执行容器健康检查

kubectl: https://kubernetes.io/zh/docs/reference/kubectl/kubectl/
是一个通过命令行对kubernetes集群进行管理的客户端工具。

ETCD

https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/

>etcd 是CoreOS公司开发目前是Kubernetes默认使用的key-value数据存储系统，用于保存kubernetes的所有集群数据，etcd支持分布式集群功能，生产环境使用时需要为etcd数据提供定期备份机制。
#官网:https://etcd.io/
#github:https://github.com/etcd-io/etcd

CoreDNS

https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/

>DNS负责为整个集群提供DNS服务，从而实现服务之间的访问

　　coredns
　　kube-dns: 1.18
　　sky-dns

Dashboard:

>Dashboard是基于网页的Kuberetes用户界面，可以使用Dashboard获取运行在集群中的应用的概览信息，也可以创建或者修改Kubernetes资源(如 Deployment, Job DaemonSet 等等)，也可以对Deployment实现弹性伸缩
发起滚动升级、重启 Pod 或者使用向导创建新的应用。

posted @ 2023-02-24 10:28 しみずよしだ阅读(24) 评论(0) 编辑收藏举报

刷新页面返回顶部

birkhoffxia

Kubernetes 组件

CNCF云原生的定义：

云原生技术栈：

Kubernetes 简介：

Kuberntes组件简介：

Kubernetes逻辑架构：

运行时简介：

运行时简介：

Kubernetes管理认证流程：

Kubernetes API Server简介：

Kubernetes API 测试

Kubernetes组件简介：

kube-scheduler:

kube-controller-manager:

Kube-proxy:

Kubelet:

ETCD

CoreDNS

Dashboard:

公告