Kubernetes controller-manager中deployment处理流程源码分析 本文将对Kubernetes controller-manager中的deployment处理的源码进行分析。采用主干的代码，commitId为2ab7ad14b4fad378a4a69a64c587497d77e60f44。代码的时间为2017年08月19日。
Kubernetes中replicaset处理流程源码分析 本文将对Kubernetes中controller-manager源码中Replicaset Controller部分进行分析。采用主干的代码，commitId 2ab7ad14b4fad378a4a69a64c587497d77e60f44。
Kubernetes中controller-manager源码分析--启动流程 本文将对Kubernetes中controller-manager的源码进行分析。分析的时间为2017年08月19日。采用主干的代码，commitId为2ab7ad14b4fad378a4a69a64c587497d77e60f44。
kubernetes安全控制认证与授权(二) 本文将继续kubernetes授权体系。授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略才能被处理。跟认证类似，Kubernetes也支持多种授权机制，并支持同时开启多个授权插件（只要有一个验证通过即可）。如果授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证；对于授权失败的请求则返回HTTP 403。
kubernetes安全机制--Admission Control 准入控制 引言当请求通过了前面的认证和授权之后，还需要经过准入控制处理通过之后，apiserver 才会处理这个请求。Admission Control 有一个准入控制列表，我们可以通过命令行设置选择执行哪几个准入控制器。只有所有的准入控制器都检查通过之后，apiserver 才执行该请求，否则返回拒绝。
kubernetes安全控制认证与授权(一) kubernetes 对于访问 API 来说提供了两个步骤的安全措施：认证和授权。认证解决用户是谁的问题，授权解决用户能做什么的问题。通过合理的权限管理，能够保证系统的安全可靠。通俗的讲，认证就是验证用户名密码，授权就是检查该用户是否拥有权限访问请求的资源。
CoreOS有状态应用管理的框架--Operator详解 Operator是CoreOS推出的旨在简化复杂有状态应用管理的框架，它是一个感知应用状态的控制器，通过扩展Kubernetes API来自动创建、管理和配置应用实例。Operator原理Operator基于Third Party Resources扩展了新的应用资源，并通过控制器来保证应用处于预期状态。
Kubernetes Scheduler 调度- Node信息管理 源码为k8s v1.6.1版本，github上对应的commit id为b0b7a323cc5a4a2019b2e9520c21c7830b7f708e本文将对Scheduler的调度中Node信息的管理流程进行介绍，主要介绍Scheduler模块中node信息如何初始化，node信息如何与pod的更新信息同步，node信息如何用到调度算法中
Kubernetes Scheduler 调度详解-基于Kubernetes 1.61版本 源码为k8s v1.6.1版本，github上对应的commit id为b0b7a323cc5a4a2019b2e9520c21c7830b7f708e本文将对Scheduler的调度算法原理和执行过程进行分析，重点介绍Scheduler算法中预选和优选的相关内容。Scheduler的调度算法的执行过程进行分析。
Kubernetes Scheduler源码分析--启动过程与多队列缓存(续) 继续上文对Scheduler的分析，分析在Scheduler主循环处理过程中，podQueue,Queue和assumePod 三个队列的处理。Scheduler中SchedulerOne为主要的处理函数，其源代码为func (s *Scheduler) scheduleOne() { pod := s.config.NextPod() if pod.DeletionTim
Kubernetes Scheduler源码分析--启动过程与多队列缓存 源码为k8s v1.6.1版本，github上对应的commit id为b0b7a323cc5a4a2019b2e9520c21c7830b7f708e本文将对Scheduler中，Pod的处理过程进行分析，主要分析Pod在各个缓存队列中的流动过程。
Kubernetes中pod创建流程 Pod是Kubernetes中最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。例如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个container的pod。本文将对Kubernetes的基本处理流程做一个简单的分析。具体的创建步骤包括：
Kubernetes 1.6新特性系列 | 高级调度 作者注：这是深入Kubernetes 1.6特性系列的第四篇。导读：Kubernetes 1.6高级调度的新特性主要集中在四个方面:Node的亲和性和反亲和性(Affinity/Anti-Affinity)Node的污点和容忍(Taints and Tolerations)Pod的亲和性和反亲和性(Affinity/Anti-Affinity)自定义调度器1、简介
kubernetes1.6新特性：支持新的卷插件 背景介绍在Kubernetes中卷的作用在于提供给POD持久化存储，这些持久化存储可以挂载到POD中的容器上，进而给容器提供持久化存储。从图中可以看到结构体PodSpec有个属性是Volumes，通过这个Volumes属性可以关联到结构体Volume和结构体VolumeSource，而且这个Volumes属性是一个数组类型，就是说POD可以关联到多个不同类型的卷上面。结
Kubernetes 1.6新特性：RBAC授权 概述Kuberntes中API Server的访问控制过程图示如下：在Kubernetes中，授权(authorization)是在认证(authentication)之后的一个步骤。授权就是决定一个用户(普通用户或ServiceAccount)是否有权请求Kubernetes API做某些事情。之前，Kubernetes中的授权策略主要是ABAC(Attribut
Kubernetes1.6新特性：全面支持多颗GPU (一) 背景资料GPU就是图形处理器，是Graphics Processing Unit的缩写。电脑显示器上显示的图像，在显示在显示器上之前，要经过一些列处理，这个过程有个专有的名词叫“渲染" ，以前计算机上是没有GPU的，都是通过CPU来进行“渲染”处理的，这些涉及到“渲染”的计算工作非常耗时，占用了CPU的大部分时间。之后出现了GPU，是专门为了实现“渲染”这种计算工作的，用来将CPU解
Kubernetes 1.6新特性系列 | 动态配置和存储类 Dynamic Provisioning的目标是完全自动化存储资源的生命周期管理，让用户无需过多的关注存储的管理，可以按需求自动动态创建和调整存储资源。StorageClass本质上是底层存储介质的抽象：不同的存储介质拥有统一的表示和行为。
Kubernetes 1.6新特性系列|在Kubernetes里配置私有DNS区域和上游服务器 许多用户都试着将现有的域名区域(domain name zones)集成到Kubernetes的DNS命名空间里。例如混合云用户可能想在集群里能解析他们内部的”.corp”域名，其他一些用户可能希望使用由其他的服务发现系统（比如Consul）管理的区域。1默认查找流 Kubernetes目前支持两种的DNS策略，通过将Pod的dn
Kubernetes 1.6 官方发布：支持多用户、多工作负载 今天，我们宣布 Kubernetes1.6正式发布。在这次版本中，社区的重点落在集群运行规模和集群运行自动化上，可以在帮助实现集群上给多个用户部署多项工作的目标。Kubernetes 1.6版本目前集群上支持5000个节点。在我们的努力下，Dynamic Storage Provisioning 处于稳定版本。Role-based access control（RBAC）、
关注
