目录：
一、Harbor的安全机制
二、Harbor的镜像同步
三、Harbor与K8s的集成实践
四、两个小贴士
五、总结
Habor是由VMWare公司开源的容器镜像仓库。事实上，Habor是在DockerRegistry上进行了相应的企业级扩展，从而获得了更加广泛的应用，这些新的企业级特性包括：管理用户界面，基于角色的访问控制，AD/LDAP集成以及审计日志等。
容器的核心在于镜象的概念，由于可以将应用打包成镜像，并快速的启动和停止，因此容器成为新的炙手可热的基础设施CAAS，并为敏捷和持续交付包括DevOps提供底层的支持。
而Habor和DockerRegistry所提供的容器镜像仓库，就是容器镜像的存储和分发服务。之所以会有这样的服务存在，是由于以下三个原因：
提供分层传输机制，优化网络传输
Docker镜像是是分层的，而如果每次传输都使用全量文件（所以用FTP的方式并不适合），显然不经济。必须提供识别分层传输的机制，以层的UUID为标识，确定传输的对象。
提供WEB界面，优化用户体验
只用镜像的名字来进行上传下载显然很不方便，需要有一个用户界面可以支持登陆、搜索功能，包括区分公有、私有镜像。
支持水平扩展集群
当有用户对镜像的上传下载操作集中在某服务器，需要对相应的访问压力作分解。
上面这些就是DockerRegistry所完成的主要工作，而Habor在此之上，又提供了用户、同步等诸多特性，这篇文章中我们就这几个方面作一些阐述，同时实例代码介绍Harbor与K8s的集成。
一、Harbor的安全机制
企业中的软件研发团队往往划分为诸多角色，如项目经理、产品经理、测试、运维等。在实际的软件开发和运维过程中，这些角色对于镜像的使用需求是不一样的。从安全的角度，也是需要通过某种机制来进行权限控制的。
举例来说，开发人员显然需要拥有对镜像的读写（PULL/PUSH）权限以更新和改正代码；测试人员中需要读取（PULL）权限；而项目经理需要对上述的角色进行管理。
Harbor为这种需求提供了用户和成员两种管理概念。
在Harbor中，用户主要分为两类。一类为管理员，另一类为普通用户。两类用户都可以成为项目的成员。而管理员可以对用户进行管理。
成员是对应于项目的概念，分为三类：管理员、开发者、访客。管理员可以对开发者和访客作权限的配置和管理。测试和运维人员可以访客身份读取项目镜像，或者公共镜像库中的文件。
从项目的角度出发，显然项目管理员拥有最大的项目权限，如果要对用户进行禁用或限权等，可以通过修改用户在项目中的成员角色来实现，甚至将用户移除出这个项目。
二、Harbor的镜像同步
为什么需要镜像同步
由于对镜像的访问是一个核心的容器概念，在实际使用过程中，一个镜像库可能是不够用的，下例情况下，我们可能会需要部署多个镜像仓库：
国外的公有镜像下载过慢，需要一个中转仓库进行加速
容器规模较大，一个镜像仓库不堪重负
对系统稳定性要求高，需要多个仓库保证高可用性
镜像仓库有多级规划，下级仓库依赖上级仓库
更常用的场景是，在企业级软件环境中，会在软件开发的不同阶段存在不同的镜像仓库，
在开发环境库，开发人员频繁修改镜像，一旦代码完成，生成稳定的镜像即需要同步到测试环境。
在测试环境库，测试人员对镜像是只读操作，测试完成后，将镜像同步到预上线环境库。
在预上线环境库，运维人员对镜像也是只读操作，一旦运行正常，即将镜像同步到生产环境库。
在这个流程中，各环境的镜像库之间都需要镜像的同步和复制。
Harbor的镜像同步机制
有了多个镜像仓库，在多个仓库之间进行镜像同步马上就成为了一个普遍的需求。比较传统的镜像同步方式，有两种：
第一种方案，使用Linux提供的RSYNC服务来定义两个仓库之间的镜像数据同步。
第二种方案，对于使用IaaS服务进行镜像存储的场景，利用IaaS的配置工具来对镜像的同步进行配置。
这两种方案都依赖于仓库所在的存储环境，而需要采用不同的工具策略。Harbor则提供了更加灵活的方案来处理镜像的同步，其核心是三个概念：
用Harbor自己的API来进行镜像下载和传输，作到与底层存储环境解耦。
利用任务调度和监控机制进行复制任务的管理，保障复制任务的健壮性。在同步过程中，如果源镜像已删除，Harbor会自动同步删除远端的镜像。在镜像同步复制的过程中，Harbor会监控整个复制过程，遇到网络等错误，会自动重试。
提供复制策略机制保证项目级的复制需求。在Harbor中，可以在项目中创建复制策略，来实现对镜像的同步。与DockerRegistry的不同之处在于，Harbor的复制是推（PUSH）的策略，由源端发起，而DockerRegistry的复制是拉（PULL）的策略，由目标端发起。
Harbor的多级部署
在实际的企业级生产运维场景，往往需要跨地域，跨层级进行镜像的同步复制，比如集团企业从总部到省公司，由省公司再市公司的场景。
这一部署场景可简化如下图：
更复杂的部署场景如下图：
三、Harbor与K8s的集成实践
Harbor提供了基于角色的访问控制机制，并通过项目来对镜像进行组织和访问权限的控制。kubernetes中通过namespace来对资源进行隔离，在企业级应用场景中，通过将两者进行结合可以有效将kubernetes使用的镜像资源进行管理和访问控制，增强镜像使用的安全性。尤其是在多租户场景下，可以通过租户、namespace和项目相结合的方式来实现对多租户镜像资源的管理和访问控制。
集成的核心概念和关键步骤
两者的集成，一个核心概念是k8s的secret。作为kubernetes中一个重要的资源secret，它的设计初衷是为了解决容器在访问外部网络或外部资源时验证的问题，例如访问一个Git仓库，连接一个数据库，设置一些密码配置等，需要额外验证的场景Secret存储了敏感数据,例如能允许容器接受请求的权限令牌。通过将Harbor的用户信息与K8s的Secret相关联，即达成了两者的集成。步骤如下：
在Harbor中创建创建用户，项目，将项目设置为私有。
将创建的用户加入到项目中，设置用户的角色为开发者或者为项目管理员。确保该账户具有拉取该仓库镜像的权限。
创建K8s下的Secret，其中secret中的用户名、密码和邮箱地址信息为在Harbor中创建的用户的信息。
在此过程中需要注意的是，第三步中创建的secret，对应的用户必须在Harbor的对应私库中有下载镜像的权限，否则应用部署时会报无法下载镜像。
举例来说
在Harbor中创建了用户，如userD
在Harbor中创建一个私有项目，如projectA
在Harbor中使用Docker命令行登陆并上传镜像至步骤2中的私有库
在K8s中创建Namespace
在K8s的Namespace中创建SecretC，该Secret对应Harbor中的用户账号userD
使用Harbor私库中的镜像在K8s的Namespace中部署应用，指定镜像下载时使用上面创建的SecretC
如果只需要能够拉取Harbor的镜像在K8s中部署应用，Harbor中的userD需要在projectA中有最低权限的访客成员角色。
Harbor与K8s集成的代码实践
imagePullSecret在K8s中用来保存镜像仓库的认证信息，以方便Kubelet在启动Pod时，能够获得镜像仓库的认证信息，确保能Kubelet够有权限从镜像仓库中下载Pod所需的镜像。