k8s学习-基础操作1

k8s学习-基础操作1

K8S对象

Kubernetes对象指的是Kubernetes系统的持久化实体，所有这些对象合起来，代表了你集群的实际情况。常规的应用里，我们把应用程序的数据存储在数据库中，Kubernetes将其数据以Kubernetes对象的形式通过 api server存储在 etcd 中。具体来说，这些数据（Kubernetes对象）描述了：

集群中运行了哪些容器化应用程序（以及在哪个节点上运行）集群中对应用程序可用的资源应用程序相关的策略定义，例如，重启策略、升级策略、容错策略其他Kubernetes管理应用程序时所需要的信息

一个Kubernetes对象代表着用户的一个意图（a record of intent），一旦您创建了一个Kubernetes对象，Kubernetes将持续工作，以尽量实现此用户的意图。创建一个 Kubernetes对象，就是告诉Kubernetes，您需要的集群中的工作负载是什么（集群的 目标状态）。

操作 Kubernetes 对象（创建、修改、删除）的方法主要有：

kubectl 命令行工具kuboard 图形界面工具

kubectl、kuboard 最终都通过调用 kubernetes API (opens new window)来实现对 Kubernetes 对象的操作

对象的spec和status

每一个 Kubernetes 对象都包含了两个重要的字段：

spec 必须由您来提供，描述了您对该对象所期望的目标状态status 只能由 Kubernetes 系统来修改，描述了该对象在 Kubernetes 系统中的实际状态

Kubernetes通过对应的控制器，不断地使实际状态趋向于您期望的目标状态。

例如，一个 Kubernetes Deployment 对象可以代表一个应用程序在集群中的运行状态。当您创建 Deployment 对象时，您可以通过 Deployment 的 spec 字段指定需要运行应用程序副本数（假设为3）。Kubernetes 从 Deployment 的 spec 中读取这些信息，并为您创建指定容器化应用程序的 3 个副本，再将实际的状态更新到 Deployment 的 status 字段。Kubernetes 系统将不断地比较 实际状态 staus 和 目标状态 spec 之间的差异，并根据差异做出对应的调整。例如，如果任何一个副本运行失败了，Kubernetes 将启动一个新的副本，以替代失败的副本。

描述k8s对象

在 Kubernetes 中创建一个对象时，您必须提供

该对象的 spec 字段，通过该字段描述您期望的目标状态该对象的一些基本信息，例如名字

如果使用 kubectl 创建对象，您必须编写 .yaml 格式的文件。

以下是kubectl可以使用使用的.yaml文件

apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: selector: matchLabels: app: nginx replicas: 2 # 运行 2 个容器化应用程序副本 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

以下是相关操作命令

kubectl apply -f #创建deployment对象kubectl delete -f #删除

必填字段

在上述的 .yaml 文件中，如下字段是必须填写的：

apiVersion用来创建对象时所使用的Kubernetes API版本kind被创建对象的类型metadata用于唯一确定该对象的元数据：包括name​ 和namespace​，如果namespace​ 为空，则默认值为defaultspec描述您对该对象的期望状态

不同类型的 Kubernetes，其 spec​ 对象的格式不同（含有不同的内嵌字段），通过 API 手册 (opens new window)可以查看 Kubernetes 对象的字段和描述。

管理k8s对象

管理方式

命令行

当使用指令性的命令行（imperative commands）时，用户通过向 kubectl​ 命令提供参数的方式，直接操作集群中的 Kubernetes 对象。此时，用户无需编写或修改 .yaml 文件。

这是在 Kubernetes 集群中执行一次性任务的一个简便的办法。由于这种方式直接修改 Kubernetes 对象，也就无法提供历史配置查看的功能。

示例

kubectl run nginx --image nginx #部署deployment对象kubectl create deployment nginx --image nginx # 格式二

优缺点

与编写.yaml文件进行配置的方式相比，优点

命令简单，容易记忆只需要一个步骤，就可以对集群执行变更

缺点

无法进行review管理不提供日志审计没有创建新对象的模板

指令性对象配置

使用指令性的对象配置（imperative object configuration）时，需要向 kubectl 命令指定具体的操作（create,replace,apply,delete等），可选参数以及至少一个配置文件的名字。配置文件中必须包括一个完整的对象的定义，可以是 yaml 格式，也可以是 json 格式。

示例：

kubectl create -f nginx.yaml #通过配置文件创建对象kubectl delete -f nginx.yaml -f redis.yaml #删除两个配置文件中的对象kubectl replace -f nginx.yaml #使用配置文件中的对象定义，替换k8s应用的对象

与指令性命令行相比的优点：

对象配置文件可以存储在源代码管理系统中，例如 git对象配置文件可以整合进团队的变更管理流程，并进行审计和复核对象配置文件可以作为一个模板，直接用来创建新的对象

与指令性命令行相比的缺点：

需要理解对象配置文件的基本格式需要额外编写 yaml 文件

指令性的对象配置更简单更易于理解指令性的对象配置更成熟

指令性的对象配置基于文件进行工作，而不是目录如果直接更新 Kubernetes 中对象，最好也同时修改配置文件，否则在下一次替换时，这些更新将丢失

示例

处理 configs​ 目录中所有配置文件中的Kubernetes对象，根据情况创建对象、或更新Kubernetes中已经存在的对象。可以先执行 diff​ 指令查看具体的变更，然后执行 apply 指令执行变更：

kubectl diff -f configs/kubectl apply -f configs/kubectl diff -R -f configs/kubectl apply -R -f configs/

与指令性的对象配置相比，优点有：

缺点：

名称

Kubernetes REST API 中，所有的对象都是通过 ​​name​​​ 和 ​​UID​​ 唯一性确定。

Names

可以通过 namespace + name 唯一性地确定一个 RESTFUL 对象，例如：

/api/v1/namespaces/{namespace}/pods/{name} 参考 名称空间 同一个名称空间下，同一个类型的对象，可以通过 name 唯一性确定。如果删除该对象之后，可以再重新创建一个同名对象。

下面是三种广泛使用的资源名称的限制类型：

DNS Subdomain NamesDNS Label NamesPath Segment Names

#示例#下面的配置文件定义了一个name为nginx-demo的pod,该pod包含一个name为nginx的容器apiVersion: v1kind: Podmetadata: name: nginx-demospec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80

UIDs

UID 是由 Kubernetes 系统生成的，唯一标识某个 Kubernetes 对象的字符串。

Kubernetes集群中，每创建一个对象，都有一个唯一的 UID。用于区分多次创建的同名对象（如前所述，按照名字删除对象后，重新再创建同名对象时，两次创建的对象 name 相同，但是 UID 不同。）

Kubernetes 中的 UID 是全局唯一的标识符（UUIDs，符合规范 ISO/IEC 9834-8 以及 ITU-T X.667）

名称空间

Kubernetes通过名称空间（namespace）在同一个物理集群上支持多个虚拟集群。

名称空间的使用

名称空间的用途是，为不同团队的用户（或项目）提供虚拟的集群空间，也可以用来区分开发环境/测试环境、准上线环境/生产环境。

名称空间为 名称 提供了作用域。名称空间内部的同类型对象不能重名，但是跨名称空间可以有同名同类型对象。名称空间不可以嵌套，任何一个Kubernetes对象只能在一个名称空间中。

名称空间可以用来在不同的团队（用户）之间划分集群的资源，在 Kubernetes 将来的版本中，同名称空间下的对象将默认使用相同的访问控制策略。

当KUbernetes对象之间的差异不大时，无需使用名称空间来区分，例如，同一个软件的不同版本，只需要使用 labels 来区分即可

查看名称空间

执行命令 kubectl get namespaces 可以查看名称空间，输出结果如下所示：

NAME STATUS AGEdefault Active 1dkube-system Active 1dkube-public Active 1d

Kubernetes 安装成功后，默认有初始化了三个名称空间：

default默认名称空间，如果 Kubernetes 对象中不定义metadata.namespace 字段，该对象将放在此名称空间下kube-systemKubernetes系统创建的对象放在此名称空间下kube-public此名称空间自动在安装集群是自动创建，并且所有用户都是可以读取的（即使是那些未登录的用户）。主要是为集群预留的，例如，某些情况下，某些Kubernetes对象应该被所有集群用户看到。

在执行请求的时设定namespace

执行 kubectl 命令时，可以使用 --namespace 参数指定名称空间，例如：

kubectl run nginx --image=nginx --namespace=<您的名称空间>kubectl get pods --namespace=<您的名称空间>

设置名称偏好

可以通过 set-context​ 命令改变当前 kubectl 上下文 的名称空间，后续所有命令都默认在此名称空间下执行

kubectl config set-context --current --namespace=<您的名称空间># 验证结果kubectl config view --minify | grep namespace:

名称空间与DNS

当您创建一个 Service 时，Kubernetes 为其创建一个对应的 DNS 条目​。该 DNS 记录的格式为 ..svc.cluster.local​，也就是说，如果在容器中只使用 ​，其DNS将解析到同名称空间下的 Service。这个特点在多环境的情况下非常有用，例如将开发环境、测试环境、生产环境部署在不同的名称空间下，应用程序只需要使用  即可进行服务发现，无需为不同的环境修改配置。如果您想跨名称空间访问服务，则必须使用完整的域名（fully qualified domain name，FQDN）

大部分的 Kubernetes 对象（例如，Pod、Service、Deployment、StatefulSet等）都必须在名称空间里。但是某些更低层级的对象，是不在任何名称空间中的，例如 nodes、persistentVolumes、storageClass 等

执行一下命令可查看哪些 Kubernetes 对象在名称空间里，哪些不在：

# 在名称空间里kubectl api-resources --namespaced=true# 不在名称空间里kubectl api-resources --namespaced=false

名称空间的作用

一个Kubernetes集群应该可以满足多组用户的不同需要。Kubernetes名称空间可以使不同的项目、团队或客户共享同一个 Kubernetes 集群。实现的方式是，提供：

名称 的作用域

为不同的名称空间定义不同的授权方式和资源分配策略Resource Quota 和resource limit range

每一个用户组都期望独立于其他用户组进行工作。通过名称空间，每个用户组拥有自己的：

Kubernetes 对象（Pod、Service、Deployment等）授权（谁可以在该名称空间中执行操作）资源分配（该用户组或名称空间可以使用集群中的多少计算资源）

可能的使用情况有：

集群管理员通过一个Kubernetes集群支持多个用户组集群管理员将集群中某个名称空间的权限分配给用户组中的受信任的成员集群管理员可以限定某一个用户组可以消耗的资源数量，以避免其他用户组受到影响集群用户可以使用自己的Kubernetes对象，而不会与集群中的其他用户组相互干扰

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。