Microsoft实习手记第一篇 Kubernetes

-

0x00

在实习的第一个Sprint，了解了组里的业务，我这块主要建立在k8s集群上，在这个之上构建分布式机器学习的平台。
由于之前只接触过本机的docker，一时之间触及k8s集群还是有点懵，这里记录些工具和概念。

0x01 概念

k8s集群中的机器们被分成两种 Master Server 和 Kubernetes Node.

ref: https://www.cnblogs.com/menkeyi/p/7134460.html

“Node是Kubernetes中的工作节点，最开始被称为minion。一个Node可以是VM或物理机。每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理，Node节点上的服务包括Docker、kubelet和kube-proxy” ----say by here
这里引入了一个新的概念Pod。
一言以蔽之：“Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程” ----say by here

这里的Pod里面运行着具体的container，终于触碰到我的已有认知了，这里的container就是docker概念里的那个，通过image产生的实例.

Pod: 为什么说Pod是k8s创建或部署的最小单位呢？因为它不直接控制container。一个pod可以包含一个或者多个container，然后k8s直接控制的是pod。在我接触的case中，一个pod包含了多个container，其中一个是负责业务逻辑的，另外的会负责pull data, pull code dependancy..., 以及挂载存储等等。


因为单个pod是一个脆弱的资源，可能因为某些原因crash。对于集群来说需要有个东西来维护它的扩展，重启等等事情。这部分工作不是pod自己来做的，而是交给Controller。
Controller: 可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。包含一个或者多个Pod的Controller示例：

通常，Controller会用你提供的Pod Template来创建相应的Pod。并且我手头的工作后续也会针对具体业务逻辑cover 这部分的生命周期管理。可能会复写一些controller的逻辑。

Deployment: 这是一个更方便的，和controller做一样事情的，概念。
它为Pod和Replica Set（升级版的 Replication Controller）提供声明式更新。你只需要在 Deployment 中描述您想要的目标状态是什么，Deployment controller 就会帮您将 Pod 和ReplicaSet 的实际状态改变到您的目标状态。您可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。 ----say from here

ref:


Service: 因为pod是脆弱的，可能因为各种各样的原因挂掉，重启之后它的ip地址又会变化，这点对于pod的用户(可以是其他pod)很不友好所以Kubernetes Service 定义了这样一种抽象: 一个 Pod 的逻辑分组，一种可以访问它们的策略 (通常称为微服务)
一个 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样， Service 定义可以基于 POST 方式，请求 apiserver 创建新的实例 ----say from here

Namespace: 对于一个k8s的集群而言，它的用户可能是一个公司的不同团队。不同团队可以通过指定自己的namespace来和其他进行区分。大多数Kubernetes资源（例如pod、services、replication controllers或其他）都在某些Namespace中，但Namespace资源本身并不在Namespace中。而低级别资源（如Node和persistentVolumes）不在任何Namespace中。Events是一个例外：它们可能有也可能没有Namespace，具体取决于Events的对象。ref: http://docs.kubernetes.org.cn/242.html#Namespace

0x02 工具

kubectl: 这是一个本地对远端k8s集群的访问和控制工具，其配置文件路径: ~/.kube/config

minikube: 一个用于在本地搭建k8s集群的工具，这个搭起的工具通常作为学习/实验环境。
ref: https://k8smeetup.github.io/docs/home/

kustomize / helm: 配置文件yaml管理工具
https://aisensiy.github.io/2018/11/27/helm-and-kustomize/
地点: Suzhou, Jiangsu, China

Comments

Post a Comment

Popular posts from this blog

Malware Report: iauzzy.exe

-
Image
Malware report of iauzzy.exe Summary This malware will create a file named ‘qqt.exe’ under the %WinDir%. This is the exact malicious executable file. qqt.exe is able to communicate to the ‘Command & Control’ server via IRC. The controller behind is able to execute any code; reboot the infected machine; clean the malware itself, etc.
Read more

Malware Report: withme.exe

-
Image
Malware Report withme.exe Summary This Withme.exe will drop a executable file ‘A-1980682553.exe’ to the location %AppData%. Also It will add itself to runonce registry. This is the exact malware. It’s able to communicate with C2 server, which domain is ‘sexwithme.info’ wia port 6667.
Read more

根因分析之iDice 文章复现

-
Image
1 Abstract  原文 给的场景是对于大规模集群的运维，当一条issue被上报的时候，通常会带上一些attribute，比如时间，软件版本，所处的国家，城市，具体在哪个机房，浏览器，操作系统等等。 在平时的时候，每天的上报的issue数量应该是差不多的，但有些时候，报错数量会突然上升，对于运维人员定位到问题所在往往很花时间。背后的问题可能是某个attribute或者某几个attributes的组合，文章称为effective combination。 这里通过三个步骤来从所有的attribute combination中找到最后可能引发报错激增的effective combination。 2 Challenge 想要找到所有effective combination的最暴力的做法就是，枚举所有attribute combination，然后以某种方式来衡量它对于总体issue激增的关系。 这里主要的问题在于搜索空间过大，本文最大的创新在于对搜索空间的剪枝。如果一共有m个attribute，那一共的组合方式就是(2^m - 1)种 3 Approach 文章把整个流程主要分成三个步骤（用做剪枝）和一个结果排序 Impact based Pruning: 基于影响的用户量做剪枝（不含时间信息） Change Detection based Pruning: 基于时间线上的突变来剪枝（时间序列处理） Isolation Power based Pruning: 计算一个类似信息熵增益的值来判断这个attribute combination的区分度 Result Ranking: 计算这个attribute combination对于全局的显著性 3.1 Impact based Pruning 对于一个effective combination而言，它必须影响足够多的用户。所以这里定一个threshold来过滤掉一些不可能的参数组合。（排除时间这个维度） 这里的目的是 寻找closed frequent itemsets，文章里的没有对算法进行详细描述，就说用BFS-based closed itemset mining algorithm。 在复现的时候，我先用了现成的找 frequent itemset 的算法（ Apriori /FPMax/ FPGrowt
Read more