Skip to content

Commit

Permalink
Add 1.4 adding a new API section (kubernetes-sigs#14)
Browse files Browse the repository at this point in the history 
* Add 1.4 adding a new API section

* 添加1.4章节中的emptyapi.go中的翻译
  • Loading branch information
@luffyao
luffyao committed Jul 25, 2020
1 parent c39c50f commit ba21770
Show file tree
Hide file tree
Showing 2 changed files with 32 additions and 55 deletions.
25 changes: 7 additions & 18 deletions docs/book/src/cronjob-tutorial/new-api.md
View file
Original file line number Diff line number Diff line change
@@ -1,30 +1,19 @@
# Adding a new API
# 添加一个新的 API

To scaffold out a new Kind (you were paying attention to the [last
chapter](./gvks.md#kinds-and-resources), right?) and corresponding
controller, we can use `kubebuilder create api`:
搭建一个新的 Kind （你刚在 [上一章节](./gvks.md#kinds-and-resources) 中注意到的，是吗？) 和相应的控制器，我们可以用 `kubebuilder create api`:

```bash
kubebuilder create api --group batch --version v1 --kind CronJob
```

The first time we call this command for each group-version, it will create
a directory for the new group-version.
当第一次我们为每个组-版本调用这个命令的时候，它将会为新的组-版本创建一个目录。

In this case, the
[`api/v1/`](https://sigs.k8s.io/kubebuilder/docs/book/src/cronjob-tutorial/testdata/project/api/v1)
directory is created, corresponding to the
`batch.tutorial.kubebuilder.io/v1` (remember our [`--domain`
setting](cronjob-tutorial.md#scaffolding-out-our-project) from the
beginning?).
在这种情况下，对应于`batch.tutorial.kubebuilder.io/v1`（记得我们在开始时 [`--domain`](cronjob-tutorial.md#scaffolding-out-our-project) 的设置吗？) 的 [`api/v1/`](https://sigs.k8s.io/kubebuilder/docs/book/src/cronjob-tutorial/testdata/project/api/v1) 目录被创建了出来。

It has also added a file for our `CronJob` Kind,
`api/v1/cronjob_types.go`. Each time we call the command with a different
kind, it'll add a corresponding new file.
它也为我们的`CronJob` Kind 添加了一个文件，`api/v1/cronjob_types.go`。每次当我们用不同的 kind 去调用这个命令，它将添加一个相应的新文件。

Let's take a look at what we've been given out of the box, then we can
move on to filling it out.
让我们来看看我们得到了哪些东西，然后我们就可以开始去填写了。

{{#literatego ./testdata/emptyapi.go}}

Now that we've seen the basic structure, let's fill it out!
现在我们已经看到了基本的结构了，让我们开始去填写它吧！
62 changes: 25 additions & 37 deletions docs/book/src/cronjob-tutorial/testdata/emptyapi.go
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,9 +15,7 @@ limitations under the License.
// +kubebuilder:docs-gen:collapse=Apache License

/*
We start out simply enough: we import the `meta/v1` API group, which is not
normally exposed by itself, but instead contains metadata common to all
Kubernetes Kinds.
我们非常简单地开始：我们导入`meta/v1` API 组，该组通常本身并不会被暴露，而是包含所有 Kubernetes 种类共有的元数据。
*/
package v1

Expand All @@ -26,51 +24,43 @@ import (
)

/*
Next, we define types for the Spec and Status of our Kind. Kubernetes functions
by reconciling desired state (`Spec`) with actual cluster state (other objects'
`Status`) and external state, and then recording what it observed (`Status`).
Thus, every *functional* object includes spec and status. A few types, like
`ConfigMap` don't follow this pattern, since they don't encode desired state,
but most types do.
下一步，我们为种类的 Spe c和 Status 定义类型。Kubernetes 功能通过使期待的状态(`Spec`)和实际集群状态(其他对象的
`Status`)保持一致和外部状态，然后记录观察到的状态(`Status`)。
因此，每个 *functional* 对象包括 spec 和 status 。很少的类型，像 `ConfigMap` 不需要遵从这个模式，因为它们不编码期待的状态，
但是大部分类型需要做这一步。
*/
// EDIT THIS FILE! THIS IS SCAFFOLDING FOR YOU TO OWN!
// NOTE: json tags are required. Any new fields you add must have json tags for the fields to be serialized.
// 编辑这个文件！这是你拥有的脚手架！
// 注意: json 标签是必需的。为了字段能够被序列化任何你添加的新的字段一定有json标签。

// CronJobSpec defines the desired state of CronJob
// CronJobSpec 定义了 CronJob 期待的状态
type CronJobSpec struct {
// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
// Important: Run "make" to regenerate code after modifying this file
// 插入额外的 SPEC 字段 - 集群期待的状态
// 重要：修改了这个文件之后运行"make"去重新生成代码
}

// CronJobStatus defines the observed state of CronJob
// CronJobStatus 定义了 CronJob 观察的的状态
type CronJobStatus struct {
// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
// Important: Run "make" to regenerate code after modifying this file
// 插入额外的 STATUS 字段 - 定义集群观察的状态
// 重要：修改了这个文件之后运行"make"去重新生成代码
}

/*
Next, we define the types corresponding to actual Kinds, `CronJob` and `CronJobList`.
`CronJob` is our root type, and describes the `CronJob` kind. Like all Kubernetes objects, it contains
`TypeMeta` (which describes API version and Kind), and also contains `ObjectMeta`, which holds things
like name, namespace, and labels.
下一步，我们定义与实际种类相对应的类型，`CronJob` 和 `CronJobList` 。
`CronJob` 是一个根类型, 它描述了 `CronJob` 种类。像所有 Kubernetes 对象，它包含
`TypeMeta` (描述了API版本和种类)，也包含其中拥有像名称,名称空间和标签的东西的 `ObjectMeta` 。
`CronJobList` is simply a container for multiple `CronJob`s. It's the Kind used in bulk operations,
like LIST.
`CronJobList` 只是多个 `CronJob` 的容器。它是批量操作中使用的种类，像 LIST 。
In general, we never modify either of these -- all modifications go in either Spec or Status.
通常情况下，我们从不修改任何一个 -- 所有修改都要到 Spec 或者 Status 。
That little `+kubebuilder:object:root` comment is called a marker. We'll see
more of them in a bit, but know that they act as extra metadata, telling
[controller-tools](https://github.com/kubernetes-sigs/controller-tools) (our code and YAML generator) extra information.
This particular one tells the `object` generator that this type represents
a Kind. Then, the `object` generator generates an implementation of the
[runtime.Object](https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime?tab=doc#Object) interface for us, which is the standard
interface that all types representing Kinds must implement.
那个小小的 `+kubebuilder:object:root` 注释被称为标记。我们将会看到更多的它们，但要知道它们充当额外的元数据，
告诉[controller-tools](https://github.com/kubernetes-sigs/controller-tools)(我们的代码和YAML生成器)额外的信息。
这个特定的标签告诉 `object `生成器这个类型表示一个种类。然后，`object` 生成器为我们生成
这个所有表示种类的类型一定要实现的[runtime.Object](https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime?tab=doc#Object)接口的实现。
*/

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// CronJob is the Schema for the cronjobs API
// CronJob 是 cronjobs API 的 Schema
type CronJob struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Expand All @@ -80,17 +70,15 @@ type CronJob struct {
}

// +kubebuilder:object:root=true

// CronJobList contains a list of CronJob
// CronJobList 包含了一个 CronJob 的列表
type CronJobList struct {
metav1.TypeMeta `json:",inline"`
metav1.ListMeta `json:"metadata,omitempty"`
Items []CronJob `json:"items"`
}

/*
Finally, we add the Go types to the API group. This allows us to add the
types in this API group to any [Scheme](https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime?tab=doc#Scheme).
最后，我们将这个 Go 类型添加到 API 组中。这允许我们将这个 API 组中的类型可以添加到任何[Scheme](https://pkg.go.dev/k8s.io/apimachinery/pkg/runtime?tab=doc#Scheme)。
*/
func init() {
SchemeBuilder.Register(&CronJob{}, &CronJobList{})
Expand Down

0 comments on commit ba21770

Please sign in to comment.