跳到主要内容

41.propose

PR #838​

Proposed roadmap to 1.0

Kubernetes Roadmap

Updated August 8, 2014

This document is intended to capture the set of features, docs, and patterns that we feel are required to call Kubernetes “feature complete” for a 1.0 release candidate.  This list does not emphasize the bug fixes and stabilization that will be required to take it all the way to production ready. This is a living document, and is certainly open for discussion.

APIs​

  1. Versioned APIs:  Manage APIs for master components and kubelets with explicit versions, version-specific conversion routines, and component-to-component version checking.
  2. Deprecation policy: Declare the project’s intentions with regards to expiring and removing features and interfaces.
  3. Compatibility policy: Declare the project’s intentions with regards to saved state and live upgrades of components.
  4. Component-centric APIs:  Clarify which types belong in each component’s API and which ones are truly common.
  5. Idempotency: Whenever possible APIs must be idempotent.
  6. Container restart policy: Policy for each pod or container stating whether and when it should be restarted upon termination.
  7. Life cycle events/hooks and notifications: Notify containers about what is happening to them.
  8. Re-think the network parts of the API: Find resolution on the the multiple issues around networking.
  9. Using the host network
  10. Representation of Ports in the Manifest structure
  11. Utility of HostPorts in ip-per-pod
  12. Scenarios where IP-per-pod is hard or impossible
  13. Port collisions between services
  14. Provide a model for durable local volumes including scheduler constraints.
  15. Auth[nz] and ACLs: Have a plan for how identity, authentication, and authorization will fit in to the API, as well as ACLs for objects, and basic resource quotas.
  16. Projects / subdivision: Have a plan for how security isolation between users could apply in terms of grouping resources (calling out explicitly) and whether there is a common model that could apply to Kubernetes

Factoring and pluggability​

  1. Pluggable scheduling: Cleanly separate the scheduler from the apiserver.
  2. Pluggable naming and discovery: Call-outs or hooks to enable external naming systems.
  3. Pluggable volumes: Allow new kinds of data sources as volumes.
  4. Replication controller: Make replication controller a standalone entity in the master stack.
  5. Pod templates: Proposal to make pod templates a first-class API object, rather than an artifact of replica controller
  6. Auto-scaling controller: Make a sizing controller, canary controller. Probably want to have a source of QPS and error rate information for an application first.
  7. Pluggable authentication, with identity and authorization being dependent on auth[nz] above

Cluster features​

  1. Minion death: Cleanly handle the loss of a minion.
  2. Configure DNS: Provide DNS service for k8s running pods, containers and services. Auto-populate it with the things we know.
  3. Resource requirements and scheduling: Use knowledge of resources available and resources required to do better scheduling.
  4. IP-per-service: Proposal to make proxies less necessary.
  5. Pod spreading: Scheduler spreads pods for higher availability.
  6. Basic deployment tools.
  7. Standard mechanisms for deploying k8s on k8s with a clear strategy for reusing the infrastructure for self-host.

Node features​

  1. Container termination reasons: Capture and report exit codes and other termination reasons.
  2. Container status snippets: Capture and report app-specific status snippets.
  3. Garbage collect old container images: Clean up old docker images that consume local disk. Maybe a TTL on images.
  4. Container logs: Expose stdout/stderr from containers without users having to SSH into minions.  Needs a rotation policy to avoid disks getting filled.
  5. Container performance information: Capture and report performance data for each container.
  6. Plan for working with upstream Docker on the Docker-daemon-kills-all-children-on-exit problem.

Global features​

  1. True IP-per-pod: Get rid of last remnants of shared port spaces.
  2. Input validation: Stop bad input as early as possible.
  3. Error propagation: Report problems reliably and consistently.

Patterns and specifications​

  1. Naming/discovery: Make it possible for common patterns to operate:
  2. Master-elected services
  3. DB replicas
  4. Sharded services
  5. Worker pools
  6. Interconnection of services: expand / decompose the service pattern to take into account:
  7. Network boundaries - private / public
  8. Allow external or shared load balancers across a deployment to be registered (name based balancers)
  9. Registering DNS name balancing
  10. Networking: Well documented recipes for settings where the networking is not the same as GCE.
  11. Health-checking: Specification for how it works and best practices.
  12. Logging: Well documented recipes for setting up log collection.
  13. Rolling updates: Demo and best practices for live application upgrades.
  14. Have a plan for how higher level deployment / update concepts should / should not fit into Kubernetes
  15. Minion requirements: Document the requirements and integrations between kubelet and minion machine environments.

APIs 这部分列出了应该在 Kubernetes 中包含的 API 功能。例如，要有版本化的 APIs，声明项目关于过期和移除功能的策略，明确各组件的 API 类型等。

Factoring and pluggability 这部分详细介绍了如何清晰地将不同的组件分离，以便于插件化。例如，将调度器从 API 服务器中分离，允许使用新类型的数据源作为卷等。

Cluster features 集群特性主要涉及到集群的管理和维护。例如，处理节点丢失的问题，为 k8s 运行的 pod、容器和服务提供 DNS 服务等。

Node features 节点特性主要描述了节点应具有的功能。例如，捕获和报告容器终止的原因，捕获和报告每个容器的性能数据等。

Global features 全局特性包括一些影响整个 Kubernetes 系统的功能。例如，每个 pod 有真正的 IP，尽早阻止错误的输入等。

Patterns and specifications 这部分主要描述了一些常见的模式和规范，例如命名/发现，服务的互连，网络设置，健康检查等。

PR#848​

Breakup the registry package into separate packages.

Currently all registry implementations live in a single package, 目前所有 registry 实现都存在于单个包中，

which makes it bit harder to maintain. The different registry 这使得维护起来有点困难。不同的 registry

implementations do not follow the same coding style and naming 实现不遵循相同的编码样式和命名

conventions, which makes the code harder to read. 约定，这使得代码更难阅读。

Breakup the registry package into smaller packages based on 根据

the registry implementation. Refactor the registry packages registry 实现。重构registry包

to follow a similar coding style and naming convention. 遵循类似的编码样式和命名约定。

This patch does not introduce any changes in behavior. 此修补程序不会引入任何行为更改。

PR#842​

Extract RESTHandler and allow API grouping

提出 apigroup 改变，首先看下 issue635

  • propose a group of api rest resources be called a "api group" (better names welcome) 建议将一组 API REST 资源称为“API 组”
  • in code, ensure that an apiserver "master" can be created from multiple independent "api groups" with no coupling between groups 在代码中，确保可以从多个独立的“API 组”创建 APISERVER“主服务器”，并且组之间没有耦合
  • define a policy for how and where "experimental" features can be prototyped in the master branc 定义一个策略，用于在主分支中如何以及在何处对“实验性”功能进行原型设计

PR #378​

Use godep to manage dependencie

PR #856​

Set CreationTimestamp in each storage implementatio

这是一个关于处理时间的实用工具包。首先，它定义了一个类型 Time，它是对 time.Time 类型的封装。这样做的原因是为了处理关于JSON和YAML格式的序列化和反序列化。

下面是这个包的主要部分的简要说明：

Date、Now、Unix 都是工厂方法，这些方法返回一个新的 Time 对象。这些方法只是对 time 包的相应方法的封装。

Rfc3339Copy 返回一个新的 Time 对象，它的时间是在秒级精度上复制的。

UnmarshalJSON 是一个实现了 json.Unmarshaler 接口的方法。当从JSON解码数据到 Time 类型的对象时，这个方法会被调用。它首先检查输入是否为"null"，然后试图解析一个RFC3339格式的时间字符串。

MarshalJSON 是一个实现了 json.Marshaler 接口的方法。当将 Time 类型的对象编码为JSON时，这个方法会被调用。如果时间对象是零值，那么这个方法会返回"null"，否则它会返回一个RFC3339格式的时间字符串。

SetYAML 和 GetYAML 是实现了 yaml.Setter 和 yaml.Getter 接口的方法。这两个方法的作用与 UnmarshalJSON 和 MarshalJSON 类似，但是它们是用于处理YAML数据的。

这个 util 包的主要用途是为了处理和存储时间数据，尤其是在需要以 JSON 或 YAML 格式进行编码和解码的场景中。

PR#888​

Allow kubecfg to parse other types via register function

This allows registering other types with kubecfg so they can be parsed in the command line as well.

PR #780​

Add a utility for doing master election via etcd.

保持系统中的一致性，在分布式系统中选举出一个 master 节点来做决策和管理。

NewEtcdMasterElector 创建了一个新的基于 etcd 的 MasterElector 对象。

etcdMasterElector 结构体是 MasterElector 的实现。它使用 etcd 作为后端，使用一个 done 通道来处理停止选举的情况，使用一个 events 通道来发送和接收选举事件。

Elect 方法启动了 master 选举过程，然后返回当前选举实例。

run 方法是主选举循环，它处理选举事件和选举错误。

extendMaster、becomeMaster 和 handleMaster 是执行选举过程的核心函数。extendMaster 尝试延长 master 锁的租约。becomeMaster 尝试成为新的 master。handleMaster 获取当前 master，如果没有 master，它会尝试成为新的 master，如果它是 master，它会尝试延长租约。

master 方法是主选举循环，它会不断地处理 master 锁，直到 done 通道被关闭。

Stop 方法关闭 done 通道，停止 master 选举。

选举最新教程： https://cit965.com/docs/k8s-course-code-new/leader-election%20copy

作业​

本节课作业，我们可以学习了解一下最新的leader-election，从而更好的理解源码。

1.查看nange最新教程​

https://cit965.com/docs/k8s-course-code-new/leader-election%20copy/

理解通过创建锁对象Lease，定期续期租约来实现leader-election的原理。

2.查看示例源码​

git clone https://github.com/mayankshah1607/k8s-leader-election.git

3.部署服务​

cd k8s-leader-election

//下载镜像
docker pull docker.io/mayankshah1607/leaderelection

//创建RBAC 获取leases对象操作权限
kubectl apply -f rbac.yaml

//创建3个pod 模拟leader-election ,传入参数--lease-name=my-lease
kubectl apply -f deploy.yaml

4.观察现象，理解leader-election​

root@master:/home/ubuntu/nange/41/k8s-leader-election-master# k apply -f rbac.yaml 
serviceaccount/leaderelection-sa created
role.rbac.authorization.k8s.io/leaderelection-role created
rolebinding.rbac.authorization.k8s.io/leaderelection-rolebinding created

root@master:/home/ubuntu/nange/41/k8s-leader-election-master# k apply -f deploy.yaml 
deployment.apps/leaderelection created

root@master:/home/ubuntu/nange/41/k8s-leader-election-master# k get pod -o wide
NAME                              READY   STATUS    RESTARTS       AGE   IP             NODE     NOMINATED NODE   READINESS GATES
leaderelection-5b7c688b46-2r8tw   1/1     Running   0              21s   10.244.0.26    master   <none>           <none>
leaderelection-5b7c688b46-ltvgh   1/1     Running   0              22s   10.244.2.110   node2    <none>           <none>
leaderelection-5b7c688b46-vbptf   1/1     Running   0              21s   10.244.1.135   node1    <none>           <none>


//查看日志，可以看到leaderelection-5b7c688b46-2r8tw 成为了leader
root@master:/home/ubuntu# k logs -f leaderelection-5b7c688b46-2r8tw
I0623 03:47:57.783545       1 leaderelection.go:248] attempting to acquire leader lease default/my-lease...
I0623 03:47:57.893714       1 leaderelection.go:258] successfully acquired lease default/my-lease
I0623 03:47:57.893830       1 main.go:57] still the leader!


root@master:/home/ubuntu# k logs -f leaderelection-5b7c688b46-ltvgh
I0623 03:48:06.888687       1 leaderelection.go:248] attempting to acquire leader lease default/my-lease...
I0623 03:48:06.908235       1 main.go:60] new leader is %sleaderelection-5b7c688b46-2r8tw


root@master:/home/ubuntu# k logs -f leaderelection-5b7c688b46-vbptf
I0623 03:48:07.777826       1 leaderelection.go:248] attempting to acquire leader lease default/my-lease...
I0623 03:48:07.793994       1 main.go:60] new leader is %sleaderelection-5b7c688b46-2r8tw

5.我们删除leader，看是否会重新选举成功​

root@master:/home/ubuntu# k delete pod leaderelection-5b7c688b46-2r8tw
pod "leaderelection-5b7c688b46-2r8tw" deleted



//可以看到 leaderelection-5b7c688b46-ltvgh这个POD成为了新的leader
root@master:/home/ubuntu# k logs -f leaderelection-5b7c688b46-ltvgh
I0623 03:48:06.888687       1 leaderelection.go:248] attempting to acquire leader lease default/my-lease...
I0623 03:48:06.908235       1 main.go:60] new leader is %sleaderelection-5b7c688b46-2r8tw
I0623 03:52:47.018802       1 leaderelection.go:258] successfully acquired lease default/my-lease
I0623 03:52:47.019003       1 main.go:57] still the leader!

root@master:/home/ubuntu# k logs -f leaderelection-5b7c688b46-vbptf
I0623 03:48:07.777826       1 leaderelection.go:248] attempting to acquire leader lease default/my-lease...
I0623 03:48:07.793994       1 main.go:60] new leader is %sleaderelection-5b7c688b46-2r8tw

I0623 03:52:48.165811       1 main.go:60] new leader is %sleaderelection-5b7c688b46-ltvgh

6. 大家可以通过查看示例源码和通过实际实验来理解 leader-election​