概述

kubernetes系统的资源管理是通过API Server完成的。API Server通过HTTP/HTTPS来接收客户端的资源操作请求，完成对资源的管理操作。

资源类别

（1）工作负载Workload
（2）发现和负载均衡Discovery & LB
（3）配置和存储Config & Storage
（4）集群Cluster
（5）元数据Metadata

工作负载
负责运行容器，解决环境的依赖问题。例如向容器中注入共享的或持久化的存储卷、配置信息或密钥数据等。这类工作主要通过控制器来完成。目前的控制器主要有以下几种

• ReplicationController: 用于确保在任何时候Pod的数量满足预期数量，目前已被废弃，现在通过Deployment和ReplicaSet来完成
• ReplicaSet: 替代ReplicationController，并且支持更丰富的标签
• Deployment: 用于管理无状态持久化的应用，如HTTP服务
• StatefulSet: 用于管理有状态的持久化应用，比如RDS，Redis等，会为Pod创建一个独有的持久性标签，并且会保证Pod之间的顺序性
• DaemonSet: 保证每个节点都运行了某个Pod的一个副本。比如filebeat，fluentd等日志收集进程；glusterd，ceph等守护进程；另外还有Prometheus的监控进程

发现和负载均衡
Pod资源可能会因为故障或者资源紧张而被重建，因此系统需要随时扫描其状态。目前kubernetes系统主要有这几种负载均衡和发现类型的资源：1.发现机制和负载均衡功能的Service资源和Endpoint资源，2.通过七层代理实现请求流量负载均衡的Ingress资源

配置和存储
1.kubernetes系统配置类型的资源为ConfigMap。ConfigMap资源能够以存储卷和环境变量的方式接入到Pod的容器中，并且具有共享特性。能够同时在多个Pod上生效，从而为一类资源进行配置。但是不适合用来存储敏感数据，敏感数据主要使用Secret类型资源来存储。
2.kubernetes系统通过Volume资源来引入多种类型的存储系统和存储设备，如GlusterFS、CEPH RDB和Flocker等

集群级资源
Pod、Deployment、Service和ConfigMap等类型的资源都是属于名称空间级别的资源。可以由各个名称空间的管理员来管理。另外有一类资源是属于集群级别的，只有系统管理员才能够进行配置管理。

• NameSpace:默认为default，也可以自定义创建
• Node:工作节点，节点名称在当前集群内唯一
• Role:有限的自定义的权限集合，可被RoleBinding引用
• ClusterRole:Cluster级别的权限的集合，可被Rolebinding和ClusterRolebinding引用
• RoleBinding:将Role的权限绑定至一个或一组用户上。也可引用ClusterRole
• ClusterRoleBinding:将ClusterRole的权限绑定至一个或一组用户上，可以通过Subject添加相关信息

元数据资源
如果知道各种资源的metadata字段就知道元数据资源用来干什么的了。主要用于设置资源的名称，名称空间，标签等等信息。

PS：总结一下：对一个应用来说，需要deployment资源来管理应用的Pod；使用ConfigMap来管理资源的配置；使用Service或Ingress来暴露应用，让外部访问；使用Volume给应用提供外部存储

访问Kubernetes REST API

使用kubeadm部署的kubernetes系统集群默认只支持HTTPS的访问方式，并需要进行一些列的认证检查。如果想通过命令行来获取集群的API资源，则可以通过kubectl proxy来作为代理网关

~]$ kubectl proxy --port=8080
Starting to serve on 127.0.0.1:8080

# 另外再开一个窗口
~]$ curl localhost:8080/api/v1/namespaces # 这样就能获取集群的所有namespace资源了，格式为JSON

# 使用jq命令来过滤资源
~]$ curl -s localhost:8080/api/v1/namespaces/ | jq .items[].metadata.name
"default"
"kube-node-lease"
"kube-public"
"kube-system"

# 获取特定名称空间的信息
~]$ curl -s localhost:8080/api/v1/namespaces/kube-system
。。。

spec字段和status字段

kubernetes使用spec字段来设置资源的期望状态，使用status字段来描述资源当前的状态。因此，在配置资源的时候，spec字段是必须字段。
spec
spec字段嵌套的字段对于不同的资源来说也会存在较大的差距，具体的嵌套字段需要使用explain命令来查阅。

~]$ kubectl explain pods
获取资源的KIND, VERSION, DESCRIPTION, FIELDS
其中，除了DESCRIPTION字段外，其他三个字段都是比较重要的。
- KIND字段描述了资源的类型
- VERSION字段描述了资源的apiVersion的版本
- FIELDS则是核心字段，描述了资源的字段嵌套类型

~]$ kubectl explain pods.spec #获取pod资源的spec字段的信息
~]$ kubectl explain pods.sepc.containers #获取spec字段下的嵌套字段
这种方式可以递归使用，掌握了字段的信息就可以进行资源的设置了。

status
使用get命令可以获取资源的状态

~]$ kubectl get pods
~]$ kubectl get pods -o wide
~]$ kubectl get pods -o json
~]$ kubectl get pods -o yaml
~]$ kubectl get pods -o yaml --export > pods-demo.yaml #导出pod的信息

资源管理

名称空间资源增删改查
（1）创建名称空间

~]$ kubectl create namespace NAME
~]$ kubectl apply -f namesapce-test.yaml #使用yaml文件定义namspace资源

（2）删除名称空间(谨慎操作，删除名称空间时，此namespace下的所有资源都会被删除)

~]$ kubectl delelte namespace test
~]$ kubectl delete TYPE RESOURCE_NAME -n NAMESPACE #删除指定名称空间下的指定资源
~]$ kubectl delete TYPE --all -n NAMESPACE #删除名称空间下的指定类型的所有资源
~]$ kubectl delele all -n NAMESPACE #删除名称空间下的所有资源
~]$ kubectl delete all -all #这条命令就相当于 rm -rf /*

（3）查询名称空间

~]$ kubectl get ns

（4）不能修改名称空间
Pod资源增删改查
（1）创建Pod

~]$ kubectl apply -f pod-demo.yaml
~]$ kubectl create -f pod-demo.yaml

（2）删除Pod

~]$ kubectl delete pod POD_NAME -n NAMESPACE
~]$ kubectl delete -f pod-demo.yaml

（3）修改Pod

~]$ kubectl replace -f pod-demo2.yaml
~}$ kubectl replace -f pod-demo2.yaml --force #强制替换，先删除旧的pod，然后重建新的pod

（4）查询Pod

~]$ kubectl get pods 
~]$ kubectl get pods -n NAMESPACE
~]$ kubectl get -f pod-demo.yaml
~]$ kubectl describe pod POD_NAME -n  NAMESPACE #其他资源也可这么做