k8s 学习杂记

  • note from 白话Kubernetes入门实践

初始化快捷命令 alias k=kubectl

export do=”–dry-run=client -o yaml” # 用于输出应用模板

一键水平扩展资源 kubectl autoscale deployment foo –min=2 –max=10

从Cronjob中复制一次性Job kubectl create job –from=cronjob/

列出制定serviceaccount的权限 kubectl -n auth can-i --list --as system:serviceaccount::

注解资源标识

To add annotation

kubectl annotate / foo=bar

To remove annotation

kubectl annotate / foo-

列出集群中所有的端点 kubectl get ep -A

按时间字段排序列出所有的事件 kubectl get events –sort-by=”.lastTimestamp”

列出集群中所有的Warning事件 kubectl get events -w –field-selector=type=Warning -A

13、映射远程端口到本地 kubectl port-forward svc/ :

16、快速创建无状态服务资源的模板 kubectl create deploy nginx-deployment –image=nginx –dry-run=client -o yaml

ref: https://getk8e.zhubai.love/posts/2172932249929457664

=====

pick central time == central coordinator decentralized time = Truetime/HLC

Borg、Omega and Kubernetes

Borg manage long-running services and batch jobs core a shared persistent store via API (k8s, applies higher-level versioning, validation, semantics, and policy, in support of a more diverse array of clients)

container: the first container just isolation of root file system, jail of namespaces => cgroups resource isolation gives better utilzation. mordern container = isolation mechanism + image. docker daemon and docker image registry.

application oriented infra data center from machine to app-oriented.

ref: https://blog.devops.dev/kubernetes-complete-reference-badbc2ed9834

=== note from ma 最近的趋势是heterogenous HW 计算迭代很快，存贮比较慢。现在网络好，计算和存贮分离也可以接受

Data Center Topology tor top of rack switch, L2 switch, multi-layer of router

管理数据中心的machine.

screenshot of the cluster definalities

how is cluster management different? HA Scalable Fault Tolerance Distributed Entities to manage

What’s native service? CNCF Fault tolerance, Multi-tenancy, container based, namedspace, declare resource demand

Borg/Autopilot/Kubernetes

Pod Disruption Budget Stateful info should be written to Spanner / BigTable etc.

Priority check Borg.

Quota: resource reservation part of admission control

service discovery Name

workload failure detection liveness probe

===== software can be cheap. business logic is tie 1 class.

当系统组件越来越小，新的从未需要思考的问题开始出现。从只有一台大机器部署所有东西，组件全在一个进程或者jvm里，不需要考虑patial failure的世界里走出来，你需要面对很多新的问题和挑战： 我的service，程序，应该部署在那里？我用的一个文件不小心和另外一个程序重名，而他们恰巧部署在一台机器怎么办？不小心把过多的东西部署在了一台机器上怎么办？一台不知道部署了什么的机器突然挂了怎么办？我service部署好了，我的其他组件怎么能找到它？把需要相互通信的机器的ip机器名都配置好了，突然要增加机器或者减少机器，或者更换机器怎么办？service正在服务我想要更新程序怎么办？我rollout了一个bug结果所有的node上的服务都挂了怎么办？…. 微服务的architecture比之前集中式的设计难上n多个档次，很多原先进程中的deterministic 同步方法调用，都将会被替换成跨service的远程调用。而分布式系统是non-deterministic的。这就好比给你一种cpu，它有99.99%的概率1+1返回2，而0.01%的概率1+1返回一个随机数. 在只有这种cpu的情况下，我需要你以100%的稳定性实现你原来的系统

我们发现在微服务环境中，有很多共有问题是可以统一解决的。它们包括： Service discovery: 让你的程序轻松获得任何其他组件的logical地址，即使这个组件真实的运行node换了100遍。 Scaling up/down: 自动根据负载增加和减少机器，互联网公司最最基本需求 Load balancing:负载均衡自动均衡到不同的机器 Self healing: 组件由于任何原因(比如网断了，机器挂了)挂了都没问题，自动在另外的机器来启动。 Leader election Security 等 而Container Orchestrators则提供了抽象和方便的工具来让程序员更简单和轻松的应对微服务构架下，我们遇到的各种难题。这就好比当多核成为趋势，多线程编程就成为程序员基本素质一样。而当我们的时代前进到这里, Container Orchestrators终将成为另外一种基础知识成为程序员的必备技能。所以即使你不喜欢Kubernetes，那么你也必然需要另一种类似的东西来解决Orchestration的问题；而解法都是类似的。

而Container Orchestrators则提供了抽象和方便的工具来让程序员更简单和轻松的应对微服务构架下，我们遇到的各种难题。这就好比当多核成为趋势，多线程编程就成为程序员基本素质一样。而当我们的时代前进到这里, Container Orchestrators终将成为另外一种基础知识成为程序员的必备技能。所以即使你不喜欢Kubernetes，那么你也必然需要另一种类似的东西来解决Orchestration的问题；而解法都是类似的

Kubernetes是Google开源的目前最成功的Container Orchestrators, 它可以提供上文中所提到的各种新“基础服务”，向application隐藏infrastructure,隐藏硬件事实。使得程序员只需要声明deployment和管理的“想达到的效果”，而不用自己去思考deployment和operation的细节。有了Kubernetes 的帮助，普普通通的SDE-II甚至SDE-I都将可以较轻松的应对复杂混乱的分布式环境开发。而Kubernetes In Action是一本非常非常对初学者友好的书，里边提供了非常有代入感的非常细致的例子和各种操作的范例，内容也比较详尽。而这些例子都是真真实实大型互联网公司中建造和维护service所遇到的核心问题和应对的best practise。比如Readiness Probe，liveness Probe, Blue/Green deployment, rolling rollout, Load Balance, auto-scaling.

商业需求开始在系统设计中变成特等公民。微服务开始代替SOA登上历史舞台，抽象了硬件资源的Container和Container Orchestrators必定将大放光彩。然而！ 分布式系统的搭建还是太难了(需要大量的知识积累和设计实现精力)。。。我们需要新的抽象，基础服务来隔离这些复杂度，培养大量可以基于”这些新基础”（而不必理解这些新基础的实现细节）就可以实现复杂分布式业务系统的SDE，让SDE resource使用在真正能够提供业务价值的application上(比如科学模型的建立)，而不是一遍遍去用相同的手段去处理这些繁琐的细节。我们需要更高一层的Programming model，基础问题需要从关注使用多少内存，使用多少硬盘，怎么做网络通信这些更底层的细节。升级到考虑什么时候使用sync，什么时候必须要注意failure tolerance，liveness和safety怎么做trade-off，什么时候使用state，什么时候使用CRDT，什么时候需要幂等，怎么做partition如何设计partitionkey，思考云环境和分布式环境的“新基础思考因素”。另一方面，当需求开始在系统设计中变成特等公民，意味着PM们可以更加轻松的去释放自己的想象力，爆炸的无限灵活的业务需求开始涌现。进一步冲击着老的基础设施。其中，以关系数据库为核心的集中式的储存成为必定要谢幕的构架思路。“数据不应被它的储存形式所束缚”成为不断开拓人类科技边界的工程师们的共识。灵活到爆炸的业务需求导致了对灵活的数据表现形式的强烈需求(关系,rang K/V, hash K/V,全文检索, elastic search, data warehousing, inmem cache,数据流, 文件)，新的问题当然也随之而来: 我们如何保证所有的数据在不同的储存层之间保持consistent呢？如何解决这个问题成为了分布式系统设计的关键因素之一， 而我们貌似只有2种选择：基于XA(eXtended Architecture), 2PC的，不能failure tolerance的强consistency 或者no consistency at all, 容忍多种的数据可能不一样。我们需要一个更好的解。。。。（这条线也暂且按下不表）

DDIA就非常不错呀，还可以顺着每章的引用去深入的学习！，hadoop the definition guide，hbase the definition guide，zookeeper，高性能spark那本，这些讲工具的书也很容易理解，不过这些书一般很长，内容不够精炼。想深入研究，不是浅尝辄止的话，读论文打好基础对之后学什么都会有加速效果。这样的话可以看paxos，google的大数据三篇，spanner，flink和spark的论文。然后不管看什么论文，有不熟悉的地方，就根据引用往回看可以把一条线都学了。分布式算法理论的好书不多，感觉Distributed Systems: An Algorithmic Approach, Second Edition，这本还不错。

作者：阿莱克西斯 链接：https://zhuanlan.zhihu.com/p/41606961 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

=====

无状态计算的问题：

  1. how to find service。
  2. after locate the service后，具体发给哪个instance？
  3. how to mgr config? each service have instances with auto scaling
  4. how to orchestrate service? vs. 单机系统所有功能都在一个process中，内部协调简单
  5. how to exact one progressing? 调用失败就要重发。
  6. how to avoid cascading failure? rate limit & circute break
Written on January 3, 2023