kubernetes(k8s)资源管理/清单配置基础

控制平面：

• API-Service: 运行于6443端口
  • 接入master节点地址的6443端口进行交互
  • 用户认证， 双向认证
• Scheduler
• Controller

工作平面：kube-proxy每个节点都有

核心资源:

• Pod
• Pod Controller
  • deployment
  • Service

和解循环（Reconciliation Loop）

• 客户端向API Server提交POST请求以创建对象
  • 通过JSON格式的body提交
  • Yaml格式需要事先完成向JSON的转换
  • 对象匹配信息保存于etcd中，其定义出的状态也称为“期望的状态（spec）”
• 控制器负责将其创建为k8s集群上的具体对象，并确保其当前状态（status）与用户定义的期望状态相同
  • status控制器自行维护，而spec则由用户进行提交
  • 活动对象在运行过程中因节点故障等原因可能会在某一时刻导致status不再吻合于spec
  • 控制器通过和解循环（loop）不间断地监控相关对象的当前状态，在对象的当前状态发生改变时运行合适的操作让其当前状态无限接近于期望的状态

资源对象的配置格式

• API Server接受和返回的所有JSON对象都遵循同一个模式，他们都具有“kind”和"apiVersion"字段，用于表示对象所属的资源类型、API群组及相关版本
• 大多数的对象或列表的资源还需要具有三个嵌套的字段metadata、spec、和status
  • metadata字段为资源提供元数据信息，例如名称、隶属的名称空间和标签等
  • spec用于定义用户期望的状态，不同的资源类型，其状态的意义各不相同，例如pod资源最为核心的功能在于运行容器
  • status则记录着活动对象的当前状态信息，它由kubernetes系统自行维护，对用户来说是只读字段
• “kubectl  api-resources”命令可以获取集群支持所使用的所有资源类型

管理资源对象

资源对象管理方式

• kubectl的命令可分为三类
  • 陈述式命令
  • 陈述式对象配置
  • 声明式对象配置
• 第一种方式即用到的run、expose、delete和get等命令，它们直接作用于kubernetes系统上的活动对象，简单易用，但不支持代码服用、修改复审及审计日志功能，这些功能的实现通常要依赖于资源配置文件中这些文件也被称为资源清单。

我们可以使用以下命令快速导出资源的yaml文件，但是需要在导出的文件上做自己的配置修改后才能使用：

　　# kubectl get  xxx  -o yaml --export > desc_file

陈述式配置文件创建一个develop的namespace：

声明式创建test的namespace：

• 声明式相比于陈述式的好处是：修改了yaml文件之后直接apply就可以完成修改变动，而create不行
• apply可以直接指定一个目录，目录中的配置清单会被全部应用，而create不支持

♠♠♠ pod 10.244.0.0/16 能否被集群外部访问？ 10.244.0.0/16是flannel网络插件内部网段 ♠♠♠

• 默认情况下答案是不能的
• 解决办法
  • 通过service NodePort 暴露每个节点上的一个端口映射
  • 通过hostPort 暴露指定节点端口
  • 通过hostNetwork 共享宿主机端口网络

原文地址：https://www.cnblogs.com/alamisu/p/10976749.html