Kubernetes资源指标

官方文档的changelog中讲从1.11版本开始，开始将监控体系，指标数据获取机制移向新一代的监控模型。对于k8s来讲，现在有两种资源指标被使用：
1、资源指标
2、自定义指标

容器的资源需求和资源限制

定义在容器级别的属性pods.spec.containers。目前支持定义CPU和内存资源。

• requests: 需求,最低保障;
• limits:限制,硬限制;
  阅读全文 »

scheduler调度过程概述

scheduler在实现调度时，分为三步实现调度过程。首先是预选，从所有节点当中选择基本符合条件的节点；而后在众多符合条件的节点当中，在使用优选函数去计算各自的得分并且加以比较，并从最高得分的节点当中随机选择出一个作为运行Pod的节点。这就是控制平面当中scheduler所实现负责的主要工作。

Kubernetes整体架构概述

master从本质上来讲主要是运行整个集群的控制平面组件的，比如三个最核心的组件：apiserver、Scheduler、Controller-manger。除此之外，master还依赖etcd这样的存储节点，最好还是个有冗余能力的存储集群。使用kubeadm部署时会把这个控制平面部署为了pod应用程序，但是是部署为静态Pod的。从本质上来讲，我们可以认为这几个pod就是简单的运行在master节点本地的守护进程，从这个角度来讲，master本身是不负责运行任何工作负载的。

flannel、calico和canel

calico的配置依赖于对BGP等协议的理解，我们这里不去使用calico作为网络插件提供网络功能了，而是把重点集中在calico如何提供网络策略，因为flannel本身提供不了网络策略，而flannel和calico二者已经合二为一了，有个新项目叫canel。可以在flannel提供网络功能的基础之上，在额外提供calico，去服务于网络策略。

docker的4种常用的网络模型

• bridge
• joined：共享使用另外一个容器的网络名称空间
• open：使用宿主机网络名称空间。
• none

无论是哪一种方式，跨节点容器之间进行通信时，必须使用NAT机制来实现。出宿主机时做源地址转换，必须拿着物理机的地址出去。

dashboard

Kubernetes的子项目之一，是Kubernetes核心附件之一。作为Kubernetes的Web用户界面，用户可以通过Dashboard在Kubernetes集群中部署容器化的应用，对应用进行问题处理和管理，并对集群本身进行管理。通过Dashboard，用户可以查看集群中应用的运行情况，同时也能够基于Dashboard创建或修改部署、任务、服务等Kubernetes的资源。通过部署向导，用户能够对部署进行扩缩容，进行滚动更新、重启Pod和部署新应用。在Kubernetes 1.8之后，在部署dashboard时，有着更复杂的权限检查了。传统的在互联网上看到的开放访问的方式不一定支持了。

常用的授权插件

• Node：由节点来认证。
• ABAC：基于属性的访问控制。
• RBAC：Role-based AC
• Webhook：基于http的回调机制
  阅读全文 »

Kubernetes安全概述

对于k8s api接口的访问不会是任何人能够轻易使用的，此前我们是通过kubectl这个客户端工具进行访问的，如果人人都可以通过kubectl来访问，那么就很可能会删除别人的应用，这是非常危险的。因此k8s对于整个系统的认证、授权和所谓的后续的访问控制做了非常精密和精细的设计。当然考虑k8s从诞生到现在还不算太长，可能会陆续有一些漏洞和缺陷被发现，但至少到现在为止，它在模型设计上已经做得足够安全了。

StatefulSet介绍

简称sts。
不同的分布式系统运维管理逻辑和运维操作过程是不尽相同的。因此没有办法有一种控制器把每一种功能都同步进来，让我们非常简单地去操作这些有状态应用。即便有了StatefulSet，我们用StatefulSet去实现真正功能控制时也是极其麻烦的。