概述

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资源来引入多种类型的存储系统和存储设备,如GlusterFSCEPH RDBFlocker

集群级资源
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 #其他资源也可这么做
Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐