K8s基本的概念及资源总结

jazon@

已于 2022-05-29 10:33:28 修改

阅读量5.8k

点赞数

分类专栏：杂文章标签： kubernetes

于 2020-09-06 20:27:39 首次发布

本文链接：https://blog.csdn.net/Xjzzon/article/details/108436122

版权

杂专栏收录该内容

10 篇文章 0 订阅

订阅专栏

Master

集群的管理和控制，执行kebernetes控制命令。内部进程有：Kubernetes API Server是集群控制的唯一入口,Kubernetes Controller Manager自动化控制中心，Kubernetes Scheduler负责 Pod的调度，etcd服务存储资源对象数据。

Node

负责实际运行负载(容器)，内部进程有:kubelet负责pod对应的容器的创建与启停，与master紧密合作，将此Node作为集群一个成员管理起来;kube-proxy负责Kubernetes Service的通信与负载均衡机制;docker。常用Node相关命令:kubectl get nodes。kubectl describe node nodeName。

Pod

在这里插入图片描述

以Pause代表Pod的生存状态，每个Pod共享IP及Volume。在Kubernetes中Pod之间可以相互通信。
定义一个Redis的Pod

    apiVersion: v1
    kind: Pod
    metadata:
      name: tb-redis // Pod名称
      labels:
        app: tb-redis // Pod的标签
    spec:
      containers:
        - name: server // Pod里的容器名为server
          imagePullPolicy: IfNotPresent
          image: redis:4.0  //用的redis:4.0镜像
          ports:
            - containerPort: 6379 //在Pod的6379上启动此容器进程，PodIp+port就可以定位到这个容器
          resources:     //限定能使用的资源
            requests:
              memory: "64Mi"
              cpu: "259m"
            limits:
              memory: "128Mi"
              cpu: "500m"
          volumeMounts:
            - mountPath: /data
              name: redis-data
      volumes:
        - name: redis-data
          emptyDir: {}
      restartPolicy: Always

在这里插入图片描述

Label

是一个key=value的键值对，Label可以附加到各种资源对象上，如Node,Pod等。给资源对象打了标签，随后可以通过Label Selector查询和筛选拥有某些Label的资源对象。Label在kubernetes中的应用:kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本数量。kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表。kube-scheduler进程可以实现Pod"定向调度"特性。

apiVersion: v1
kind: ReplicationController
metadata:
  name: myweb
spec:
  replicas: 1
  selector: //标签选择器
    app: myweb
  template: 
    ...

Replication Controller

作用是声明某种Pod的副本数量在任意时刻都符合某个预期值，包含三个部分:Pod期待的副本数，用于筛选目标Pod的Label Selector，当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板。kubectl scale rc redis-slave --replicas=3命令可用于动态伸缩。

Deployment

可以看作是RC的一次升级，可以随时知道Pod的部署进度。kubectl create -f tomcat-deployment.yaml可以创建Deployment。kubectl get deployments可以知道Deployment的信息。

Horizontal PodAutoscaler

虽然kubectl scale可以实现扩容，但是不能自动。HP可以实现自动扩容。

apiVersion autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    kind: Deployment
    name: php-apache
  targetCPUUtilizationPercentage: 90  //

StatefulSet

一些服务是由状态的，而RC、Deployment等式面向无状态的。StatefulSet里的每个Pod都有为稳定、唯一的网络标识，可以用来发现集群内其他的成员。StatefulSet控制的Pod副本的启停是受控制的。StatefulSet里的Pod采用稳定的持久化存储券，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储券。

Service

Service定义了一个服务的访问入口地址，前端通过地址访问到该Node背后的一组由Pod组成的集群来提供服务，kube-proxy进程其实是一个智能的软件负载均衡器，它负责将对Service的请求转发到后端的某个Pod实例上，并在内部实现服务的负载均衡及会话保持。每个Service都有一个Cluster IP,J即使Pod的ip发生变化，Service IP并不会变化，所以只要用Service的Name与Serivice IP地址做一个DNS域名映射，就可以实现服务发现。但是Service本身的负载均衡问题没解决，如果有多个Service，那么按理是有一个负载均衡器转发到各个Service上，而现在是单独NodeIp+NodePort访问Service。比如一个系统有多个service,如 device, portal, mall等多个servcie，需要一个负载均衡器如nginx，根据url将请求转发到servcie中。

Volume

Volume是Pod中能够被多个容器访问的共享目录，定义在Pod上，被Pod里的多个容器挂载到具体目录下。在Pod上声明一个Volume，然后再容器里引用该Volume并mount到容器里的某个目录。

template:
  metadata:
    labels:
      app: app-demo
      tier: frontend
  spec:
    volumes:
       name: datavol       // 声明一个名为datavol的volumes
       emptyDir: {}
    containers:
       name: tomcat-demo
       image: tomcat
       volumeMounts:       // 挂载到volumes
         mountPath: /mydata-data
         name: datavol

emptyDir，Kubernets将自动在宿主机上分配一个目录，Pod从Node移除时，emptyDir中的数据也会被移除。hostPath可以指定宿主机的文件或目录，会一直保存着。还有一些其它类型的Volume，如NFS等。

Persistent Volume

“网络存储”是相对于"计算资源"而存在的一种实体资源，之前的Volume是定义在Pod上的，属于"“计算资源”。PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  accessMode:
    - ReadWriteOnce
  nfs:
    path: /somepath
    server: 172.17.0.2