K8s基础概念

阅读目录

• 一、资源与对象简述
• 二、资源种类

回到顶部

一、资源与对象简述

Kubernetes 中的所有内容都被抽象为“资源”，如 Pod、Service、Node 等都是资源。“对象”就是“资源”的实例，是持久化的实体。如某个具体的 Pod、某个具体的 Node。Kubernetes 使用这些实体去表示整个集群的状态。

对象的创建、删除、修改都是通过 “Kubernetes API”，也就是 “Api Server” 组件提供的 API 接口，这些是 RESTful 风格的 Api，与 k8s 的“万物皆对象”理念相符。命令行工具 “kubectl”，实际上也是调用 kubernetes api。

对象规约（Spec）和状态（Status）
每个Kubernetes对象包含两个嵌套的对象字段，它们负责管理对象的配置，他们分别是 “spec” 和 “status”
“spec” 是 “规约”、“规格” 的意思，spec 是必需的，它描述了对象的期望状态（Desired State）—— 希望对象所具有的特征。
status 描述了对象的 实际状态（Actual State） ，它是由 Kubernetes 系统提供和更新的。在任何时刻，Kubernetes 控制面一直努力地管理着对象的实际状态以与期望状态相匹配。

示例:

apiVersion: v1
kind: Pod
metadata:
    name: myapp-pod
    labels:
      app: myapp
spec:
    containers:
    - name: myapp-container
      image: busybox
      command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

除 “spec” 字段外，在创建一个Pod及Pod的控制器对象时，还要像上面模板所示一样，还要有这三个字段:
“apiVersion”——“创建该对象所使用的 Kubernetes API 的版本”；
“kind”——“想要创建的对象的类型”；
“metadata”——“帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace。”

 

二、对象的常用属性

 1.name和uid

2.namespace

在 k8s 中， namespace (命名空间) 也称为虚拟集群

k8s 集群搭建好后，会创建一个名为 "default" 的 namespace，当没有为资源明确指定 namespace 时，会默认分配该 namespace。kubernetes 的组件，分配的是名为 “kube-system” 的 namespace。

# 列出在命名空间中的资源
kubectl api-resources --namespaced=true
 
# 列出不在命名空间中的资源
kubectl api-resources --namespaced=false

3.label和selector

label 与 selector 配合，可以实现对象的“关联”，“Pod 控制器” 与 Pod 是相关联的 —— “Pod 控制器”依赖于 Pod，可以给 Pod 设置 label，然后给“控制器”设置对应的 selector，这就实现了对象的关联。

4.对象信息的获取

kubectl get <resource_type> --namespace=<namespace> 

• <resource_type> 就是资源的类别，可以是 pod、node 或其它所有类别的名称。这里可以输入资源的单数形式、复数形式，比如 “pod” 还可以写成 “pods”；对于稍微长一点的资源名，还可以使用缩写，比如 “service”，可以输入其缩写 “svc”。

• <namespace> <namespace>后面的 “=” 可有可无。namespace 是对象所在的 namespace，namespace 可以看做是对象的分组的组名，下文会简单介绍。k8s 集群初始化后会创建名为 “default” 的 namespace，在创建对象时如果没有指定 namespace，默认使用这个 namespace。如果在使用 “kubectl get” 时不指定 “--namespace”这个参数，获取的是 “default” namespace 下的对象。 另外 “--namespace” 可以简写成 “-n”，如果想获取所有 namespace 下的对象，则可以写成 “--all-namespaces”。

示例:

查看集群中存在的所有 namespace
kubectl get namespace
查看当前集群下所有存在的 node （ node 不在 namespace 中）
kubectl get node
查看当前存在的所有 pod
kubectl get pods --all-namespaces
查看“kube-system”下所有的service
kubectl get svc -n kube-system

5.查看对象的具体信息，需要用 “describe”

kubectl describe <resource_type> <object_name> --namespace=<namespace>

参数说明:

<resource_type> 跟上面一样，可以写单复数形式、简写。<namespace> 也是一样的，可以写成 “-n”，但有一点需要注意，不能写成 “--all-namespaces”，因为如果不同 namespace 有两个同名同类别的对象，那么就出现歧义了，“--all-namespaces” 对 “kubectl describe” 是没有意义的，所以不要这样写。

<object_name> 就是对象的名称，也就是 “kubectl get” 命令显示的结果。

示例:

获取名为 “kube-apiserver”，namespace 为 “kube-system” 的 pod 的信息
kubectl describe pod kube-apiserver -n kube-system
获取名为 “hello” 的 node 的信息
kubectl describe node hello

回到顶部

二、资源种类

1.Pod

　　最小的可部署的 Kubernetes 对象模型。Pod是不能被外网直接访问的，所以不要想着只要把应用部署到Pod就可以直接用，要想在外网访问Pod需要用到service

2.Pod控制器

2.1 ReplicationController 简写 “RC” 或 “RCS”

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

该文件描述了一个资源对象，它有4个字段，分别是 “apiVersion”、“kind”、“metadata”、“spec”。上面讲对象与“规约”时讲过，创建一个 Pod 及 Pod控制器 对象时，这四个字段是必不可少的。kind 说明这是一个 “ReplicationController” 类型的对象，metadata 说明对象名称是 “nginx”。spec 指定了这个对象的特征，关注 spec 这个字段:

template

在 spec 中 template 这个字段是必需的，其实这就是一个 Pod 的模板，只不过这个模板是嵌套进来的，不需要 kind 和 apiVersion 字段

replicas

replica就是“复制品”、“副本”的意思，“replicas: 3”就是开启三个 Pod 副本

selector

通过指定 ReplicationController 的 selector 和 Pod 的 “app: nginx” 标签，可以实现 ReplicationController 和 Pod 的绑定关系

2.2 ReplicaSet

简写 “RS”，是 “Replication Controller” 的升级版。和 “ReplicationController” 一样用于确保任何给定时间指定的Pod副本数量，并提供声明式更新等功能。
RC与RS唯一区别就是lable selectore支持不同，RS支持新的基于集合的标签，RC仅支持基于等式的标签。

2.3 Deployment

一个更高层次的API对象，他管理ReplicaSets和Pod，并提供声明式更新等功能。
官方建议使用Deployment管理ReplicaSets，而不是直接使用ReplicaSets，这就意味着可能永远不需要直接操作ReplicaSet对象。

2.4 StatefulSet

适合持久性的应用程序，有唯一的网络标识符（IP），持久存储，有序的部署、扩展、删除和滚动更新。

2.5 DaemonSet

一般是用来部署一些特殊应用的，譬如日志应用等有“守护”意义的应用

2.6 Job

一次性任务，运行完成后Pod销毁，不再重新启动新容器

2.7 CronJob

是在 Job 基础上加上了定时功能

3.Service

简写 “svc”.Pod不能直接提供给外网访问，而是应该使用service。Service就是把Pod暴露出来提供服务，Service才是真正的“服务”，它的中文名就叫“服务”.

Service是一个应用服务的抽象，定义了Pod逻辑集合和访问这个Pod集合的策略。Service代理Pod集合，对外表现为一个访问入口，访问该入口的请求将经过负载均衡，转发到后端Pod中的容器

Service是如何保持这种与特定Pod绑定的关系的呢？那就是“Label”和“Label Selector”，可以给Pod分配特定的Label，然后配置Service，通过“Lable Selector”选择具有这些特定“Label”的Pod来接受请求、提供服务。

默认情况下，在创建service对象的时候，如果不指定service的访问方式，service被配置为ClusterIp模式，在该模式下，只有集群内部的网络才能访问到该service，要想真正的实现外网访问service，需要把service访问方式配置为NodePort或其它。