Update localization guidelines (#10485)
* Update localization guidelines for language labels
Continuing work
Continuing work
Continuing work
More work in progress
Add local OWNERS folders
Add an OWNERS file to Chinese
Remove shortcode for repos
Add Japanese
Alphabetize languages, change weights accordingly
More updates
Add Korean in Korean
Add English to languageName
Feedback from gochist
Move Chinese content from cn/ to zh/
Move OWNERS from cn/ to zh/
Resolve merge conflicts by updating from master
Add files back in to prep for resolution
After rebase on upstream/master, remove files
Review and update localization guidelines
Feedback from gochist, tnir, cstoku
Add a trailing newline to content/ja/OWNERS
Add a trailing newline to content/zh/OWNERS
Drop requirement for GH repo project
Clarify language about forks/branches
Edits and typos
Remove a shortcode specific to a multi-repo language setup
Update aliases and owners
Add explicit OWNERS for content/en
Migrate content from Chinese repo, update regex in config.toml
Remove untranslated strings
Add trailing newline to content/en/OWNERS
Add trailing newlines to OWNERS files
add Jaguar project description (#10433)
* add Jaguar project description
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight.
Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
* Minor newline tweak
blog post for azure vmss (#10538)
Add microk8s to pick-right-solution.md (#10542)
* Add microk8s to pick-right-solution.md
Microk8s is a single-command installation of upstream Kubernetes on any Linux and should be included in the list of local-machine solutions.
* capitalized Istio
Add microk8s to foundational.md (#10543)
* Add microk8s to foundational.md
Adding microk8s as credible and stable alternative to get started with Kubernetes on a local machine. This is especially attractive for those not wanting to incur the overhead of running a VM for a local cluster.
* Update foundational.md
Thank you for your suggestions! LMK if this works now?
* Rewrote first paragraph
And included a bullet list of features of microk8s
* Copyedit
fix typo (#10545)
Fix the kubectl subcommands links. (#10550)
Signed-off-by: William Zhang <warmchang@outlook.com>
Fix command issue (#10515)
Signed-off-by: mooncake <xcoder@tenxcloud.com>
remove imported community files per issue 10184 (#10501)
networking.md: Markdown fix (#10498)
Fix front matter, federation command-line tools (#10500)
Clean up glossary entry (#10399)
update slack link (#10536)
typo in StatefulSet docs (#10558)
fix discription about horizontal pod autoscale (#10557)
Remove redundant symbols (#10556)
Fix issue #10520 (#10554)
Signed-off-by: William Zhang <warmchang@outlook.com>
Update api-concepts.md (#10534)
Revert "Fix command issue (#10515)"
This reverts commit c02a7fb9f9.
Update memory-constraint-namespace.md (#10530)
update memory request to 100MiB corresponding the yaml content
Blog: Introducing Volume Snapshot Alpha for Kubernetes (#10562)
* blog post for azure vmss
* snapshot blog post
Resolve merge conflicts in OWNERS*
Minor typo fix (#10567)
Not sure what's supposed to be here, proposing removing it.
* Feedback from gochist
Tweaks to feedback
* Feedback from ClaudiaJKang
This commit is contained in:
Zach Corleissen
committed by
k8s-ci-robot
k8s-ci-robot
parent
753f57f0e6
commit
abcee2dccd
@@ -0,0 +1,182 @@
|
||||
<!-- ---
|
||||
title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
|
||||
date: 2016-04-18
|
||||
slug: kubernetes-network-policy-apis
|
||||
url: /blog/2016/04/Kubernetes-Network-Policy-APIs
|
||||
--- -->
|
||||
|
||||
---
|
||||
title: "SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
|
||||
date: 2016-04-18
|
||||
slug: kubernetes-network-policy-apis
|
||||
url: /blog/2016/04/Kubernetes-Network-Policy-APIs
|
||||
---
|
||||
|
||||
<!-- _Editor’s note: This week we’re featuring [Kubernetes Special Interest Groups](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)); Today’s post is by the Network-SIG team describing network policy APIs coming in 1.3 - policies for security, isolation and multi-tenancy._ -->
|
||||
|
||||
编者按：这一周，我们的封面主题是 [Kubernetes 特别兴趣小组](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs))；今天的文章由网络兴趣小组撰写，来谈谈 1.3 版本中即将出现的网络策略 API - 针对安全，隔离和多租户的策略。
|
||||
|
||||
<!-- The [Kubernetes network SIG](https://kubernetes.slack.com/messages/sig-network/) has been meeting regularly since late last year to work on bringing network policy to Kubernetes and we’re starting to see the results of this effort. -->
|
||||
|
||||
自去年下半年起，[Kubernetes 网络特别兴趣小组](https://kubernetes.slack.com/messages/sig-network/)经常定期开会，讨论如何将网络策略带入到 Kubernetes 之中，现在，我们也将慢慢看到这些工作的成果。
|
||||
|
||||
<!-- One problem many users have is that the open access network policy of Kubernetes is not suitable for applications that need more precise control over the traffic that accesses a pod or service. Today, this could be a multi-tier application where traffic is only allowed from a tier’s neighbor. But as new Cloud Native applications are built by composing microservices, the ability to control traffic as it flows among these services becomes even more critical. -->
|
||||
|
||||
很多用户经常会碰到的一个问题是， Kubernetes 的开放访问网络策略并不能很好地满足那些需要对 pod 或服务( service )访问进行更为精确控制的场景。今天，这个场景可以是在多层应用中，只允许临近层的访问。然而，随着组合微服务构建原生应用程序潮流的发展，如何控制流量在不同服务之间的流动会别的越发的重要。
|
||||
|
||||
<!-- In most IaaS environments (both public and private) this kind of control is provided by allowing VMs to join a ‘security group’ where traffic to members of the group is defined by a network policy or Access Control List (ACL) and enforced by a network packet filter. -->
|
||||
|
||||
在大多数的（公共的或私有的） IaaS 环境中，这种网络控制通常是将 VM 和“安全组”结合，其中安全组中成员的通信都是通过一个网络策略或者访问控制表（ Access Control List, ACL ）来定义，以及借助于网络包过滤器来实现。
|
||||
|
||||
<!-- The Network SIG started the effort by identifying [specific use case scenarios](https://docs.google.com/document/d/1blfqiH4L_fpn33ZrnQ11v7LcYP0lmpiJ_RaapAPBbNU/edit?pref=2&pli=1#) that require basic network isolation for enhanced security. Getting the API right for these simple and common use cases is important because they are also the basis for the more sophisticated network policies necessary for multi-tenancy within Kubernetes. -->
|
||||
|
||||
“网络特别兴趣小组”刚开始的工作是确定 [特定的使用场景](https://docs.google.com/document/d/1blfqiH4L_fpn33ZrnQ11v7LcYP0lmpiJ_RaapAPBbNU/edit?pref=2&pli=1#) ，这些用例需要基本的网络隔离来提升安全性。
|
||||
让这些API恰如其分地满足简单、共通的用例尤其重要，因为它们将为那些服务于 Kubernetes 内多租户，更为复杂的网络策略奠定基础。
|
||||
|
||||
<!-- From these scenarios several possible approaches were considered and a minimal [policy specification](https://docs.google.com/document/d/1qAm-_oSap-f1d6a-xRTj6xaH1sYQBfK36VyjB5XOZug/edit) was defined. The basic idea is that if isolation were enabled on a per namespace basis, then specific pods would be selected where specific traffic types would be allowed. -->
|
||||
|
||||
根据这些应用场景，我们考虑了集中不同的方法，然后定义了一个最简[策略规范](https://docs.google.com/document/d/1qAm-_oSap-f1d6a-xRTj6xaH1sYQBfK36VyjB5XOZug/edit)。
|
||||
基本的想法是，如果是根据命名空间的不同来进行隔离，那么就会根据所被允许的流量类型的不同，来选择特定的 pods 。
|
||||
|
||||
<!-- The simplest way to quickly support this experimental API is in the form of a ThirdPartyResource extension to the API Server, which is possible today in Kubernetes 1.2. -->
|
||||
|
||||
快速支持这个实验性 API 的办法是往 API 服务器上加入一个 `ThirdPartyResource` 扩展，这在 Kubernetes 1.2 就能办到。
|
||||
|
||||
<!-- If you’re not familiar with how this works, the Kubernetes API can be extended by defining ThirdPartyResources that create a new API endpoint at a specified URL. -->
|
||||
|
||||
如果你还不是很熟悉这其中的细节， Kubernetes API 是可以通过定义 `ThirdPartyResources` 扩展在特定的 URL 上创建一个新的 API 端点。
|
||||
|
||||
#### third-party-res-def.yaml
|
||||
|
||||
```
|
||||
kind: ThirdPartyResource
|
||||
apiVersion: extensions/v1beta1
|
||||
metadata:
|
||||
- name: network-policy.net.alpha.kubernetes.io
|
||||
description: "Network policy specification"
|
||||
versions:
|
||||
- name: v1alpha1
|
||||
```
|
||||
|
||||
```
|
||||
$kubectl create -f third-party-res-def.yaml
|
||||
```
|
||||
|
||||
<!-- This will create an API endpoint (one for each namespace): -->
|
||||
这条命令会创建一个 API 端点（每个命名空间各一个）:
|
||||
|
||||
```
|
||||
/net.alpha.kubernetes.io/v1alpha1/namespace/default/networkpolicys/
|
||||
```
|
||||
|
||||
<!-- Third party network controllers can now listen on these endpoints and react as necessary when resources are created, modified or deleted. _Note: With the upcoming release of Kubernetes 1.3 - when the Network Policy API is released in beta form - there will be no need to create a ThirdPartyResource API endpoint as shown above._ -->
|
||||
|
||||
|
||||
第三方网络控制器可以监听这些端点，根据资源的创建，修改或者删除作出必要的响应。
|
||||
_注意：在接下来的 Kubernetes 1.3 发布中， Network Policy API 会以 beta API 的形式出现，这也就不需要像上面那样，创建一个 `ThirdPartyResource` API 端点了。_
|
||||
|
||||
<!-- Network isolation is off by default so that all pods can communicate as they normally do. However, it’s important to know that once network isolation is enabled, all traffic to all pods, in all namespaces is blocked, which means that enabling isolation is going to change the behavior of your pods -->
|
||||
|
||||
网络隔离默认是关闭的，因而，所有的 pods 之间可以自由地通信。
|
||||
然而，很重要的一点是，一旦开通了网络隔离，所有命名空间下的所有 pods 之间的通信都会被阻断，换句话说，开通隔离会改变 pods 的行为。
|
||||
|
||||
<!-- Network isolation is enabled by defining the _network-isolation_ annotation on namespaces as shown below: -->
|
||||
|
||||
网络隔离可以通过定义命名空间， `net.alpha.kubernetes.io` 里的 `network-isolation` 注释来开通关闭:
|
||||
|
||||
```
|
||||
net.alpha.kubernetes.io/network-isolation: [on | off]
|
||||
```
|
||||
|
||||
<!-- Once network isolation is enabled, explicit network policies **must be applied** to enable pod communication. -->
|
||||
|
||||
一旦开通了网络隔离，**一定需要使用** 显示的网络策略来允许 pod 间的通信。
|
||||
|
||||
<!-- A policy specification can be applied to a namespace to define the details of the policy as shown below: -->
|
||||
|
||||
一个策略规范可以被用到一个命名空间中，来定义策略的细节（如下所示）：
|
||||
|
||||
```
|
||||
POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/
|
||||
{
|
||||
"kind": "NetworkPolicy",
|
||||
"metadata": {
|
||||
"name": "pol1"
|
||||
},
|
||||
"spec": {
|
||||
"allowIncoming": {
|
||||
"from": [
|
||||
{
|
||||
"pods": {
|
||||
"segment": "frontend"
|
||||
}
|
||||
}
|
||||
],
|
||||
"toPorts": [
|
||||
{
|
||||
"port": 80,
|
||||
"protocol": "TCP"
|
||||
}
|
||||
]
|
||||
},
|
||||
"podSelector": {
|
||||
"segment": "backend"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- In this example, the ‘ **tenant-a** ’ namespace would get policy ‘ **pol1** ’ applied as indicated. Specifically, pods with the **segment** label ‘ **backend** ’ would allow TCP traffic on port 80 from pods with the **segment** label ‘ **frontend** ’ to be received. -->
|
||||
|
||||
在这个例子中，**tenant-a** 空间将会使用 **pol1** 策略。
|
||||
具体而言，带有 **segment** 标签为 **backend** 的 pods 会允许 **segment** 标签为 **frontend** 的 pods 访问其端口 80 。
|
||||
|
||||
|
||||
<!-- Today, [Romana](http://romana.io/), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) and [Calico](http://projectcalico.org/) support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)). -->
|
||||
|
||||
|
||||
今天，[Romana](http://romana.io/), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) 以及 [Calico](http://projectcalico.org/) 都已经支持在命名空间和pods中使用网络策略。
|
||||
而 Cisco 和 VMware 也在努力实现支持之中。
|
||||
Romana 和 Calico 已经在最近的 KubeCon 中展示了如何在 Kubernetes 1.2 下使用这些功能。
|
||||
你可以在这里看到他们的演讲：
|
||||
[Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([幻灯片](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)),
|
||||
[Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([幻灯片](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).
|
||||
|
||||
<!-- **How does it work?** -->
|
||||
|
||||
**这是如何工作的**
|
||||
|
||||
<!-- Each solution has their their own specific implementation details. Today, they rely on some kind of on-host enforcement mechanism, but future implementations could also be built that apply policy on a hypervisor, or even directly by the network itself. -->
|
||||
|
||||
每套解决方案都有自己不同的具体实现。尽管今天，他们都借助于每种主机上（ on-host ）的实现机制，但未来的实现可以通过将策略使用在 hypervisor 上，亦或是直接使用到网络本身上来达到同样的目的。
|
||||
|
||||
<!-- External policy control software (specifics vary across implementations) will watch the new API endpoint for pods being created and/or new policies being applied. When an event occurs that requires policy configuration, the listener will recognize the change and a controller will respond by configuring the interface and applying the policy. The diagram below shows an API listener and policy controller responding to updates by applying a network policy locally via a host agent. The network interface on the pods is configured by a CNI plugin on the host (not shown). -->
|
||||
|
||||
外部策略控制软件（不同实现各有不同）可以监听 pods 创建以及新加载策略的 API 端点。
|
||||
当产生一个需要策略配置的事件之后，监听器会确认这个请求，相应的，控制器会配置接口，使用该策略。
|
||||
下面的图例展示了 API 监视器和策略控制器是如何通过主机代理在本地应用网络策略的。
|
||||
这些 pods 的网络接口是使用过主机上的 CNI 插件来进行配置的（并未在图中注明）。
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- If you’ve been holding back on developing applications with Kubernetes because of network isolation and/or security concerns, these new network policies go a long way to providing the control you need. No need to wait until Kubernetes 1.3 since network policy is available now as an experimental API enabled as a ThirdPartyResource. -->
|
||||
|
||||
如果你一直受网络隔离或安全考虑的困扰，而犹豫要不要使用 Kubernetes 来开发应用程序，这些新的网络策略将会极大地解决你这方面的需求。并不需要等到 Kubernetes 1.3 ，现在就可以通过 `ThirdPartyResource` 的方式来使用这个实现性 API 。
|
||||
|
||||
|
||||
<!-- If you’re interested in Kubernetes and networking, there are several ways to participate - join us at:
|
||||
|
||||
- Our [Networking slack channel](https://kubernetes.slack.com/messages/sig-network/)
|
||||
- Our [Kubernetes Networking Special Interest Group](https://groups.google.com/forum/#!forum/kubernetes-sig-network) email list -->
|
||||
|
||||
如果你对 Kubernetes 和网络感兴趣，可以通过下面的方式参与、加入其中：
|
||||
|
||||
- 我们的[网络 slack channel](https://kubernetes.slack.com/messages/sig-network/)
|
||||
- 我们的[Kubernetes 特别网络兴趣小组](https://groups.google.com/forum/#!forum/kubernetes-sig-network) 邮件列表
|
||||
|
||||
<!-- The Networking “Special Interest Group,” which meets bi-weekly at 3pm (15h00) Pacific Time at [SIG-Networking hangout](https://zoom.us/j/5806599998). -->
|
||||
|
||||
网络“特别兴趣小组”每两周下午三点（太平洋时间）开会，地址是[SIG-Networking hangout](https://zoom.us/j/5806599998).
|
||||
|
||||
_--Chris Marino, Co-Founder, Pani Networks_
|
||||
@@ -0,0 +1,129 @@
|
||||
<!-- ---
|
||||
title: " How to deploy secure, auditable, and reproducible Kubernetes clusters on AWS "
|
||||
date: 2016-04-15
|
||||
slug: kubernetes-on-aws_15
|
||||
url: /blog/2016/04/Kubernetes-On-Aws_15
|
||||
--- -->
|
||||
|
||||
---
|
||||
title: " 如何在AWS上部署安全，可审计，可复现的k8s集群 "
|
||||
date: 2016-04-15
|
||||
slug: kubernetes-on-aws_15
|
||||
url: /blog/2016/04/Kubernetes-On-Aws_15
|
||||
---
|
||||
|
||||
<!-- _Today’s guest post is written by Colin Hom, infrastructure engineer at [CoreOS](https://coreos.com/), the company delivering Google’s Infrastructure for Everyone Else (#GIFEE) and running the world's containers securely on CoreOS Linux, Tectonic and Quay._
|
||||
|
||||
_Join us at [CoreOS Fest Berlin](https://coreos.com/fest/), the Open Source Distributed Systems Conference, and learn more about CoreOS and Kubernetes._ -->
|
||||
|
||||
_今天的客座文章是由Colin Hom撰写，[CoreOS](https://coreos.com/)的基础架构工程师。CoreOS致力于推广谷歌的基础架构模式（Google’s Infrastructure for Everyone Else， #GIFEE），让全世界的容器都能在CoreOS Linux, Tectonic 和 Quay上安全运行。_
|
||||
|
||||
_加入到我们的[柏林CoreOS盛宴](https://coreos.com/fest/)，这是一个开源分布式系统主题的会议，在这里可以了解到更多关于CoreOS和Kubernetes的信息。_
|
||||
|
||||
<!-- At CoreOS, we're all about deploying Kubernetes in production at scale. Today we are excited to share a tool that makes deploying Kubernetes on Amazon Web Services (AWS) a breeze. Kube-aws is a tool for deploying auditable and reproducible Kubernetes clusters to AWS, currently used by CoreOS to spin up production clusters. -->
|
||||
|
||||
在CoreOS, 我们一直都是在生产环境中大规模部署Kubernetes。今天我们非常兴奋地想分享一款工具，它能让你的Kubernetes生产环境大规模部署更加的轻松。Kube-aws这个工具可以用来在AWS上部署可审计，可复现的k8s集群，而CoreOS本身就在生产环境中使用它。
|
||||
|
||||
<!-- Today you might be putting the Kubernetes components together in a more manual way. With this helpful tool, Kubernetes is delivered in a streamlined package to save time, minimize interdependencies and quickly create production-ready deployments. -->
|
||||
|
||||
也许今天，你更多的可能是用手工的方式来拼接Kubernetes组件。但有了这个工具之后，Kubernetes可以流水化地打包、交付，节省时间，减少了相互间的依赖，更加快捷地实现生产环境的部署。
|
||||
|
||||
<!-- A simple templating system is leveraged to generate cluster configuration as a set of declarative configuration templates that can be version controlled, audited and re-deployed. Since the entirety of the provisioning is by [AWS CloudFormation](https://aws.amazon.com/cloudformation/) and cloud-init, there’s no need for external configuration management tools on your end. Batteries included! -->
|
||||
|
||||
借助于一个简单的模板系统，来生成集群配置，这么做是因为一套声明式的配置模板可以版本控制，审计以及重复部署。而且，由于整个创建过程只用到了[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 和 cloud-init，你也就不需要额外用到其它的配置管理工具。开箱即用！
|
||||
|
||||
<!-- To skip the talk and go straight to the project, check out [the latest release of kube-aws](https://github.com/coreos/coreos-kubernetes/releases), which supports Kubernetes 1.2.x. To get your cluster running, [check out the documentation](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html). -->
|
||||
|
||||
如果要跳过演讲，直接了解这个项目，可以看看[kube-aws的最新发布](https://github.com/coreos/coreos-kubernetes/releases)，支持Kubernetes 1.2.x。如果要部署集群，可以参考[文档]](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html).
|
||||
|
||||
<!-- **Why kube-aws? Security, auditability and reproducibility** -->
|
||||
**为什么是kube-aws？安全，可审计，可复现**
|
||||
|
||||
<!-- Kube-aws is designed with three central goals in mind. -->
|
||||
Kube-aws设计初衷有三个目标。
|
||||
|
||||
<!-- **Secure** : TLS assets are encrypted via the [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) before being embedded in the CloudFormation JSON. By managing [IAM policy](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) for the KMS key independently, an operator can decouple operational access to the CloudFormation stack from access to the TLS secrets. -->
|
||||
|
||||
**安全** : TLS 资源在嵌入到CloudFormation JSON之前，通过[AWS 秘钥管理服务](https://aws.amazon.com/kms/)加密。通过单独管理KMS密钥的[IAM 策略](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)，可以将CloudFormation栈的访问与TLS秘钥的访问分离开。
|
||||
|
||||
<!-- **Auditable** : kube-aws is built around the concept of cluster assets. These configuration and credential assets represent the complete description of the cluster. Since KMS is used to encrypt TLS assets, you can feel free to check your unencrypted stack JSON into version control as well! -->
|
||||
|
||||
**可审计** : kube-aws是围绕集群资产的概念来创建。这些配置和账户资产是对集群的完全描述。由于KMS被用来加密TLS资产，因而可以无所顾忌地将未加密的CloudFormation栈 JSON签入到版本控制服务中。
|
||||
|
||||
<!-- **Reproducible** : The _--export_ option packs your parameterized cluster definition into a single JSON file which defines a CloudFormation stack. This file can be version controlled and submitted directly to the CloudFormation API via existing deployment tooling, if desired. -->
|
||||
|
||||
**可重复** : _--export_ 选项将参数化的集群定义打包成一整个JSON文件，对应一个CloudFormation栈。这个文件可以版本控制，然后，如果需要的话，通过现有的部署工具直接提交给CloudFormation API。
|
||||
|
||||
<!-- **How to get started with kube-aws** -->
|
||||
**如何开始用kube-aws**
|
||||
|
||||
<!-- On top of this foundation, kube-aws implements features that make Kubernetes deployments on AWS easier to manage and more flexible. Here are some examples. -->
|
||||
在此基础之上，kube-aws也实现了一些功能，使得在AWS上部署Kubernetes集群更加容易，灵活。下面是一些例子。
|
||||
|
||||
<!-- **Route53 Integration** : Kube-aws can manage your cluster DNS records as part of the provisioning process. -->
|
||||
**Route53集成** : Kube-aws 可以管理你的集群DNS记录，作为配置过程的一部分。
|
||||
|
||||
cluster.yaml
|
||||
```
|
||||
externalDNSName: my-cluster.kubernetes.coreos.com
|
||||
|
||||
createRecordSet: true
|
||||
|
||||
hostedZone: kubernetes.coreos.com
|
||||
|
||||
recordSetTTL: 300
|
||||
```
|
||||
|
||||
<!-- **Existing VPC Support** : Deploy your cluster to an existing VPC. -->
|
||||
**现有VPC支持** : 将集群部署到现有的VPC上。
|
||||
|
||||
cluster.yaml
|
||||
```
|
||||
vpcId: vpc-xxxxx
|
||||
|
||||
routeTableId: rtb-xxxxx
|
||||
```
|
||||
|
||||
<!-- **Validation** : Kube-aws supports validation of cloud-init and CloudFormation definitions, along with any external resources that the cluster stack will integrate with. For example, here’s a cloud-config with a misspelled parameter: -->
|
||||
**验证** : kube-aws 支持验证 cloud-init 和 CloudFormation定义，以及集群栈会集成用到的外部资源。例如，下面就是一个cloud-config，外带一个拼写错误的参数：
|
||||
|
||||
userdata/cloud-config-worker
|
||||
```
|
||||
#cloud-config
|
||||
|
||||
coreos:
|
||||
|
||||
flannel:
|
||||
interrface: $private\_ipv4
|
||||
etcd\_endpoints: {{ .ETCDEndpoints }}
|
||||
```
|
||||
|
||||
$ kube-aws validate
|
||||
|
||||
\> Validating UserData...
|
||||
Error: cloud-config validation errors:
|
||||
UserDataWorker: line 4: warning: unrecognized key "interrface"
|
||||
|
||||
<!-- To get started, check out the [kube-aws documentation](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html). -->
|
||||
考虑如何起步？看看[kube-aws 文档](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html)！
|
||||
|
||||
<!-- **Future Work** -->
|
||||
**未来的工作**
|
||||
|
||||
<!-- As always, the goal with kube-aws is to make deployments that are production ready. While we use kube-aws in production on AWS today, this project is pre-1.0 and there are a number of areas in which kube-aws needs to evolve. -->
|
||||
一如既往，kube-aws的目标是让生产环境部署更加的简单。尽管我们现在在AWS下使用kube-aws进行生产环境部署，但是这个项目还是pre-1.0，所以还有很多的地方，kube-aws需要考虑、扩展。
|
||||
|
||||
<!-- **Fault tolerance** : At CoreOS we believe Kubernetes on AWS is a potent platform for fault-tolerant and self-healing deployments. In the upcoming weeks, kube-aws will be rising to a new challenge: surviving the [Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey) – control plane and all! -->
|
||||
**容错** : CoreOS坚信 Kubernetes on AWS是强健的平台，适于容错、自恢复部署。在接下来的几个星期，kube-aws将会迎接新的考验：混世猴子（[Chaos Monkey](https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey)）测试 - 控制平面以及全部！
|
||||
|
||||
<!-- **Zero-downtime updates** : Updating CoreOS nodes and Kubernetes components can be done without downtime and without interdependency with the correct instance replacement strategy. -->
|
||||
**零停机更新** : 更新CoreOS节点和Kubernetes组件不需要停机，也不需要考虑实例更新策略（instance replacement strategy）的影响。
|
||||
|
||||
<!-- A [github issue](https://github.com/coreos/coreos-kubernetes/issues/340) tracks the work towards this goal. We look forward to seeing you get involved with the project by filing issues or contributing directly. -->
|
||||
有一个[github issue](https://github.com/coreos/coreos-kubernetes/issues/340)来追踪这些工作进展。我们期待你的参与，提交issue，或是直接贡献。
|
||||
|
||||
<!-- _Learn more about Kubernetes and meet the community at [CoreOS Fest Berlin](https://coreos.com/fest/) - May 9-10, 2016_ -->
|
||||
_想要更多地了解Kubernetes，来[柏林CoreOS盛宴](https://coreos.com/fest/)看看，- 五月 9-10, 2016_
|
||||
|
||||
<!-- _– Colin Hom, infrastructure engineer, CoreOS_ -->
|
||||
_– Colin Hom, 基础架构工程师, CoreOS_
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "Principles of Container-based Application Design"
|
||||
date: 2018-03-15
|
||||
slug: principles-of-container-app-design
|
||||
url: /blog/2018/03/Principles-Of-Container-App-Design
|
||||
---
|
||||
|
||||
<!-- It's possible nowadays to put almost any application in a container and run it. Creating cloud-native applications, however—containerized applications that are automated and orchestrated effectively by a cloud-native platform such as Kubernetes—requires additional effort. Cloud-native applications anticipate failure; they run and scale reliably even when their infrastructure experiences outages. To offer such capabilities, cloud-native platforms like Kubernetes impose a set of contracts and constraints on applications. These contracts ensure that applications they run conform to certain constraints and allow the platform to automate application management. -->
|
||||
|
||||
现如今，几乎所有的的应用程序都可以在容器中运行。但创建云原生应用，通过诸如 Kubernetes 的云原生平台更有效地自动化运行、管理容器化的应用却需要额外的工作。
|
||||
云原生应用需要考虑故障；即使是在底层架构发生故障时也需要可靠地运行。
|
||||
为了提供这样的功能，像 Kubernetes 这样的云原生平台需要向运行的应用程序强加一些契约和约束。
|
||||
这些契约确保应用可以在符合某些约束的条件下运行，从而使得平台可以自动化应用管理。
|
||||
|
||||
<!-- I've outlined [seven principles][1]for containerized applications to follow in order to be fully cloud-native. -->
|
||||
|
||||
我已经为容器化应用如何之为云原生应用概括出了[七项原则][1]。
|
||||
|
||||
| ----- |
|
||||
| ![][2] |
|
||||
| Container Design Principles |
|
||||
|
||||
|
||||
<!-- These seven principles cover both build time and runtime concerns. -->
|
||||
|
||||
这里所述的七项原则涉及到构建时和运行时，两类关注点。
|
||||
|
||||
<!-- #### Build time -->
|
||||
#### 构建时
|
||||
|
||||
<!-- * **Single Concern:** Each container addresses a single concern and does it well.
|
||||
* **Self-Containment:** A container relies only on the presence of the Linux kernel. Additional libraries are added when the container is built.
|
||||
* **Image Immutability:** Containerized applications are meant to be immutable, and once built are not expected to change between different environments. -->
|
||||
|
||||
* **单一关注点：** 每个容器只解决一个关注点，并且完成的很好。
|
||||
* **自包含：** 一个容器只依赖Linux内核。额外的库要求可以在构建容器时加入。
|
||||
* **镜像不变性：** 容器化的应用意味着不变性，一旦构建完成，不需要根据环境的不同而重新构建。
|
||||
|
||||
<!-- #### Runtime -->
|
||||
#### 运行时
|
||||
|
||||
<!-- * **High Observability:** Every container must implement all necessary APIs to help the platform observe and manage the application in the best way possible.
|
||||
* **Lifecycle Conformance:** A container must have a way to read events coming from the platform and conform by reacting to those events.
|
||||
* **Process Disposability:** Containerized applications must be as ephemeral as possible and ready to be replaced by another container instance at any point in time.
|
||||
* **Runtime Confinement:** Every container must declare its resource requirements and restrict resource use to the requirements indicated. -->
|
||||
|
||||
* **高可观测性：** 每个容器必须实现所有必要的 API 来帮助平台以最好的方式来观测、管理应用。
|
||||
* **生命周期一致性：** 一个容器必须要能从平台中获取事件信息，并作出相应的反应。
|
||||
* **进程易处理性：** 容器化应用的寿命一定要尽可能的短暂，这样，可以随时被另一个容器所替换。
|
||||
* **运行时限制：** 每个容器都必须要声明自己的资源需求，并将资源使用限制在所需要的范围之内。
|
||||
|
||||
<!-- The build time principles ensure that containers have the right granularity, consistency, and structure in place. The runtime principles dictate what functionalities must be implemented in order for containerized applications to possess cloud-native function. Adhering to these principles helps ensure that your applications are suitable for automation in Kubernetes. -->
|
||||
|
||||
编译时原则保证了容器拥有合适的粒度，一致性以及结构。运行时原则明确了容器化必须要实现那些功能才能成为云原生函数。遵循这些原则可以帮助你的应用适应 Kubernetes 上的自动化。
|
||||
|
||||
<!-- The white paper is freely available for download: -->
|
||||
|
||||
白皮书可以免费下载：
|
||||
|
||||
<!-- To read more about designing cloud-native applications for Kubernetes, check out my [Kubernetes Patterns][3] book. -->
|
||||
|
||||
想要了解更多关于如何面向 Kubernetes 设计云原生应用，可以看看我的 [Kubernetes 模式][3] 一书。
|
||||
|
||||
<!-- — [Bilgin Ibryam][4], Principal Architect, Red Hat -->
|
||||
|
||||
— [Bilgin Ibryam][4], 首席架构师, Red Hat
|
||||
|
||||
Twitter:
|
||||
Blog: [http://www.ofbizian.com][5]
|
||||
Linkedin:
|
||||
|
||||
<!-- Bilgin Ibryam (@bibryam) is a principal architect at Red Hat, open source committer at ASF, blogger, author, and speaker. He is the author of Camel Design Patterns and Kubernetes Patterns books. In his day-to-day job, Bilgin enjoys mentoring, training and leading teams to be successful with distributed systems, microservices, containers, and cloud-native applications in general. -->
|
||||
|
||||
Bilgin Ibryam (@bibryam) 是 Red Hat 的一名首席架构师， ASF 的开源贡献者，博主，作者以及演讲者。
|
||||
他是 Camel 设计模式、 Kubernetes 模式的作者。在他的日常生活中，他非常享受指导、培训以及帮助各个团队更加成功地使用分布式系统、微服务、容器，以及云原生应用。
|
||||
|
||||
[1]: https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper
|
||||
[2]: https://lh5.googleusercontent.com/1XqojkVC0CET1yKCJqZ3-0VWxJ3W8Q74zPLlqnn6eHSJsjHOiBTB7EGUX5o_BOKumgfkxVdgBeLyoyMfMIXwVm9p2QXkq_RRy2mDJG1qEExJDculYL5PciYcWfPAKxF2-DGIdiLw
|
||||
[3]: http://leanpub.com/k8spatterns/
|
||||
[4]: http://twitter.com/bibryam
|
||||
[5]: http://www.ofbizian.com/
|
||||
@@ -0,0 +1,676 @@
|
||||
---
|
||||
|
||||
layout: blog
|
||||
|
||||
title: 'Airflow on Kubernetes (Part 1): A Different Kind of Operator'
|
||||
|
||||
date: 2018-06-28
|
||||
|
||||
title: 'Airflow在Kubernetes中的使用（第一部分）：一种不同的操作器'
|
||||
|
||||
cn-approvers:
|
||||
|
||||
- congfairy
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
Author: Daniel Imberman (Bloomberg LP)
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
作者: Daniel Imberman (Bloomberg LP)
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
|
||||
As part of Bloomberg's continued commitment to developing the Kubernetes ecosystem, we are excited to announce the Kubernetes Airflow Operator; a mechanism for Apache Airflow, a popular workflow orchestration framework to natively launch arbitrary Kubernetes Pods using the Kubernetes API.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
## 介绍
|
||||
|
||||
|
||||
|
||||
作为Bloomberg [继续致力于开发Kubernetes生态系统]的一部分（https://www.techatbloomberg.com/blog/bloomberg-awarded-first-cncf-end-user-award-contributions-kubernetes/），我们很高兴能够宣布Kubernetes Airflow Operator的发布; [Apache Airflow]（https://airflow.apache.org/）的机制，一种流行的工作流程编排框架，使用Kubernetes API可以在本机启动任意的Kubernetes Pod。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
## What Is Airflow?
|
||||
|
||||
|
||||
|
||||
Apache Airflow is one realization of the DevOps philosophy of "Configuration As Code." Airflow allows users to launch multi-step pipelines using a simple Python object DAG (Directed Acyclic Graph). You can define dependencies, programmatically construct complex workflows, and monitor scheduled jobs in an easy to read UI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
## 什么是Airflow?
|
||||
|
||||
|
||||
|
||||
Apache Airflow是DevOps“Configuration As Code”理念的一种实现。 Airflow允许用户使用简单的Python对象DAG（有向无环图）启动多步骤流水线。 您可以在易于阅读的UI中定义依赖关系，以编程方式构建复杂的工作流，并监视调度的作业。
|
||||
|
||||
|
||||
|
||||
<img src =“/ images / blog / 2018-05-25-Airflow-Kubernetes-Operator / 2018-05-25-airflow_dags.png”width =“85％”alt =“Airflow DAGs”/>
|
||||
|
||||
<img src =“/ images / blog / 2018-05-25-Airflow-Kubernetes-Operator / 2018-05-25-airflow.png”width =“85％”alt =“Airflow UI”/>
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
## Why Airflow on Kubernetes?
|
||||
|
||||
|
||||
|
||||
Since its inception, Airflow's greatest strength has been its flexibility. Airflow offers a wide range of integrations for services ranging from Spark and HBase, to services on various cloud providers. Airflow also offers easy extensibility through its plug-in framework. However, one limitation of the project is that Airflow users are confined to the frameworks and clients that exist on the Airflow worker at the moment of execution. A single organization can have varied Airflow workflows ranging from data science pipelines to application deployments. This difference in use-case creates issues in dependency management as both teams might use vastly different libraries for their workflows.
|
||||
|
||||
|
||||
|
||||
To address this issue, we've utilized Kubernetes to allow users to launch arbitrary Kubernetes pods and configurations. Airflow users can now have full power over their run-time environments, resources, and secrets, basically turning Airflow into an "any job you want" workflow orchestrator.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
## 为什么在Kubernetes上使用Airflow?
|
||||
|
||||
|
||||
|
||||
自成立以来，Airflow的最大优势在于其灵活性。 Airflow提供广泛的服务集成，包括Spark和HBase，以及各种云提供商的服务。 Airflow还通过其插件框架提供轻松的可扩展性。但是，该项目的一个限制是Airflow用户仅限于执行时Airflow站点上存在的框架和客户端。单个组织可以拥有各种Airflow工作流程，范围从数据科学流到应用程序部署。用例中的这种差异会在依赖关系管理中产生问题，因为两个团队可能会在其工作流程使用截然不同的库。
|
||||
|
||||
|
||||
|
||||
为了解决这个问题，我们使Kubernetes允许用户启动任意Kubernetes pod和配置。 Airflow用户现在可以在其运行时环境，资源和机密上拥有全部权限，基本上将Airflow转变为“您想要的任何工作”工作流程协调器。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
## The Kubernetes Operator
|
||||
|
||||
|
||||
|
||||
Before we move any further, we should clarify that an Operator in Airflow is a task definition. When a user creates a DAG, they would use an operator like the "SparkSubmitOperator" or the "PythonOperator" to submit/monitor a Spark job or a Python function respectively. Airflow comes with built-in operators for frameworks like Apache Spark, BigQuery, Hive, and EMR. It also offers a Plugins entrypoint that allows DevOps engineers to develop their own connectors.
|
||||
|
||||
|
||||
|
||||
Airflow users are always looking for ways to make deployments and ETL pipelines simpler to manage. Any opportunity to decouple pipeline steps, while increasing monitoring, can reduce future outages and fire-fights. The following is a list of benefits provided by the Airflow Kubernetes Operator:
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
## Kubernetes运营商
|
||||
|
||||
|
||||
|
||||
在进一步讨论之前，我们应该澄清Airflow中的[Operator]（https://airflow.apache.org/concepts.html#operators）是一个任务定义。 当用户创建DAG时，他们将使用像“SparkSubmitOperator”或“PythonOperator”这样的operator分别提交/监视Spark作业或Python函数。 Airflow附带了Apache Spark，BigQuery，Hive和EMR等框架的内置运算符。 它还提供了一个插件入口点，允许DevOps工程师开发自己的连接器。
|
||||
|
||||
|
||||
|
||||
Airflow用户一直在寻找更易于管理部署和ETL流的方法。 在增加监控的同时，任何解耦流程的机会都可以减少未来的停机等问题。 以下是Airflow Kubernetes Operator提供的好处：
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
* Increased flexibility for deployments:
|
||||
|
||||
Airflow's plugin API has always offered a significant boon to engineers wishing to test new functionalities within their DAGs. On the downside, whenever a developer wanted to create a new operator, they had to develop an entirely new plugin. Now, any task that can be run within a Docker container is accessible through the exact same operator, with no extra Airflow code to maintain.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
* 提高部署灵活性：
|
||||
|
||||
Airflow的插件API一直为希望在其DAG中测试新功能的工程师提供了重要的福利。 不利的一面是，每当开发人员想要创建一个新的operator时，他们就必须开发一个全新的插件。 现在，任何可以在Docker容器中运行的任务都可以通过完全相同的运算符访问，而无需维护额外的Airflow代码。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
* Flexibility of configurations and dependencies:
|
||||
|
||||
For operators that are run within static Airflow workers, dependency management can become quite difficult. If a developer wants to run one task that requires SciPy and another that requires NumPy, the developer would have to either maintain both dependencies within all Airflow workers or offload the task to an external machine (which can cause bugs if that external machine changes in an untracked manner). Custom Docker images allow users to ensure that the tasks environment, configuration, and dependencies are completely idempotent.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
* 配置和依赖的灵活性：
|
||||
|
||||
对于在静态Airflow工作程序中运行的operator，依赖关系管理可能变得非常困难。 如果开发人员想要运行一个需要[SciPy]（https://www.scipy.org） 的任务和另一个需要[NumPy]（http://www.numpy.org） 的任务，开发人员必须维护所有Airflow节点中的依赖关系或将任务卸载到其他计算机（如果外部计算机以未跟踪的方式更改，则可能导致错误）。 自定义Docker镜像允许用户确保任务环境，配置和依赖关系完全是幂等的。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
* Usage of kubernetes secrets for added security:
|
||||
|
||||
Handling sensitive data is a core responsibility of any DevOps engineer. At every opportunity, Airflow users want to isolate any API keys, database passwords, and login credentials on a strict need-to-know basis. With the Kubernetes operator, users can utilize the Kubernetes Vault technology to store all sensitive data. This means that the Airflow workers will never have access to this information, and can simply request that pods be built with only the secrets they need.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
* 使用kubernetes Secret以增加安全性：
|
||||
|
||||
处理敏感数据是任何开发工程师的核心职责。 Airflow用户总有机会在严格条款的基础上隔离任何API密钥，数据库密码和登录凭据。 使用Kubernetes运算符，用户可以利用Kubernetes Vault技术存储所有敏感数据。 这意味着Airflow工作人员将永远无法访问此信息，并且可以容易地请求仅使用他们需要的密码信息构建pod。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
# Architecture
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The Kubernetes Operator uses the Kubernetes Python Client to generate a request that is processed by the APIServer (1). Kubernetes will then launch your pod with whatever specs you've defined (2). Images will be loaded with all the necessary environment variables, secrets and dependencies, enacting a single command. Once the job is launched, the operator only needs to monitor the health of track logs (3). Users will have the choice of gathering logs locally to the scheduler or to any distributed logging service currently in their Kubernetes cluster.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
＃架构
|
||||
|
||||
|
||||
|
||||
<img src =“/ images / blog / 2018-05-25-Airflow-Kubernetes-Operator / 2018-05-25-airflow-architecture.png”width =“85％”alt =“Airflow Architecture”/>
|
||||
|
||||
|
||||
|
||||
Kubernetes Operator使用[Kubernetes Python客户端]（https://github.com/kubernetes-client/Python)生成由APIServer处理的请求（1）。 然后，Kubernetes将使用您定义的需求启动您的pod（2）。映像文件中将加载环境变量，Secret和依赖项，执行单个命令。 一旦启动作业，operator只需要监视跟踪日志的状况（3）。 用户可以选择将日志本地收集到调度程序或当前位于其Kubernetes集群中的任何分布式日志记录服务。
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
# Using the Kubernetes Operator
|
||||
|
||||
|
||||
|
||||
## A Basic Example
|
||||
|
||||
|
||||
|
||||
The following DAG is probably the simplest example we could write to show how the Kubernetes Operator works. This DAG creates two pods on Kubernetes: a Linux distro with Python and a base Ubuntu distro without it. The Python pod will run the Python request correctly, while the one without Python will report a failure to the user. If the Operator is working correctly, the passing-task pod should complete, while the failing-task pod returns a failure to the Airflow webserver.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
＃使用Kubernetes Operator
|
||||
|
||||
|
||||
|
||||
##一个基本的例子
|
||||
|
||||
|
||||
|
||||
以下DAG可能是我们可以编写的最简单的示例，以显示Kubernetes Operator的工作原理。 这个DAG在Kubernetes上创建了两个pod：一个带有Python的Linux发行版和一个没有它的基本Ubuntu发行版。 Python pod将正确运行Python请求，而没有Python的那个将向用户报告失败。 如果Operator正常工作，则应该完成“passing-task”pod，而“falling-task”pod则向Airflow网络服务器返回失败。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```Python
|
||||
|
||||
from airflow import DAG
|
||||
|
||||
from datetime import datetime, timedelta
|
||||
|
||||
from airflow.contrib.operators.kubernetes_pod_operator import KubernetesPodOperator
|
||||
|
||||
from airflow.operators.dummy_operator import DummyOperator
|
||||
|
||||
|
||||
default_args = {
|
||||
|
||||
'owner': 'airflow',
|
||||
|
||||
'depends_on_past': False,
|
||||
|
||||
'start_date': datetime.utcnow(),
|
||||
|
||||
'email': ['airflow@example.com'],
|
||||
|
||||
'email_on_failure': False,
|
||||
|
||||
'email_on_retry': False,
|
||||
|
||||
'retries': 1,
|
||||
|
||||
'retry_delay': timedelta(minutes=5)
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
dag = DAG(
|
||||
|
||||
'kubernetes_sample', default_args=default_args, schedule_interval=timedelta(minutes=10))
|
||||
|
||||
start = DummyOperator(task_id='run_this_first', dag=dag)
|
||||
passing = KubernetesPodOperator(namespace='default',
|
||||
|
||||
image="Python:3.6",
|
||||
|
||||
cmds=["Python","-c"],
|
||||
|
||||
arguments=["print('hello world')"],
|
||||
|
||||
labels={"foo": "bar"},
|
||||
|
||||
name="passing-test",
|
||||
|
||||
task_id="passing-task",
|
||||
|
||||
get_logs=True,
|
||||
|
||||
dag=dag
|
||||
|
||||
)
|
||||
|
||||
failing = KubernetesPodOperator(namespace='default',
|
||||
|
||||
image="ubuntu:1604",
|
||||
|
||||
cmds=["Python","-c"],
|
||||
|
||||
arguments=["print('hello world')"],
|
||||
|
||||
labels={"foo": "bar"},
|
||||
|
||||
name="fail",
|
||||
|
||||
task_id="failing-task",
|
||||
|
||||
get_logs=True,
|
||||
|
||||
dag=dag
|
||||
|
||||
)
|
||||
|
||||
passing.set_upstream(start)
|
||||
|
||||
failing.set_upstream(start)
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
## But how does this relate to my workflow?
|
||||
|
||||
|
||||
|
||||
While this example only uses basic images, the magic of Docker is that this same DAG will work for any image/command pairing you want. The following is a recommended CI/CD pipeline to run production-ready code on an Airflow DAG.
|
||||
|
||||
|
||||
|
||||
### 1: PR in github
|
||||
|
||||
Use Travis or Jenkins to run unit and integration tests, bribe your favorite team-mate into PR'ing your code, and merge to the master branch to trigger an automated CI build.
|
||||
|
||||
|
||||
|
||||
### 2: CI/CD via Jenkins -> Docker Image
|
||||
|
||||
|
||||
|
||||
Generate your Docker images and bump release version within your Jenkins build.
|
||||
|
||||
|
||||
|
||||
### 3: Airflow launches task
|
||||
|
||||
|
||||
|
||||
Finally, update your DAGs to reflect the new release version and you should be ready to go!
|
||||
|
||||
-->
|
||||
|
||||
##但这与我的工作流程有什么关系？
|
||||
|
||||
|
||||
|
||||
虽然这个例子只使用基本映像，但Docker的神奇之处在于，这个相同的DAG可以用于您想要的任何图像/命令配对。 以下是推荐的CI / CD管道，用于在Airflow DAG上运行生产就绪代码。
|
||||
|
||||
|
||||
|
||||
### 1：github中的PR
|
||||
|
||||
使用Travis或Jenkins运行单元和集成测试，请您的朋友PR您的代码，并合并到主分支以触发自动CI构建。
|
||||
|
||||
|
||||
|
||||
### 2：CI / CD构建Jenkins - > Docker Image
|
||||
|
||||
|
||||
|
||||
[在Jenkins构建中生成Docker镜像和缓冲版本]（https://getintodevops.com/blog/building-your-first-Docker-image-with-jenkins-2-guide-for-developers）。
|
||||
|
||||
|
||||
|
||||
### 3：Airflow启动任务
|
||||
|
||||
|
||||
|
||||
最后，更新您的DAG以反映新版本，您应该准备好了！
|
||||
|
||||
|
||||
|
||||
```Python
|
||||
|
||||
production_task = KubernetesPodOperator(namespace='default',
|
||||
|
||||
# image="my-production-job:release-1.0.1", <-- old release
|
||||
|
||||
image="my-production-job:release-1.0.2",
|
||||
|
||||
cmds=["Python","-c"],
|
||||
|
||||
arguments=["print('hello world')"],
|
||||
|
||||
name="fail",
|
||||
|
||||
task_id="failing-task",
|
||||
|
||||
get_logs=True,
|
||||
|
||||
dag=dag
|
||||
|
||||
)
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
# Launching a test deployment
|
||||
|
||||
|
||||
|
||||
Since the Kubernetes Operator is not yet released, we haven't released an official helm chart or operator (however both are currently in progress). However, we are including instructions for a basic deployment below and are actively looking for foolhardy beta testers to try this new feature. To try this system out please follow these steps:
|
||||
|
||||
|
||||
|
||||
## Step 1: Set your kubeconfig to point to a kubernetes cluster
|
||||
|
||||
|
||||
|
||||
## Step 2: Clone the Airflow Repo:
|
||||
|
||||
|
||||
|
||||
Run git clone https://github.com/apache/incubator-airflow.git to clone the official Airflow repo.
|
||||
|
||||
|
||||
|
||||
## Step 3: Run
|
||||
|
||||
|
||||
|
||||
To run this basic deployment, we are co-opting the integration testing script that we currently use for the Kubernetes Executor (which will be explained in the next article of this series). To launch this deployment, run these three commands:
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
＃启动测试部署
|
||||
|
||||
|
||||
|
||||
由于Kubernetes运营商尚未发布，我们尚未发布官方[helm](https://helm.sh/) 图表或operator（但两者目前都在进行中）。 但是，我们在下面列出了基本部署的说明，并且正在积极寻找测试人员来尝试这一新功能。 要试用此系统，请按以下步骤操作：
|
||||
|
||||
|
||||
|
||||
##步骤1：将kubeconfig设置为指向kubernetes集群
|
||||
|
||||
|
||||
|
||||
##步骤2：clone Airflow 仓库：
|
||||
|
||||
|
||||
|
||||
运行git clone https：// github.com / apache / incubator-airflow.git来clone官方Airflow仓库。
|
||||
|
||||
|
||||
|
||||
##步骤3：运行
|
||||
|
||||
|
||||
|
||||
为了运行这个基本Deployment，我们正在选择我们目前用于Kubernetes Executor的集成测试脚本（将在本系列的下一篇文章中对此进行解释）。 要启动此部署，请运行以下三个命令：
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/configmaps.yaml
|
||||
|
||||
./scripts/ci/kubernetes/Docker/build.sh
|
||||
|
||||
./scripts/ci/kubernetes/kube/deploy.sh
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
Before we move on, let's discuss what these commands are doing:
|
||||
|
||||
|
||||
|
||||
### sed -ie "s/KubernetesExecutor/LocalExecutor/g" scripts/ci/kubernetes/kube/configmaps.yaml
|
||||
|
||||
|
||||
|
||||
The Kubernetes Executor is another Airflow feature that allows for dynamic allocation of tasks as idempotent pods. The reason we are switching this to the LocalExecutor is simply to introduce one feature at a time. You are more then welcome to skip this step if you would like to try the Kubernetes Executor, however we will go into more detail in a future article.
|
||||
|
||||
|
||||
|
||||
### ./scripts/ci/kubernetes/Docker/build.sh
|
||||
|
||||
|
||||
|
||||
This script will tar the Airflow master source code build a Docker container based on the Airflow distribution
|
||||
|
||||
|
||||
|
||||
### ./scripts/ci/kubernetes/kube/deploy.sh
|
||||
|
||||
|
||||
|
||||
Finally, we create a full Airflow deployment on your cluster. This includes Airflow configs, a postgres backend, the webserver + scheduler, and all necessary services between. One thing to note is that the role binding supplied is a cluster-admin, so if you do not have that level of permission on the cluster, you can modify this at scripts/ci/kubernetes/kube/airflow.yaml
|
||||
|
||||
|
||||
|
||||
## Step 4: Log into your webserver
|
||||
|
||||
|
||||
|
||||
Now that your Airflow instance is running let's take a look at the UI! The UI lives in port 8080 of the Airflow pod, so simply run
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
在我们继续之前，让我们讨论这些命令正在做什么：
|
||||
|
||||
|
||||
|
||||
### sed -ie“s / KubernetesExecutor / LocalExecutor / g”scripts / ci / kubernetes / kube / configmaps.yaml
|
||||
|
||||
|
||||
|
||||
Kubernetes Executor是另一种Airflow功能，允许动态分配任务已解决幂等pod的问题。我们将其切换到LocalExecutor的原因只是一次引入一个功能。如果您想尝试Kubernetes Executor，欢迎您跳过此步骤，但我们将在以后的文章中详细介绍。
|
||||
|
||||
|
||||
|
||||
### ./scripts/ci/kubernetes/Docker/build.sh
|
||||
|
||||
|
||||
|
||||
此脚本将对Airflow主分支代码进行打包，以根据Airflow的发行文件构建Docker容器
|
||||
|
||||
|
||||
|
||||
### ./scripts/ci/kubernetes/kube/deploy.sh
|
||||
|
||||
|
||||
|
||||
最后，我们在您的群集上创建完整的Airflow部署。这包括Airflow配置，postgres后端，webserver +调度程序以及之间的所有必要服务。需要注意的一点是，提供的角色绑定是集群管理员，因此如果您没有该集群的权限级别，可以在scripts / ci / kubernetes / kube / airflow.yaml中进行修改。
|
||||
|
||||
|
||||
|
||||
##步骤4：登录您的网络服务器
|
||||
|
||||
|
||||
|
||||
现在您的Airflow实例正在运行，让我们来看看UI！用户界面位于Airflow pod的8080端口，因此只需运行即可
|
||||
|
||||
|
||||
|
||||
```
|
||||
|
||||
WEB=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep "airflow" | head -1)
|
||||
|
||||
kubectl port-forward $WEB 8080:8080
|
||||
|
||||
```
|
||||
|
||||
<!--
|
||||
|
||||
Now the Airflow UI will exist on http://localhost:8080. To log in simply enter airflow/airflow and you should have full access to the Airflow web UI.
|
||||
|
||||
|
||||
|
||||
## Step 5: Upload a test document
|
||||
|
||||
|
||||
|
||||
To modify/add your own DAGs, you can use kubectl cp to upload local files into the DAG folder of the Airflow scheduler. Airflow will then read the new DAG and automatically upload it to its system. The following command will upload any local file into the correct directory:
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
现在，Airflow UI将存在于http://localhost:8080上。 要登录，只需输入airflow /airflow，您就可以完全访问Airflow Web UI。
|
||||
|
||||
|
||||
|
||||
##步骤5：上传测试文档
|
||||
|
||||
|
||||
|
||||
要修改/添加自己的DAG，可以使用kubectl cp将本地文件上传到Airflow调度程序的DAG文件夹中。 然后，Airflow将读取新的DAG并自动将其上传到其系统。 以下命令将任何本地文件上载到正确的目录中：
|
||||
|
||||
|
||||
|
||||
kubectl cp <local file> <namespace>/<pod>:/root/airflow/dags -c scheduler
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
## Step 6: Enjoy!
|
||||
|
||||
|
||||
|
||||
# So when will I be able to use this?
|
||||
|
||||
|
||||
|
||||
While this feature is still in the early stages, we hope to see it released for wide release in the next few months.
|
||||
|
||||
|
||||
|
||||
# Get Involved
|
||||
|
||||
|
||||
|
||||
This feature is just the beginning of multiple major efforts to improves Apache Airflow integration into Kubernetes. The Kubernetes Operator has been merged into the 1.10 release branch of Airflow (the executor in experimental mode), along with a fully k8s native scheduler called the Kubernetes Executor (article to come). These features are still in a stage where early adopters/contributers can have a huge influence on the future of these features.
|
||||
|
||||
|
||||
|
||||
For those interested in joining these efforts, I'd recommend checkint out these steps:
|
||||
|
||||
|
||||
|
||||
* Join the airflow-dev mailing list at dev@airflow.apache.org.
|
||||
|
||||
* File an issue in Apache Airflow JIRA
|
||||
|
||||
* Join our SIG-BigData meetings on Wednesdays at 10am PST.
|
||||
|
||||
* Reach us on slack at #sig-big-data on kubernetes.slack.com
|
||||
|
||||
|
||||
|
||||
Special thanks to the Apache Airflow and Kubernetes communities, particularly Grant Nicholas, Ben Goldberg, Anirudh Ramanathan, Fokko Dreisprong, and Bolke de Bruin, for your awesome help on these features as well as our future efforts.
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
##步骤6：使用它！
|
||||
|
||||
|
||||
|
||||
#那么我什么时候可以使用它？
|
||||
|
||||
|
||||
|
||||
虽然此功能仍处于早期阶段，但我们希望在未来几个月内发布该功能以进行广泛发布。
|
||||
|
||||
|
||||
|
||||
#参与其中
|
||||
|
||||
|
||||
|
||||
此功能只是将Apache Airflow集成到Kubernetes中的多项主要工作的开始。 Kubernetes Operator已合并到[Airflow的1.10发布分支]（https://github.com/apache/incubator-airflow/tree/v1-10-test）（实验模式中的执行模块），以及完整的k8s本地调度程序称为Kubernetes Executor（即将发布文章）。这些功能仍处于早期采用者/贡献者可能对这些功能的未来产生巨大影响的阶段。
|
||||
|
||||
|
||||
|
||||
对于有兴趣加入这些工作的人，我建议按照以下步骤：
|
||||
|
||||
|
||||
|
||||
*加入airflow-dev邮件列表dev@airflow.apache.org。
|
||||
|
||||
*在[Apache Airflow JIRA]中提出问题（https://issues.apache.org/jira/projects/AIRFLOW/issues/）
|
||||
|
||||
*周三上午10点太平洋标准时间加入我们的SIG-BigData会议。
|
||||
|
||||
*在kubernetes.slack.com上的＃sig-big-data找到我们。
|
||||
|
||||
|
||||
|
||||
特别感谢Apache Airflow和Kubernetes社区，特别是Grant Nicholas，Ben Goldberg，Anirudh Ramanathan，Fokko Dreisprong和Bolke de Bruin，感谢您对这些功能的巨大帮助以及我们未来的努力。
|
||||
@@ -0,0 +1,401 @@
|
||||
---
|
||||
title: 基于IPVS的集群内部负载均衡
|
||||
cn-approvers:
|
||||
- congfairy
|
||||
layout: blog
|
||||
title: 'IPVS-Based In-Cluster Load Balancing Deep Dive'
|
||||
date: 2018-07-09
|
||||
---
|
||||
|
||||
<!--
|
||||
|
||||
Author: Jun Du(Huawei), Haibin Xie(Huawei), Wei Liang(Huawei)
|
||||
|
||||
Editor’s note: this post is part of a series of in-depth articles on what’s new in Kubernetes 1.11
|
||||
|
||||
-->
|
||||
|
||||
作者: Jun Du(华为), Haibin Xie(华为), Wei Liang(华为)
|
||||
|
||||
注意: 这篇文章出自 系列深度文章 介绍 Kubernetes 1.11 的新特性
|
||||
|
||||
<!--
|
||||
|
||||
Introduction
|
||||
|
||||
Per the Kubernetes 1.11 release blog post , we announced that IPVS-Based In-Cluster Service Load Balancing graduates to General Availability. In this blog, we will take you through a deep dive of the feature.
|
||||
|
||||
-->
|
||||
|
||||
介绍
|
||||
|
||||
根据 Kubernetes 1.11 发布的博客文章, 我们宣布基于 IPVS 的集群内部服务负载均衡已达到一般可用性。 在这篇博客中，我们将带您深入了解该功能。
|
||||
|
||||
<!--
|
||||
|
||||
What Is IPVS?
|
||||
|
||||
IPVS (IP Virtual Server) is built on top of the Netfilter and implements transport-layer load balancing as part of the Linux kernel.
|
||||
|
||||
IPVS is incorporated into the LVS (Linux Virtual Server), where it runs on a host and acts as a load balancer in front of a cluster of real servers. IPVS can direct requests for TCP- and UDP-based services to the real servers, and make services of the real servers appear as virtual services on a single IP address. Therefore, IPVS naturally supports Kubernetes Service.
|
||||
|
||||
-->
|
||||
|
||||
什么是 IPVS ?
|
||||
|
||||
IPVS (IP Virtual Server)是在 Netfilter 上层构建的，并作为 Linux 内核的一部分，实现传输层负载均衡。
|
||||
|
||||
IPVS 集成在 LVS（Linux Virtual Server，Linux 虚拟服务器）中，它在主机上运行，并在物理服务器集群前作为负载均衡器。IPVS 可以将基于 TCP 和 UDP 服务的请求定向到真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。 因此，IPVS 自然支持 Kubernetes 服务。
|
||||
|
||||
<!--
|
||||
|
||||
Why IPVS for Kubernetes?
|
||||
|
||||
As Kubernetes grows in usage, the scalability of its resources becomes more and more important. In particular, the scalability of services is paramount to the adoption of Kubernetes by developers/companies running large workloads.
|
||||
|
||||
Kube-proxy, the building block of service routing has relied on the battle-hardened iptables to implement the core supported Service types such as ClusterIP and NodePort. However, iptables struggles to scale to tens of thousands of Services because it is designed purely for firewalling purposes and is based on in-kernel rule lists.
|
||||
|
||||
Even though Kubernetes already support 5000 nodes in release v1.6, the kube-proxy with iptables is actually a bottleneck to scale the cluster to 5000 nodes. One example is that with NodePort Service in a 5000-node cluster, if we have 2000 services and each services have 10 pods, this will cause at least 20000 iptable records on each worker node, and this can make the kernel pretty busy.
|
||||
|
||||
On the other hand, using IPVS-based in-cluster service load balancing can help a lot for such cases. IPVS is specifically designed for load balancing and uses more efficient data structures (hash tables) allowing for almost unlimited scale under the hood.
|
||||
|
||||
-->
|
||||
|
||||
为什么为 Kubernetes 选择 IPVS ?
|
||||
|
||||
随着 Kubernetes 的使用增长，其资源的可扩展性变得越来越重要。特别是，服务的可扩展性对于运行大型工作负载的开发人员/公司采用 Kubernetes 至关重要。
|
||||
|
||||
Kube-proxy 是服务路由的构建块，它依赖于经过强化攻击的 iptables 来实现支持核心的服务类型，如 ClusterIP 和 NodePort。 但是，iptables 难以扩展到成千上万的服务，因为它纯粹是为防火墙而设计的，并且基于内核规则列表。
|
||||
|
||||
尽管 Kubernetes 在版本v1.6中已经支持5000个节点，但使用 iptables 的 kube-proxy 实际上是将集群扩展到5000个节点的瓶颈。 一个例子是，在5000节点集群中使用 NodePort 服务，如果我们有2000个服务并且每个服务有10个 pod，这将在每个工作节点上至少产生20000个 iptable 记录，这可能使内核非常繁忙。
|
||||
|
||||
另一方面，使用基于 IPVS 的集群内服务负载均衡可以为这种情况提供很多帮助。 IPVS 专门用于负载均衡，并使用更高效的数据结构（哈希表），允许几乎无限的规模扩张。
|
||||
|
||||
<!--
|
||||
|
||||
IPVS-based Kube-proxy
|
||||
|
||||
Parameter Changes
|
||||
|
||||
Parameter: --proxy-mode In addition to existing userspace and iptables modes, IPVS mode is configured via --proxy-mode=ipvs. It implicitly uses IPVS NAT mode for service port mapping.
|
||||
|
||||
-->
|
||||
|
||||
基于 IPVS 的 Kube-proxy
|
||||
|
||||
参数更改
|
||||
|
||||
参数: --proxy-mode 除了现有的用户空间和 iptables 模式，IPVS 模式通过--proxy-mode = ipvs 进行配置。 它隐式使用 IPVS NAT 模式进行服务端口映射。
|
||||
|
||||
<!--
|
||||
|
||||
Parameter: --ipvs-scheduler
|
||||
|
||||
A new kube-proxy parameter has been added to specify the IPVS load balancing algorithm, with the parameter being --ipvs-scheduler. If it’s not configured, then round-robin (rr) is the default value.
|
||||
|
||||
- rr: round-robin
|
||||
- lc: least connection
|
||||
- dh: destination hashing
|
||||
- sh: source hashing
|
||||
- sed: shortest expected delay
|
||||
- nq: never queue
|
||||
|
||||
In the future, we can implement Service specific scheduler (potentially via annotation), which has higher priority and overwrites the value.
|
||||
|
||||
-->
|
||||
|
||||
参数: --ipvs-scheduler
|
||||
|
||||
添加了一个新的 kube-proxy 参数来指定 IPVS 负载均衡算法，参数为 --ipvs-scheduler。 如果未配置，则默认为 round-robin 算法（rr）。
|
||||
|
||||
- rr: round-robin
|
||||
- lc: least connection
|
||||
- dh: destination hashing
|
||||
- sh: source hashing
|
||||
- sed: shortest expected delay
|
||||
- nq: never queue
|
||||
|
||||
将来，我们可以实现特定于服务的调度程序（可能通过注释），该调度程序具有更高的优先级并覆盖该值。
|
||||
|
||||
<!--
|
||||
|
||||
Parameter: --cleanup-ipvs Similar to the --cleanup-iptables parameter, if true, cleanup IPVS configuration and IPTables rules that are created in IPVS mode.
|
||||
|
||||
Parameter: --ipvs-sync-period Maximum interval of how often IPVS rules are refreshed (e.g. '5s', '1m'). Must be greater than 0.
|
||||
|
||||
Parameter: --ipvs-min-sync-period Minimum interval of how often the IPVS rules are refreshed (e.g. '5s', '1m'). Must be greater than 0.
|
||||
|
||||
-->
|
||||
|
||||
参数: --cleanup-ipvs 类似于 --cleanup-iptables 参数，如果为 true，则清除在 IPVS 模式下创建的 IPVS 配置和 IPTables 规则。
|
||||
|
||||
参数: --ipvs-sync-period 刷新 IPVS 规则的最大间隔时间（例如'5s'，'1m'）。 必须大于0。
|
||||
|
||||
参数: --ipvs-min-sync-period 刷新 IPVS 规则的最小间隔时间间隔（例如'5s'，'1m'）。 必须大于0。
|
||||
|
||||
<!--
|
||||
|
||||
Parameter: --ipvs-exclude-cidrs A comma-separated list of CIDR's which the IPVS proxier should not touch when cleaning up IPVS rules because IPVS proxier can't distinguish kube-proxy created IPVS rules from user original IPVS rules. If you are using IPVS proxier with your own IPVS rules in the environment, this parameter should be specified, otherwise your original rule will be cleaned.
|
||||
|
||||
-->
|
||||
|
||||
参数: --ipvs-exclude-cidrs 清除 IPVS 规则时 IPVS 代理不应触及的 CIDR 的逗号分隔列表，因为 IPVS 代理无法区分 kube-proxy 创建的 IPVS 规则和用户原始规则 IPVS 规则。 如果您在环境中使用 IPVS proxier 和您自己的 IPVS 规则，则应指定此参数，否则将清除原始规则。
|
||||
|
||||
<!--
|
||||
|
||||
Design Considerations
|
||||
|
||||
IPVS Service Network Topology
|
||||
|
||||
When creating a ClusterIP type Service, IPVS proxier will do the following three things:
|
||||
|
||||
- Make sure a dummy interface exists in the node, defaults to kube-ipvs0
|
||||
- Bind Service IP addresses to the dummy interface
|
||||
- Create IPVS virtual servers for each Service IP address respectively
|
||||
-->
|
||||
|
||||
设计注意事项
|
||||
|
||||
IPVS 服务网络拓扑
|
||||
|
||||
创建 ClusterIP 类型服务时，IPVS proxier 将执行以下三项操作：
|
||||
|
||||
- 确保节点中存在虚拟接口，默认为 kube-ipvs0
|
||||
- 将服务 IP 地址绑定到虚拟接口
|
||||
- 分别为每个服务 IP 地址创建 IPVS 虚拟服务器
|
||||
|
||||
<!--
|
||||
|
||||
Here comes an example:
|
||||
|
||||
# kubectl describe svc nginx-service
|
||||
Name: nginx-service
|
||||
...
|
||||
Type: ClusterIP
|
||||
IP: 10.102.128.4
|
||||
Port: http 3080/TCP
|
||||
Endpoints: 10.244.0.235:8080,10.244.1.237:8080
|
||||
Session Affinity: None
|
||||
|
||||
# ip addr
|
||||
...
|
||||
73: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
|
||||
link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.102.128.4/32 scope global kube-ipvs0
|
||||
valid_lft forever preferred_lft forever
|
||||
|
||||
# ipvsadm -ln
|
||||
IP Virtual Server version 1.2.1 (size=4096)
|
||||
Prot LocalAddress:Port Scheduler Flags
|
||||
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
|
||||
TCP 10.102.128.4:3080 rr
|
||||
-> 10.244.0.235:8080 Masq 1 0 0
|
||||
-> 10.244.1.237:8080 Masq 1 0 0
|
||||
|
||||
-->
|
||||
|
||||
这是一个例子:
|
||||
|
||||
# kubectl describe svc nginx-service
|
||||
Name: nginx-service
|
||||
...
|
||||
Type: ClusterIP
|
||||
IP: 10.102.128.4
|
||||
Port: http 3080/TCP
|
||||
Endpoints: 10.244.0.235:8080,10.244.1.237:8080
|
||||
Session Affinity: None
|
||||
|
||||
# ip addr
|
||||
...
|
||||
73: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
|
||||
link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.102.128.4/32 scope global kube-ipvs0
|
||||
valid_lft forever preferred_lft forever
|
||||
|
||||
# ipvsadm -ln
|
||||
IP Virtual Server version 1.2.1 (size=4096)
|
||||
Prot LocalAddress:Port Scheduler Flags
|
||||
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
|
||||
TCP 10.102.128.4:3080 rr
|
||||
-> 10.244.0.235:8080 Masq 1 0 0
|
||||
-> 10.244.1.237:8080 Masq 1 0 0
|
||||
|
||||
<!--
|
||||
|
||||
Please note that the relationship between a Kubernetes Service and IPVS virtual servers is 1:N. For example, consider a Kubernetes Service that has more than one IP address. An External IP type Service has two IP addresses - ClusterIP and External IP. Then the IPVS proxier will create 2 IPVS virtual servers - one for Cluster IP and another one for External IP. The relationship between a Kubernetes Endpoint (each IP+Port pair) and an IPVS virtual server is 1:1.
|
||||
|
||||
Deleting of a Kubernetes service will trigger deletion of the corresponding IPVS virtual server, IPVS real servers and its IP addresses bound to the dummy interface.
|
||||
|
||||
Port Mapping
|
||||
|
||||
There are three proxy modes in IPVS: NAT (masq), IPIP and DR. Only NAT mode supports port mapping. Kube-proxy leverages NAT mode for port mapping. The following example shows IPVS mapping Service port 3080 to Pod port 8080.
|
||||
|
||||
-->
|
||||
|
||||
请注意，Kubernetes 服务和 IPVS 虚拟服务器之间的关系是“1：N”。 例如，考虑具有多个 IP 地址的 Kubernetes 服务。 外部 IP 类型服务有两个 IP 地址 - 集群IP和外部 IP。 然后，IPVS 代理将创建2个 IPVS 虚拟服务器 - 一个用于集群 IP，另一个用于外部 IP。 Kubernetes 的 endpoint（每个IP +端口对）与 IPVS 虚拟服务器之间的关系是“1：1”。
|
||||
|
||||
删除 Kubernetes 服务将触发删除相应的 IPVS 虚拟服务器，IPVS 物理服务器及其绑定到虚拟接口的 IP 地址。
|
||||
|
||||
端口映射
|
||||
|
||||
IPVS 中有三种代理模式：NAT（masq），IPIP 和 DR。 只有 NAT 模式支持端口映射。 Kube-proxy 利用 NAT 模式进行端口映射。 以下示例显示 IPVS 服务端口3080到Pod端口8080的映射。
|
||||
|
||||
TCP 10.102.128.4:3080 rr
|
||||
-> 10.244.0.235:8080 Masq 1 0 0
|
||||
-> 10.244.1.237:8080 Masq 1 0
|
||||
|
||||
<!--
|
||||
|
||||
Session Affinity
|
||||
|
||||
IPVS supports client IP session affinity (persistent connection). When a Service specifies session affinity, the IPVS proxier will set a timeout value (180min=10800s by default) in the IPVS virtual server. For example:
|
||||
|
||||
-->
|
||||
|
||||
会话关系
|
||||
|
||||
IPVS 支持客户端 IP 会话关联（持久连接）。 当服务指定会话关系时，IPVS 代理将在 IPVS 虚拟服务器中设置超时值（默认为180分钟= 10800秒）。 例如：
|
||||
|
||||
# kubectl describe svc nginx-service
|
||||
Name: nginx-service
|
||||
...
|
||||
IP: 10.102.128.4
|
||||
Port: http 3080/TCP
|
||||
Session Affinity: ClientIP
|
||||
|
||||
# ipvsadm -ln
|
||||
IP Virtual Server version 1.2.1 (size=4096)
|
||||
Prot LocalAddress:Port Scheduler Flags
|
||||
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
|
||||
TCP 10.102.128.4:3080 rr persistent 10800
|
||||
|
||||
<!--
|
||||
|
||||
Iptables & Ipset in IPVS Proxier
|
||||
|
||||
IPVS is for load balancing and it can't handle other workarounds in kube-proxy, e.g. packet filtering, hairpin-masquerade tricks, SNAT, etc.
|
||||
|
||||
IPVS proxier leverages iptables in the above scenarios. Specifically, ipvs proxier will fall back on iptables in the following 4 scenarios:
|
||||
|
||||
- kube-proxy start with --masquerade-all=true
|
||||
- Specify cluster CIDR in kube-proxy startup
|
||||
- Support Loadbalancer type service
|
||||
- Support NodePort type service
|
||||
|
||||
However, we don't want to create too many iptables rules. So we adopt ipset for the sake of decreasing iptables rules. The following is the table of ipset sets that IPVS proxier maintains:
|
||||
|
||||
-->
|
||||
|
||||
IPVS 代理中的 Iptables 和 Ipset
|
||||
|
||||
IPVS 用于负载均衡，它无法处理 kube-proxy 中的其他问题，例如 包过滤，数据包欺骗，SNAT 等
|
||||
|
||||
IPVS proxier 在上述场景中利用 iptables。 具体来说，ipvs proxier 将在以下4种情况下依赖于 iptables：
|
||||
|
||||
- kube-proxy 以 --masquerade-all = true 开头
|
||||
- 在 kube-proxy 启动中指定集群 CIDR
|
||||
- 支持 Loadbalancer 类型服务
|
||||
- 支持 NodePort 类型的服务
|
||||
|
||||
但是，我们不想创建太多的 iptables 规则。 所以我们采用 ipset 来减少 iptables 规则。 以下是 IPVS proxier 维护的 ipset 集表：
|
||||
|
||||
<!--
|
||||
|
||||
set name members usage
|
||||
KUBE-CLUSTER-IP All Service IP + port masquerade for cases that masquerade-all=true or clusterCIDR specified
|
||||
KUBE-LOOP-BACK All Service IP + port + IP masquerade for resolving hairpin issue
|
||||
KUBE-EXTERNAL-IP Service External IP + port masquerade for packets to external IPs
|
||||
KUBE-LOAD-BALANCER Load Balancer ingress IP + port masquerade for packets to Load Balancer type service
|
||||
KUBE-LOAD-BALANCER-LOCAL Load Balancer ingress IP + port with externalTrafficPolicy=local accept packets to Load Balancer with externalTrafficPolicy=local
|
||||
KUBE-LOAD-BALANCER-FW Load Balancer ingress IP + port with loadBalancerSourceRanges Drop packets for Load Balancer type Service with loadBalancerSourceRanges specified
|
||||
KUBE-LOAD-BALANCER-SOURCE-CIDR Load Balancer ingress IP + port + source CIDR accept packets for Load Balancer type Service with loadBalancerSourceRanges specified
|
||||
KUBE-NODE-PORT-TCP NodePort type Service TCP port masquerade for packets to NodePort(TCP)
|
||||
KUBE-NODE-PORT-LOCAL-TCP NodePort type Service TCP port with externalTrafficPolicy=local accept packets to NodePort Service with externalTrafficPolicy=local
|
||||
KUBE-NODE-PORT-UDP NodePort type Service UDP port masquerade for packets to NodePort(UDP)
|
||||
KUBE-NODE-PORT-LOCAL-UDP NodePort type service UDP port with externalTrafficPolicy=local accept packets to NodePort Service with externalTrafficPolicy=local
|
||||
|
||||
-->
|
||||
|
||||
设置名称 成员 用法
|
||||
KUBE-CLUSTER-IP 所有服务 IP + 端口 masquerade-all=true 或 clusterCIDR 指定的情况下进行伪装
|
||||
KUBE-LOOP-BACK 所有服务 IP +端口+ IP 解决数据包欺骗问题
|
||||
KUBE-EXTERNAL-IP 服务外部 IP +端口 将数据包伪装成外部 IP
|
||||
KUBE-LOAD-BALANCER 负载均衡器入口 IP +端口 将数据包伪装成 Load Balancer 类型的服务
|
||||
KUBE-LOAD-BALANCER-LOCAL 负载均衡器入口 IP +端口 以及 externalTrafficPolicy=local 接受数据包到 Load Balancer externalTrafficPolicy=local
|
||||
KUBE-LOAD-BALANCER-FW 负载均衡器入口 IP +端口 以及 loadBalancerSourceRanges 使用指定的 loadBalancerSourceRanges 丢弃 Load Balancer类型Service的数据包
|
||||
KUBE-LOAD-BALANCER-SOURCE-CIDR 负载均衡器入口 IP +端口 + 源 CIDR 接受 Load Balancer 类型 Service 的数据包，并指定loadBalancerSourceRanges
|
||||
KUBE-NODE-PORT-TCP NodePort 类型服务 TCP 将数据包伪装成 NodePort（TCP）
|
||||
KUBE-NODE-PORT-LOCAL-TCP NodePort 类型服务 TCP 端口，带有 externalTrafficPolicy=local 接受数据包到 NodePort 服务 使用 externalTrafficPolicy=local
|
||||
KUBE-NODE-PORT-UDP NodePort 类型服务 UDP 端口 将数据包伪装成 NodePort(UDP)
|
||||
KUBE-NODE-PORT-LOCAL-UDP NodePort 类型服务 UDP 端口 使用 externalTrafficPolicy=local 接受数据包到NodePort服务 使用 externalTrafficPolicy=local
|
||||
|
||||
<!--
|
||||
|
||||
In general, for IPVS proxier, the number of iptables rules is static, no matter how many Services/Pods we have.
|
||||
|
||||
-->
|
||||
|
||||
通常，对于 IPVS proxier，无论我们有多少 Service/ Pod，iptables 规则的数量都是静态的。
|
||||
|
||||
<!--
|
||||
|
||||
Run kube-proxy in IPVS Mode
|
||||
|
||||
Currently, local-up scripts, GCE scripts, and kubeadm support switching IPVS proxy mode via exporting environment variables (KUBE_PROXY_MODE=ipvs) or specifying flag (--proxy-mode=ipvs). Before running IPVS proxier, please ensure IPVS required kernel modules are already installed.
|
||||
|
||||
ip_vs
|
||||
ip_vs_rr
|
||||
ip_vs_wrr
|
||||
ip_vs_sh
|
||||
nf_conntrack_ipv4
|
||||
|
||||
Finally, for Kubernetes v1.10, feature gate SupportIPVSProxyMode is set to true by default. For Kubernetes v1.11, the feature gate is entirely removed. However, you need to enable --feature-gates=SupportIPVSProxyMode=true explicitly for Kubernetes before v1.10.
|
||||
|
||||
-->
|
||||
|
||||
在 IPVS 模式下运行 kube-proxy
|
||||
|
||||
目前，本地脚本，GCE 脚本和 kubeadm 支持通过导出环境变量（KUBE_PROXY_MODE=ipvs）或指定标志（--proxy-mode=ipvs）来切换 IPVS 代理模式。 在运行IPVS 代理之前，请确保已安装 IPVS 所需的内核模块。
|
||||
|
||||
ip_vs
|
||||
ip_vs_rr
|
||||
ip_vs_wrr
|
||||
ip_vs_sh
|
||||
nf_conntrack_ipv4
|
||||
|
||||
最后，对于 Kubernetes v1.10，“SupportIPVSProxyMode” 默认设置为 “true”。 对于 Kubernetes v1.11 ，该选项已完全删除。 但是，您需要在v1.10之前为Kubernetes 明确启用 --feature-gates = SupportIPVSProxyMode = true。
|
||||
|
||||
<!--
|
||||
|
||||
Get Involved
|
||||
|
||||
The simplest way to get involved with Kubernetes is by joining one of the many Special Interest Groups (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly community meeting, and through the channels below.
|
||||
|
||||
Thank you for your continued feedback and support.
|
||||
|
||||
Post questions (or answer questions) on Stack Overflow
|
||||
|
||||
Join the community portal for advocates on K8sPort
|
||||
|
||||
Follow us on Twitter @Kubernetesio for latest updates
|
||||
|
||||
Chat with the community on Slack
|
||||
|
||||
Share your Kubernetes story
|
||||
|
||||
-->
|
||||
|
||||
参与其中
|
||||
|
||||
参与 Kubernetes 的最简单方法是加入众多[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIG）中与您的兴趣一致的小组。 你有什么想要向 Kubernetes 社区广播的吗？ 在我们的每周[社区会议](https://github.com/kubernetes/community/blob/master/communication.md#weekly-meeting)或通过以下渠道分享您的声音。
|
||||
|
||||
感谢您的持续反馈和支持。
|
||||
在[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)上发布问题（或回答问题）
|
||||
|
||||
加入[K8sPort](http://k8sport.org/)的倡导者社区门户网站
|
||||
|
||||
在 Twitter 上关注我们 [@Kubernetesio](https://twitter.com/kubernetesio )获取最新更新
|
||||
|
||||
在[Slack](http://slack.k8s.io/)上与社区聊天
|
||||
|
||||
分享您的 Kubernetes [故事](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
|
||||
Reference in New Issue
Block a user