openshift/origin

GitHub: openshift/origin

OpenShift 官方仓库,维护 openshift-tests 二进制文件及其端到端测试套件,用于验证 OpenShift 集群的一致性与功能完整性。

Stars: 8675 | Forks: 4792

# Origin Kubernetes [![Go Report Card](https://goreportcard.com/badge/github.com/openshift/origin)](https://goreportcard.com/report/github.com/openshift/origin) [![GoDoc](https://godoc.org/github.com/openshift/origin?status.png)](https://godoc.org/github.com/openshift/origin) [![Licensed under Apache License version 2.0](https://img.shields.io/github/license/openshift/origin.svg?maxAge=2592000)](https://www.apache.org/licenses/LICENSE-2.0) 此仓库曾是为 [OKD](https://github.com/openshift/okd) 追踪的核心 Kubernetes 仓库,也是维护 OpenShift 的 `hyperkube` 和 `openshift-test` 二进制文件的场所。截至 2020 年 7 月,该仓库的用途和维护策略因分支而异。 ## 4.6 及以上版本 `main` 和 `release-x.x` 分支的维护 这些分支不再包含生成 `hyperkube` 二进制文件所需的代码,仅限于维护 `openshift-tests` 二进制文件。维护 hyperkube 的职责已转移至 [openshift/kubernetes](https://github.com/openshift/kubernetes) 仓库。 针对上游的 backport 和 carry 应提交至 `openshift/kubernetes`。如果合并到 `openshift/kubernetes` 的更改需要应用到 `origin`,则需要向 `origin` 提交一个 PR 来更新 vendoring。 两个仓库之间的分支名称是相关的,因此合并到 `openshift/kubernetes` 某个分支的更改应当被 vendored 到 `origin` 的相同分支中(例如,`openshift/kubernetes` 中的 `master` 被 vendored 到 `origin` 中的 `main`)。 **注意:** 将 `openshift/kubernetes` 的 `main` 和 `release-x.x` 分支 vendoring 到 `origin` 的对应分支只是临时措施。在不久的将来,`origin` 将切换为 vendoring origin 特有的分支(例如 `origin-4.6-kubernetes-1.19.2`),以最大程度地减少在 `openshift/kubernetes` rebase 时需要考虑的 backport 和 carry 范围。 ### 测试排除规则 测试排除现在通过基于环境选择器的过滤来处理,而不是测试注解。环境选择器允许根据集群环境和配置来过滤或跳过测试。 例如,可以定义选择器来匹配已知与特定 OpenShift 配置不兼容的 kube e2e 测试,并将这些测试排除在运行之外。 测试排除规则的维护工作在 `openshift/kubernetes` 和 `origin` 仓库之间进行拆分,以确保提交给 `openshift/kubernetes` 的 PR 能够针对已知与 OpenShift 兼容的 kube e2e 测试集进行验证。 kubernetes e2e 测试的测试排除规则维护在:https://github.com/openshift/kubernetes/blob/master/openshift-hack/cmd/k8s-tests-ext: * [environment_selectors.go](https://github.com/openshift/kubernetes/blob/master/openshift-hack/cmd/k8s-tests-ext/environment_selectors.go) * [disabled_tests.go](https://github.com/openshift/kubernetes/blob/master/openshift-hack/cmd/k8s-tests-ext/disabled_tests.go) openshift e2e 测试的测试排除规则维护在:https://github.com/openshift/origin/blob/main/pkg/test/extensions: * [environment_selectors.go](https://github.com/openshift/origin/blob/main/pkg/test/extensions/environment_selectors.go) * [disabled_tests.go](https://github.com/openshift/origin/blob/main/pkg/test/extensions/disabled_tests.go) 要更新 kube e2e 测试的测试排除规则,请更新 `openshift/kubernetes` 中的环境选择器。对于 OpenShift e2e 测试,请更新 `origin` 中的选择器。 ### 从 `openshift/kubernetes` 进行 Vendoring 这些 origin 分支通过我们的 [openshift/kubernetes](https://github.com/openshift/kubernetes) fork 对 `k8s.io/kubernetes` 及其部分 staging 仓库(例如 `k8s.io/api`)进行 vendoring。 在可能的情况下会使用上游 staging 仓库,但某些测试依赖于仅存在于该 fork 中的功能。 当更改合并到某个 `openshift/kubernetes` 分支并且需要 vendoring 到 `origin` 的相应分支时,`hack/update-kube-vendor.sh` 辅助脚本会简化为该分支中所有源自 `openshift/kubernetes` 的依赖项更新 go module 配置的过程。该脚本需要提供 `openshift/kubernetes` 的分支名称或 SHA: ``` $ hack/update-kube-vendor.sh ``` 该脚本还支持执行一次虚假升级(fake bump),以验证尚未合并到 `openshift/kubernetes` 的更改。这可以通过将 fork 仓库名称作为脚本的第二个参数来实现: ``` $ hack/update-kube-vendor.sh github.com/myname/kubernetes ``` 脚本执行完毕后,vendoring 的更改需要进行提交并提议到该仓库。 #### 解决 '410 Gone' 错误 如果脚本返回如下所示的 '410 Gone' 错误,可能是由于 golang checksum 服务器尚未知晓目标 SHA。 ``` go: k8s.io/kubernetes@v1.21.1 (replaced by github.com/openshift/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003): verifying go.mod: g ithub.com/openshift/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003/go.mod: reading https://sum.golang.org/lookup/github.com/openshif t/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003: 410 Gone server response: not found: ``` 解决方法是在执行 vendoring 更新时设置 `GOSUMDB=off` 以禁用 checksum 数据库: ``` $ GOSUMDB=off hack/update-kube-vendor.sh ``` ## release-4.5、release-4.4 和 release-4.3 的维护 4.6 之前的版本继续在 `origin` 仓库的 `release-4.x` 分支中维护 hyperkube。这些分支的持久性 carry 和 backport 应继续直接提交到 origin。除了 rebase 之外,`openshift/kubernetes` 不参与其中。 ## 端到端 (e2e) 和扩展测试 端到端测试 (e2e) 应当验证用户在日常使用中所能看到的整个产品流程。两个 e2e 测试之间的功能重叠不应超过 10%,且它们不用于详细测试错误条件。项目示例应由 e2e 测试驱动。e2e 测试还可以测试协同工作的外部组件。 所有 e2e 测试都会被编译进 `openshift-tests` 二进制文件中。 要构建测试二进制文件,请运行 `make`。 要运行特定测试或整个测试套件,请阅读 [test/extended/README](https://github.com/openshift/origin/blob/main/test/extended/README.md) 了解更多信息。 ## 更新外部示例 `hack/update-external-example.sh` 将从外部仓库拉取示例文件,并将它们存放在 `examples` 目录下。 如果您需要刷新某个示例文件或添加新文件,请运行此脚本。有关更多详细信息,请参阅该脚本和 `examples/quickstarts/README.md`。
标签:EVTX分析, Go语言, OpenShift, 子域名突变, 日志审计, 程序破解, 网络安全研究