滑动窗口算法思想

滑动窗口算法思想是非常重要的一种思想,可以用来解决数组,字符串的子元素问题。它可以将嵌套循环的问题,转换为单层循环问题,降低时间复杂度,提高效率。 滑动窗口的思想非常简单,它将子数组(子字符串)理解成一个滑动的窗口,然后将这个窗口在数组上滑动,在窗口滑动的过程中,左边会出一个元素,右边会进一个元素,然后只需要计算当前窗口内的元素值即可。 可用滑动窗口思想解决的问

权限系统的设计模式

权限系统的设计模式 ACL RBAC ABAC ACL(Access Control List):访问权限列表 如: user1–>AC1 user1–>AC2 user2–>AC1 此时权限汇总成一个列表 这种设计最常见的应用就是文件系统的权限设计,如微软的NTFS 对权限控制比较分散,不便于管理,比如无法简单地将一组文件设置统一的权限开放给指定的一群用户 RBAC(Role Base Access Control):基于角色的权限控制 与ACL 对比 RBAC不用给用户单个分配权限,只用指向对应的角色就会

Kubelet实现原理

kubelet 主要功能 在kubernetes集群中,每个Node节点都会启动kubelet进程,用来处理Master节点下发到本节点的任务,管理Pod和其中的容器。 pod 管理 Kubelet 以 PodSpec 的方式工作。PodSpec 是描述一个 Pod 的 YAML 或 JSON 对象。 kubelet 采用一组通过各种机制提供的 PodSpecs(主要通过 apiserver),并确保这些 PodSpecs 中描述的 Pod 正常健康运行。 官方提供了4中方式来获取容器信息

使用Docker安装GitLab

安装GitLab gitlab 镜像分为两个版本: gitlab-ce 社区版 gitlab-ee 企业收费版 这里使用社区版则可,直接安装官方镜像,目前(2020/1/14)官方镜像大小约1.8G,如果你没有设置Docker镜像源,Docker会默认从国外Docker官方Hub去拉去进行,速度难以让人接受,参考「Centos7安装docker-ce」一文进行设置。 拉取gitlab-ce源 docker pull gitlab/gitlab-ce:latest 运行Gitlab 下

docker网络

安装Docker时,它会自动创建三个网络,bridge(创建容器默认连接到此网络)、 none 、host 网络模式 简介 Host 容器将不会虚拟出自己的网卡,配置自己的IP等,而是使用宿主机的IP和端口。 Bridge 此模式会为每一个容器分配、设置IP等,并将容器连接到一个docker0虚拟网桥,通过docker0网桥以及Iptables nat表配置与宿主机通信。 None 该模式关闭了容器的网络功

Namespace和Cgroup

容器其实就是一种特殊的进程 为什么使用容器? 容器虚拟化可以更高效地构建应用,也更容易管理维护。 左图是虚拟机的工作原理,右图是Docker,所示: 容器的核心技术是Cgroup和Namespace,在此基础上还有一些其他工具共同构成容器技术。 容器是宿主机上的进程: 容器技术通过 Namespace 实现资源隔离 通过Cgroup实现资源控制 通过rootfs实现文件系统隔离 容器引擎自身的特

Kubernetes port类型

k8s有几种port类型,分别是TargetPort,ContainerPort,NodePort,Port,那么该怎么区别她们呢,各自的使用场景又是什么呢,接下来这篇文章给你分析一下。 ContainerPort ContainerPort表示你使用的镜像需要开放的端口。例如,mysql 服务需要暴露 3306 端口,redis 暴露 6379 端口 apiVersion: v1 kind: ReplicationController metadata: name: redis-master labels: name: redis-master spec: replicas: 1 selector: name: redis-master template: metadata: labels: name: redis-master spec: containers: - name: master image: kubeguide/redis-master ports:

Kubernetes网络模型

关于 Pod 如何接入网络这件事情,Kubernetes 做出了明确的选择。具体来说,Kubernetes 要求所有的网络插件实现必须满足如下要求: 所有的 Pod 可以与任何其他 Pod 直接通信,无需使用 NAT 映射(network address translation) 所有节点可以与所有 Pod 直接通信,无需使用 NAT 映射 Pod 内部获取到的 IP 地址与其他 Pod 或节点与其通信时的 IP 地址是同一个 在这些限制条件下,需要解决如下

Kubernetes中的Service与Ingress

Service 必须了解的一点是 Service 的访问信息在 Kubernetes 集群内是有效的,集群之外是无效的。 Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service,应用可以方便地实现服务发现和负载均衡。对于Service 的工作原理请参考:https://time.geekbang.org/column/article/68636 当需要从集群外部访问k8s里的服务的时候,

go并发小练习

package main import "fmt" func add(a, b int) { var c = a + b fmt.Printf("%d + %d = %d", a, b, c) } func main() { go add(1, 2) } 在这段代码中包含了两个协程,一个是显式的,通过 go 关键字声明的这条语句,表示启用一个新的协程来处理加法运算,另一个是隐式的,即 main 函数本身也是运行在一个主协程中,该协程和调用 add 函数的子协程是并发运行的两个协程,就好比从 go 关键字开始,从主协程中叉出一条新路。 和之前不使用协程的方式相比,由此也引入了不确定