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 &quot;role: web&quot; 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 会将&quot;资源&quot;放置到一个默认的命名空间中, 在大多数情况下, 这就足够了; 但是, 在多团队合作的情况下, 使用命名空间可以防止资源的冲突与混淆.
　　示例:
　　

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 新增.