kubernetes资源对象的操作实操
在应用层面，所有的K8S资源对象都叫做API对象。
在k8s中，推荐使用配置文件运行一个或者多个容器，当然也支持命令行方式。API对象的配置文件可以是yaml格式的文件，也可以是json格式的文件。
yaml文件比较易懂，因此后面都会使用yaml风格的文件去描述一个k8s对象的各种属性，即：容器的定义，参数，配置，统统记录在一个yaml文件。
K8S对象yaml的构成：例如
在上述的.yaml文件中，如下字段是必须填写的：
①、apiVersion:用来创建对象时所使用的Kubernetes API版本
②、kind:被创建对象的类型
③、metadata：用于唯一确定该对象的元数据：包括name和namespace，如果namespace为空，则默认值为default。
④、spec描述对该对象的期望值
不同类型的kubernetes，其spec对象的格式不同(含有不同的内嵌字段)，通过api手册官方文档可以查看kubernetes对象的字段和描述。
当在Kubernetes中创建一个对象时，必须提供对象规约spec，例如：
1、名称
2、使用什么镜像
3、多少个副本
4、挂载的文件或目录
5、使用多少资源等
spec是静态的，是存在yaml文件中的，
关于yaml文件的分割
多个资源对象的yaml文件，比如Deployment和Service，可以放在一个文件，可以放在不同的yaml文件中单独执行。如果放在同一个yaml文件中，需要用连续的三个短横线隔开
关于对象的CRUD以及对象Kubernetes系统的持久化实体，通过ercd持久化
①、操作kubernetes对象-无论是创建，修改，或者删除-需要使用kubernetes API.比如，当使用kubectl命令行接口时，CLI会执行必要的kubernetes API调用。
②、Kubernetes对象指的是Kubernetes系统持久化实体，所有这些对象合起来，代表了集群的实际情况。
常规的应用里，我们的应用程序的数据存储在数据库中，Kubernetes将其数据以Kubernetes对象的形式通过api server存储在etcd中。
具体来说，这些数据(Kubernetes对象)描述了：
①、集群中运行了哪些容器化应用程序(以及在哪个节点上运行)
②、集群中对应用程序可用的资源(网络，存储等)
③、应用程序相关的策略定义，例如：重启策略，升级策略，容错策略。
④、其他Kubernetes管理应用程序时所需要的信息
查看apiversion可用版本
在k8s中查看apiversion可用版本的命令如下：
各种apiversion的含义
①、alpha
1、该软件可能包含错误，启用一个功能可能会导致bug
2、随时可能会丢弃对该功能的支持，恕不另行通知
②、beta
1、软件经过很好的测试，启用功能被认为是安全的
2、默认情况下功能是开启的
3、细节可能会改变，但功能在后续版本不会被删除。
③、stable
1、该版本名称命名方式：vX这里的X是一个整数
2、稳定版本，放心使用
3、将出现在后续发布的软件版本中
④、v1
1、Kubernetes API的稳定版本，包含了很多核心对象：pod,service等
⑤、apps/v1beta2
1、在Kubernetes1.8版本中，新增了apps/v1beta2的概念，apps/v1beta1同理。DaemonSet,Deployment,ReplicaSet和StatefulSet的当时版本迁入apps/v1beta2，兼容原有的extensions/v1beta1。
⑥、apps/v1
1、在kubernetes1.9版本中，引入了apps/v1,deployment等资源从extensions/v1beta1,apps/v1beta1和apps/v1beta2迁入apps/v1，原来的v1beta1等被废弃。
apps/v1代表：包含一些通用的应用层api组合，如：Deployments,RollingUpdates，andReplicaSets。
⑦、batch/v1
1、代表job相关的api组合
在Kubernetes1.8版本中，新增了batch/v1beta1，后CronJob已经迁移到了batch/v1beta1，然后再迁入batch/v1
⑧、autoscaling/v1
1、代表自动扩缩容的api组合，kubernetes1.8版本中引入，这个组合中后续的alpha和beta版本将支持基于memory使用量，其他监控指标进行扩缩容。
⑨、extensions/v1beta1
1、deployment等资源在1.6版本时放在这个版本中，后迁入到apps/v1beta2，再到apps/v1中统一管理。
⑩、certificates.k8s.io/v1beta1：安全认证相关的api组合
authentication.k8s.io/v1:资源鉴权相关的api组合
补充说明：Kubernetes的官方文档中并没有对apiVersion的详细解释，而且因为K8S本身版本也在快速迭代，有些资源在低版本还在beta阶段，到了高版本就变成了stable。
获取各个属性字段的含义的命令如下：
Kubernetes对象的定义字段，非常多；如果需要了解各个属性的字段的含义，有两个方式：方式一：从命令行获取方式；方式二：官方API文档方式
方式一：从命令行获取方式：
kubectl explain 查看 创建对象所使用的API版本。
例如：查看pod使用的API版本如下
管理K8S对象：
注意：同一个Kubernetes对象应该只使用一种方式管理，否则可能会出现不可预期的结果。
下面使用指令性对象的配置来管理k8s资源对象的CRUD的操作
首先定义一个对象文件：如下
apiVersion: apps/v1 #每种资源对象都归属到版本下的 可以通过kubectl explain deployment.apiVersion来查看#做pod的部署管理的 对Pod进行管理，可以有多个 副本的数量 所以在pod上有标号kind: Deployment #根据标签做副本的调度所以要加上选择器metadata: name: nginx-gateway-deployment labels: app: nginx-gateway #为该Deployment设置key为app，value为nginx的标签 #定义预期的行为spec: replicas: 1 #pod的副本数量 selector: #标签选择器，与上面的标签共同作用 根据条件来管理副本，做副本的调度 matchLabels: #选择包含标签app:nginx的资源 根据标签查副本 app: nginx-gateway #接收流量的pod所以要加上标签 template: #这是选择或创建的Pod的模板 metadata: #Pod的元数据 接收流量的和调度的 labels: #Pod的标签，上面的selector即选择包含标签app:nginx的Pod app: nginx-gateway spec: #期望Pod实现的功能（即在pod中部署） hostAliases: - ip: "192.168.49.1" hostnames: - "cdh1" #下面可以定义多个容器，同属于一个pod containers: #生成容器的container，与docker中的container是同一种 - name: nginx-gateway image: harbor.daemon.io/demo/nginx-gateway:1.0-SNAPSHOT #使用镜像nginx 创建container，该container默认8008端口可访问 ports: - containerPort: 8008 # 开启本容器的8008端口可访问 #和etc的profile文件的配置是一样的 env: - name: env_flag value: flag224455555555555333 --- apiVersion: v1#做pod的传输层的负载均衡的 4层的kind: Servicemetadata: name: nginx-gateway-svcspec: selector: app: nginx-gateway #选择包含标签app:nginx的资源 也加上标签：根据标签做流量的分发 也要加上选择器 ports: - port: 8008 #写nginx本身端口 protocol: TCP targetPort: 8008 # 容器nginx对外开放的端口 上面的dm已经指定了 nodePort: 32701 #外网访问的端口
部署资源文件
查看pod:
查看service:
我们如果访问svc的话，需要用minikube集群ip：32701来访问svc，然后svc把流量打到标签为nginx-gateway的Pod上。然后由对应的pod来处理
