Kubernets 资源类型简介

# Node

代表 Kubernets 集群运行的宿主物理机或者虚拟服务器, 为容器提供必要的计算资源: 内存 与 CPU 等.

# Pod

最底层的抽象. 一个 Pod 中可以包含一个或者多个运行的容器, 这些容器运行在同一个 Node 上, 并共享次 Node 的资源. 在同一个 Pod 中的容器, 可以相互通过 localhost 的方式通信, 这样就可以以集群与可扩展方式运行一个应用提供了支持.

Pod 是 Kubernetes 中的 '不可变层 (immutable layer)' ; Pod 不会升级, 只会关闭,丢弃与被代替. 他们可以被手动停止, 但是, 不推荐这样. 在 Kubernetes 集群中对 Pod 的配置与管理都是通过 "Deployment" 来完成.

# Deployment

Deployment 是 Kubernetes 集群的管理殷勤, 负责管理集群中繁琐的 Pod 启停工作, 如 : 它负责部署一个集群中一共需要跑多少个 Pod, Pod 运行的内容, 以及根据部署方案或者 Node , 集群发生的问题来决定如何启停 Pod (技术上来讲, Deployment 把上面的一些工作交给了 Replica Set 来做).

示例 , 一次部署 3 个 nginx_pod :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        role: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

# Service : 将容器中运行的服务暴露给外网.

Service 是一个 Pod 逻辑集合和访问这个集合的策略, 逻辑上代理后端 Pod. 代表 Pod 集合与其他服务进行交互, 进行请求的分发和负载均衡.

集合是通过定义 Service 时, 提供的 Label 选择器完成的.

kube-proxy 通过 iptables 实现.

Service 提供了一个从 Deployment 与 Pod 到外部网络以及外部网络到内部容器的一个双工通道.

NodePort Service : 提供容器内部访问机制, 但是也能将部分高段的端口(30000-35000)映射给集群外部以访问集群内部的容器.

LoadBalancer Service : 可以通过配置一些规则在你的云环境中实现一个 负载均衡器.

ClusterIP : 默认类型. 自动分配一个仅 Cluster 内部可以访问的虚拟IP, 这种类型的服务只能在集群内部使用访问. 用户从且只能从 kubernetes node 节点，使用 clusterIp 和 port 就可以访问 service 里的服务了。

externalName : 同事分配 Cluster IP , 并进一步在集群中所有节点的同一端口上暴露服务, 用户可以通过任意的 <NodeIP>:NodePort 访问服务. 用户可以从任意 kubernetes node 节点 和 非 kubernetes node 节点，只要和 kubernetes node 正常通信的机器，都可以访问service的服务。

示例配置:

我们在一个rails应用的前端加一个nginx的负载均衡，同时使用redis作为此应用的数据后端，只需要内部访问。我们的负载均衡指向nginx，nginx将请求路由到rails应用程序，同时通过redis读写数据。下面是Service的配置文件，注意其中的selector节点中label值role:web让Kubernetes知道此LoadBalancer类型的Service的具体Deployment在哪 (上节讲Deployment时例子中的3个nginx)。

##
# nginx
# Listen to the world on port 80 and 443
##
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    role: web
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 443
  selector:
    # Find all Resources that are tagged with the "role: web" label
    # In our case, it will find the nginx Deployment mentioned above
    role: web
---
##
# Rails
# Listen for traffic on 8080 so we don't have to run as root.
##
apiVersion: v1
kind: Service
metadata:
  name: rails
  labels:
    role: rails
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 8080
  selector:
    role: rails
---
##
# Redis
##
apiVersion: v1
kind: Service
metadata:
  name: redis
  labels:
    role: redis
spec:
  type: NodePort
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    role: redis

# Namespace : 封装/划分基础设施

在 Service 上面, 还可以定义它的 Namespace 属性, 它实际上只是一个标识符, 用于封装,划分你的基础设施.

Kubernetes 内部就是用命名空间的方式来区分自己内部的服务(kubedns,kube-proxy等)与用户自定义的服务, Kubernetes 的命名空间是 : kube-system.

如果用户未定义命名空间, Kubernetes 会将"资源"放置到一个默认的命名空间中, 在大多数情况下, 这就足够了; 但是, 在多团队合作的情况下, 使用命名空间可以防止资源的冲突与混淆.

示例:

apiVersion: v1
kind: Namespace
metadata:
  name: my-app

# Labels : 用与标记与查找资源.

Kubernetes中大量使用Label在整个集群中来标记与查找资源。

Deployment 中有 labels 节点, 他的值跟下面的 Service 中 selectors 中的值是对应的. Kubernetes 用 Label 将各种资源重定义的配置关联在一起, 引用层级:

Service --> Deployment --> Pod --> Container

# secrets : 在 Pod 与容器中保存敏感信息

# DaemonSet : 定义在部分或者所有 Nodes 中都冗余的运行一个 Pod

# Job : 创建一次性任务.

# kubernetes 支持的卷插件(v1.6)

红色的为 v1.6 新增.