Merge branch 'main' into update-daemonset
ziyi-xie
GitHub
commit
3d17e6a93f
|
|
@ -207,3 +207,11 @@ and without losing the state of the containers in that Pod.
|
|||
You can reach SIG Node by several means:
|
||||
- Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node)
|
||||
- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node)
|
||||
|
||||
## Further reading
|
||||
|
||||
Please see the follow-up article [Forensic container
|
||||
analysis][forensic-container-analysis] for details on how a container checkpoint
|
||||
can be analyzed.
|
||||
|
||||
[forensic-container-analysis]: /blog/2023/03/10/forensic-container-analysis/
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ This page lists some of the available add-ons and links to their respective inst
|
|||
|
||||
* [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI.
|
||||
* [Antrea](https://antrea.io/) operates at Layer 3/4 to provide networking and security services for Kubernetes, leveraging Open vSwitch as the networking data plane. Antrea is a [CNCF project at the Sandbox level](https://www.cncf.io/projects/antrea/).
|
||||
* [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer.
|
||||
* [Calico](https://www.tigera.io/project-calico/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer.
|
||||
* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) unites Flannel and Calico, providing networking and network policy.
|
||||
* [Cilium](https://github.com/cilium/cilium) is a networking, observability, and security solution with an eBPF-based data plane. Cilium provides a simple flat Layer 3 network with the ability to span multiple clusters in either a native routing or overlay/encapsulation mode, and can enforce network policies on L3-L7 using an identity-based security model that is decoupled from network addressing. Cilium can act as a replacement for kube-proxy; it also offers additional, opt-in observability and security features. Cilium is a [CNCF project at the Incubation level](https://www.cncf.io/projects/cilium/).
|
||||
* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, or Weave. CNI-Genie is a [CNCF project at the Sandbox level](https://www.cncf.io/projects/cni-genie/).
|
||||
|
|
|
|||
|
|
@ -235,7 +235,7 @@ at different times.
|
|||
{{< note >}}
|
||||
Clients of the EndpointSlice API must iterate through all the existing EndpointSlices
|
||||
associated to a Service and build a complete list of unique network endpoints. It is
|
||||
important to mention that endpoints may be duplicated in different EndointSlices.
|
||||
important to mention that endpoints may be duplicated in different EndpointSlices.
|
||||
|
||||
You can find a reference implementation for how to perform this endpoint aggregation
|
||||
and deduplication as part of the `EndpointSliceCache` code within `kube-proxy`.
|
||||
|
|
|
|||
|
|
@ -656,7 +656,7 @@ by making the changes that are equivalent to you requesting a Service of
|
|||
`type: NodePort`. The cloud-controller-manager component then configures the external load balancer to
|
||||
forward traffic to that assigned node port.
|
||||
|
||||
_As an alpha feature_, you can configure a load balanced Service to
|
||||
You can configure a load balanced Service to
|
||||
[omit](#load-balancer-nodeport-allocation) assigning a node port, provided that the
|
||||
cloud provider implementation supports this.
|
||||
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ That is, the CronJob does _not_ update existing Jobs, even if those remain runni
|
|||
A CronJob creates a Job object approximately once per execution time of its schedule.
|
||||
The scheduling is approximate because there
|
||||
are certain circumstances where two Jobs might be created, or no Job might be created.
|
||||
Kubernetes tries to avoid those situations, but do not completely prevent them. Therefore,
|
||||
Kubernetes tries to avoid those situations, but does not completely prevent them. Therefore,
|
||||
the Jobs that you define should be _idempotent_.
|
||||
|
||||
If `startingDeadlineSeconds` is set to a large value or left unset (the default)
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ min-kubernetes-server-version: v1.25
|
|||
{{< feature-state for_k8s_version="v1.25" state="alpha" >}}
|
||||
|
||||
This page explains how user namespaces are used in Kubernetes pods. A user
|
||||
namespace allows to isolate the user running inside the container from the one
|
||||
namespace isolates the user running inside the container from the one
|
||||
in the host.
|
||||
|
||||
A process running as root in a container can run as a different (non-root) user
|
||||
|
|
|
|||
|
|
@ -0,0 +1,293 @@
|
|||
---
|
||||
title: Common Expression Language in Kubernetes
|
||||
reviewers:
|
||||
- jpbetz
|
||||
- cici37
|
||||
content_type: concept
|
||||
weight: 35
|
||||
min-kubernetes-server-version: 1.25
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
The [Common Expression Language (CEL)](https://github.com/google/cel-go) is used
|
||||
in the Kubernetes API to declare validation rules, policy rules, and other
|
||||
constraints or conditions.
|
||||
|
||||
CEL expressions are evaluated directly in the
|
||||
{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}, making CEL a
|
||||
convenient alternative to out-of-process mechanisms, such as webhooks, for many
|
||||
extensibility use cases. Your CEL expressions continue to execute so long as the
|
||||
control plane's API server component remains available.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Language overview
|
||||
|
||||
The [CEL
|
||||
language](https://github.com/google/cel-spec/blob/master/doc/langdef.md) has a
|
||||
straightforward syntax that is similar to the expressions in C, C++, Java,
|
||||
JavaScript and Go.
|
||||
|
||||
CEL was designed to be embedded into applications. Each CEL "program" is a
|
||||
single expression that evaluates to a single value. CEL expressions are
|
||||
typically short "one-liners" that inline well into the string fields of Kubernetes
|
||||
API resources.
|
||||
|
||||
Inputs to a CEL program are "variables". Each Kubernetes API field that contains
|
||||
CEL declares in the API documentation which variables are available to use for
|
||||
that field. For example, in the `x-kubernetes-validations[i].rules` field of
|
||||
CustomResourceDefinitions, the `self` and `oldSelf` variables are available and
|
||||
refer to the previous and current state of the custom resource data to be
|
||||
validated by the CEL expression. Other Kubernetes API fields may declare
|
||||
different variables. See the API documentation of the API fields to learn which
|
||||
variables are available for that field.
|
||||
|
||||
Example CEL expressions:
|
||||
|
||||
{{< table caption="Examples of CEL expressions and the purpose of each" >}}
|
||||
| Rule | Purpose |
|
||||
|------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
|
||||
| `self.minReplicas <= self.replicas && self.replicas <= self.maxReplicas` | Validate that the three fields defining replicas are ordered appropriately |
|
||||
| `'Available' in self.stateCounts` | Validate that an entry with the 'Available' key exists in a map |
|
||||
| `(self.list1.size() == 0) != (self.list2.size() == 0)` | Validate that one of two lists is non-empty, but not both |
|
||||
| `self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')` | Validate the 'value' field of a listMap entry where key field 'name' is 'MY_ENV' |
|
||||
| `has(self.expired) && self.created + self.ttl < self.expired` | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration |
|
||||
| `self.health.startsWith('ok')` | Validate a 'health' string field has the prefix 'ok' |
|
||||
| `self.widgets.exists(w, w.key == 'x' && w.foo < 10)` | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 |
|
||||
| `type(self) == string ? self == '99%' : self == 42` | Validate an int-or-string field for both the the int and string cases |
|
||||
| `self.metadata.name == 'singleton'` | Validate that an object's name matches a specific value (making it a singleton) |
|
||||
| `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint |
|
||||
| `self.names.size() == self.details.size() && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet |
|
||||
|
||||
## CEL community libraries
|
||||
|
||||
Kubernetes CEL expressions have access to the following CEL community libraries:
|
||||
|
||||
- CEL standard functions, defined in the [list of standard definitions](https://github.com/google/cel-spec/blob/master/doc/langdef.md#list-of-standard-definitions)
|
||||
- CEL standard [macros](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#macros)
|
||||
- CEL [extended string function library](https://pkg.go.dev/github.com/google/cel-go/ext#Strings)
|
||||
|
||||
## Kubernetes CEL libraries
|
||||
|
||||
In additional to the CEL community libraries, Kubernetes includes CEL libraries
|
||||
that are available everywhere CEL is used in Kubernetes.
|
||||
|
||||
### Kubernetes list library
|
||||
|
||||
The list library includes `indexOf` and `lastIndexOf`, which work similar to the
|
||||
strings functions of the same names. These functions either the first or last
|
||||
positional index of the provided element in the list.
|
||||
|
||||
The list library also includes `min`, `max` and `sum`. Sum is supported on all
|
||||
number types as well as the duration type. Min and max are supported on all
|
||||
comparable types.
|
||||
|
||||
`isSorted` is also provided as a convenience function and is supported on all
|
||||
comparable types.
|
||||
|
||||
Examples:
|
||||
|
||||
{{< table caption="Examples of CEL expressions using list library functions" >}}
|
||||
| CEL Expression | Purpose |
|
||||
|------------------------------------------------------------------------------------|-----------------------------------------------------------|
|
||||
| `names.isSorted()` | Verify that a list of names is kept in alphabetical order |
|
||||
| `items.map(x, x.weight).sum() == 1.0` | Verify that the "weights" of a list of objects sum to 1.0 |
|
||||
| `lowPriorities.map(x, x.priority).max() < highPriorities.map(x, x.priority).min()` | Verify that two sets of priorities do not overlap |
|
||||
| `names.indexOf('should-be-first') == 1` | Require that the first name in a list if a specific value |
|
||||
|
||||
See the [Kubernetes List Library](https://pkg.go.dev/k8s.io/apiextensions-apiserver/pkg/apiserver/schema/cel/library#Lists)
|
||||
godoc for more information.
|
||||
|
||||
### Kubernetes regex library
|
||||
|
||||
In addition to the `matches` function provided by the CEL standard library, the
|
||||
regex library provides `find` and `findAll`, enabling a much wider range of
|
||||
regex operations.
|
||||
|
||||
Examples:
|
||||
|
||||
{{< table caption="Examples of CEL expressions using regex library functions" >}}
|
||||
| CEL Expression | Purpose |
|
||||
|-------------------------------------------------------------|----------------------------------------------------------|
|
||||
| `"abc 123".find('[0-9]*')` | Find the first number in a string |
|
||||
| `"1, 2, 3, 4".findAll('[0-9]*').map(x, int(x)).sum() < 100` | Verify that the numbers in a string sum to less than 100 |
|
||||
|
||||
See the [Kubernetes regex library](https://pkg.go.dev/k8s.io/apiextensions-apiserver/pkg/apiserver/schema/cel/library#Regex)
|
||||
godoc for more information.
|
||||
|
||||
### Kubernetes URL library
|
||||
|
||||
To make it easier and safer to process URLs, the following functions have been added:
|
||||
|
||||
- `isURL(string)` checks if a string is a valid URL according to the [Go's
|
||||
net/url](https://pkg.go.dev/net/url#URL) package. The string must be an
|
||||
absolute URL.
|
||||
- `url(string) URL` converts a string to a URL or results in an error if the
|
||||
string is not a valid URL.
|
||||
|
||||
Once parsed via the `url` function, the resulting URL object has `getScheme`,
|
||||
`getHost`, `getHostname`, `getPort`, `getEscapedPath` and `getQuery` accessors.
|
||||
|
||||
Examples:
|
||||
|
||||
{{< table caption="Examples of CEL expressions using URL library functions" >}}
|
||||
| CEL Expression | Purpose |
|
||||
|-----------------------------------------------------------------|------------------------------------------------|
|
||||
| `url('https://example.com:80/').getHost()` | Get the 'example.com:80' host part of the URL. |
|
||||
| `url('https://example.com/path with spaces/').getEscapedPath()` | Returns '/path%20with%20spaces/' |
|
||||
|
||||
See the [Kubernetes URL library](https://pkg.go.dev/k8s.io/apiextensions-apiserver/pkg/apiserver/schema/cel/library#URLs)
|
||||
godoc for more information.
|
||||
|
||||
## Type checking
|
||||
|
||||
CEL is a [gradually typed language](https://github.com/google/cel-spec/blob/master/doc/langdef.md#gradual-type-checking).
|
||||
|
||||
Some Kubernetes API fields contain fully type checked CEL expressions. For
|
||||
example, [CustomResourceDefinitions Validation
|
||||
Rules](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules)
|
||||
are fully type checked.
|
||||
|
||||
Some Kubernetes API fields contain partially type checked CEL expressions. A
|
||||
partially type checked expression is an experessions where some of the variables
|
||||
are statically typed but others are dynamically typed. For example, in the CEL
|
||||
expressions of
|
||||
[ValidatingAdmissionPolicies](/docs/reference/access-authn-authz/validating-admission-policy/)
|
||||
the `request` variable is typed, but the `object` variable is dynamically typed.
|
||||
As a result, an expression containing `request.namex` would fail type checking
|
||||
because the `namex` field is not defined. However, `object.namex` would pass
|
||||
type checking even when the `namex` field is not defined for the resource kinds
|
||||
that `object` refers to, because `object` is dynamically typed.
|
||||
|
||||
The `has()` macro in CEL may be used in CEL expressions to check if a field of a
|
||||
dynamically typed variable is accessable before attempting to access the field's
|
||||
value. For example:
|
||||
|
||||
```cel
|
||||
has(object.namex) ? object.namex == 'special' : request.name == 'special'
|
||||
```
|
||||
|
||||
## Type system integration
|
||||
|
||||
{{< table caption="Table showing the relationship between OpenAPIv3 types and CEL types" >}}
|
||||
| OpenAPIv3 type | CEL type |
|
||||
|----------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|
|
||||
| 'object' with Properties | object / "message type" (`type(<object>)` evaluates to `selfType<uniqueNumber>.path.to.object.from.self` |
|
||||
| 'object' with AdditionalProperties | map |
|
||||
| 'object' with x-kubernetes-embedded-type | object / "message type", 'apiVersion', 'kind', 'metadata.name' and 'metadata.generateName' are implicitly included in schema |
|
||||
| 'object' with x-kubernetes-preserve-unknown-fields | object / "message type", unknown fields are NOT accessible in CEL expression |
|
||||
| x-kubernetes-int-or-string | union of int or string, `self.intOrString < 100 \|\| self.intOrString == '50%'` evaluates to true for both `50` and `"50%"` |
|
||||
| 'array | list |
|
||||
| 'array' with x-kubernetes-list-type=map | list with map based Equality & unique key guarantees |
|
||||
| 'array' with x-kubernetes-list-type=set | list with set based Equality & unique entry guarantees |
|
||||
| 'boolean' | boolean |
|
||||
| 'number' (all formats) | double |
|
||||
| 'integer' (all formats) | int (64) |
|
||||
| _no equivalent_ | uint (64) |
|
||||
| 'null' | null_type |
|
||||
| 'string' | string |
|
||||
| 'string' with format=byte (base64 encoded) | bytes |
|
||||
| 'string' with format=date | timestamp (google.protobuf.Timestamp) |
|
||||
| 'string' with format=datetime | timestamp (google.protobuf.Timestamp) |
|
||||
| 'string' with format=duration | duration (google.protobuf.Duration) |
|
||||
|
||||
Also see: [CEL types](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#values),
|
||||
[OpenAPI types](https://swagger.io/specification/#data-types),
|
||||
[Kubernetes Structural Schemas](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema).
|
||||
|
||||
Equality comparison for arrays with `x-kubernetes-list-type` of `set` or `map` ignores element
|
||||
order. For example `[1, 2] == [2, 1]` if the arrays represent Kubernetes `set` values.
|
||||
|
||||
Concatenation on arrays with `x-kubernetes-list-type` use the semantics of the
|
||||
list type:
|
||||
|
||||
- `set`: `X + Y` performs a union where the array positions of all elements in
|
||||
`X` are preserved and non-intersecting elements in `Y` are appended, retaining
|
||||
their partial order.
|
||||
- `map`: `X + Y` performs a merge where the array positions of all keys in `X`
|
||||
are preserved but the values are overwritten by values in `Y` when the key
|
||||
sets of `X` and `Y` intersect. Elements in `Y` with non-intersecting keys are
|
||||
appended, retaining their partial order.
|
||||
|
||||
## Escaping
|
||||
|
||||
Only Kubernetes resource property names of the form
|
||||
`[a-zA-Z_.-/][a-zA-Z0-9_.-/]*` are accessible from CEL. Accessible property
|
||||
names are escaped according to the following rules when accessed in the
|
||||
expression:
|
||||
|
||||
{{< table caption="Table of CEL identifier escaping rules" >}}
|
||||
| escape sequence | property name equivalent |
|
||||
|-------------------|----------------------------------------------------------------------------------------------|
|
||||
| `__underscores__` | `__` |
|
||||
| `__dot__` | `.` |
|
||||
| `__dash__` | `-` |
|
||||
| `__slash__` | `/` |
|
||||
| `__{keyword}__` | [CEL **RESERVED** keyword](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#syntax) |
|
||||
|
||||
When you escape any of CEL's **RESERVED** keywords you need to match the exact property name
|
||||
use the underscore escaping
|
||||
(for example, `int` in the word `sprint` would not be escaped and nor would it need to be).
|
||||
|
||||
Examples on escaping:
|
||||
|
||||
{{< table caption="Examples escaped CEL identifiers" >}}
|
||||
| property name | rule with escaped property name |
|
||||
|---------------|-----------------------------------|
|
||||
| `namespace` | `self.__namespace__ > 0` |
|
||||
| `x-prop` | `self.x__dash__prop > 0` |
|
||||
| `redact__d` | `self.redact__underscores__d > 0` |
|
||||
| `string` | `self.startsWith('kube')` |
|
||||
|
||||
## Resource constraints
|
||||
|
||||
CEL is non-Turing complete and offers a variety of production safety controls to
|
||||
limit execution time. CEL's _resource constraint_ features provide feedback to
|
||||
developers about expression complexity and help protect the API server from
|
||||
excessive resource consumption during evaluation. CEL's resource constraint
|
||||
features are used to prevent CEL evaluation from consuming excessive API server
|
||||
resources.
|
||||
|
||||
A key element of the resource constraint features is a _cost unit_ that CEL
|
||||
defines as a way of tracking CPU utilization. Cost units are independant of
|
||||
system load and hardware. Cost units are also deterministic; for any given CEL
|
||||
expression and input data, evaluation of the expression by the CEL interpreter
|
||||
will always result in the same cost.
|
||||
|
||||
Many of CEL's core operations have fixed costs. The simplest operations, such as
|
||||
comparisons (e.g. `<`) have a cost of 1. Some have a higher fixed cost, for
|
||||
example list literal declarations have a fixed base cost of 40 cost units.
|
||||
|
||||
Calls to functions implemented in native code approximate cost based on the time
|
||||
complexity of the operation. For example: operations that use regular
|
||||
expressions, such as `match` and `find`, are estimated using an approximated
|
||||
cost of `length(regexString)*length(inputString)`. The approximated cost
|
||||
reflects the worst case time complexity of Go's RE2 implementation.
|
||||
|
||||
### Runtime cost budget
|
||||
|
||||
All CEL expressions evaluated by Kubernetes are constrained by a runtime cost
|
||||
budget. The runtime cost budget is an estimate of actual CPU utilization
|
||||
computed by incrementing a cost unit counter while interpreting a CEL
|
||||
expression. If the CEL interpreter executes too many instructions, the runtime
|
||||
cost budget will be exceeded, execution of the expressions will be halted, and
|
||||
an error will result.
|
||||
|
||||
Some Kubernetes resources define an additional runtime cost budget that bounds
|
||||
the execution of multiple expressions. If the sum total of the cost of
|
||||
expressions exceed the budget, execution of the expressions will be halted, and
|
||||
an error will result. For example the validation of a custom resource has a
|
||||
_per-validation_ runtime cost budget for all [Validation
|
||||
Rules](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules)
|
||||
evaluated to validate the custom resource.
|
||||
|
||||
### Estimated cost limits
|
||||
|
||||
For some Kubernetes resources, the API server may also check if worst case
|
||||
estimated running time of CEL expressions would be prohibitively expensive to
|
||||
execute. If so, the API server prevent the CEL expression from being written to
|
||||
API resources by rejecting create or update operations containing the CEL
|
||||
expression to the API resources. This feature offers a stronger assurance that
|
||||
CEL expressions written to the API resource will be evaluate at runtime without
|
||||
exceeding the runtime cost budget.
|
||||
|
|
@ -41,12 +41,12 @@ cluster's API server.
|
|||
|
||||
## Define clusters, users, and contexts
|
||||
|
||||
Suppose you have two clusters, one for development work and one for scratch work.
|
||||
Suppose you have two clusters, one for development work and one for test work.
|
||||
In the `development` cluster, your frontend developers work in a namespace called `frontend`,
|
||||
and your storage developers work in a namespace called `storage`. In your `scratch` cluster,
|
||||
and your storage developers work in a namespace called `storage`. In your `test` cluster,
|
||||
developers work in the default namespace, or they create auxiliary namespaces as they
|
||||
see fit. Access to the development cluster requires authentication by certificate. Access
|
||||
to the scratch cluster requires authentication by username and password.
|
||||
to the test cluster requires authentication by username and password.
|
||||
|
||||
Create a directory named `config-exercise`. In your
|
||||
`config-exercise` directory, create a file named `config-demo` with this content:
|
||||
|
|
@ -60,7 +60,7 @@ clusters:
|
|||
- cluster:
|
||||
name: development
|
||||
- cluster:
|
||||
name: scratch
|
||||
name: test
|
||||
|
||||
users:
|
||||
- name: developer
|
||||
|
|
@ -72,7 +72,7 @@ contexts:
|
|||
- context:
|
||||
name: dev-storage
|
||||
- context:
|
||||
name: exp-scratch
|
||||
name: exp-test
|
||||
```
|
||||
|
||||
A configuration file describes clusters, users, and contexts. Your `config-demo` file
|
||||
|
|
@ -83,7 +83,7 @@ your configuration file:
|
|||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
Add user details to your configuration file:
|
||||
|
|
@ -108,7 +108,7 @@ Add context details to your configuration file:
|
|||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
Open your `config-demo` file to see the added details. As an alternative to opening the
|
||||
|
|
@ -130,7 +130,7 @@ clusters:
|
|||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://5.6.7.8
|
||||
name: scratch
|
||||
name: test
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
|
|
@ -143,10 +143,10 @@ contexts:
|
|||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
cluster: test
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
name: exp-test
|
||||
current-context: ""
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
|
@ -220,19 +220,19 @@ users:
|
|||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
Now suppose you want to work for a while in the scratch cluster.
|
||||
Now suppose you want to work for a while in the test cluster.
|
||||
|
||||
Change the current context to `exp-scratch`:
|
||||
Change the current context to `exp-test`:
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
kubectl config --kubeconfig=config-demo use-context exp-test
|
||||
```
|
||||
|
||||
Now any `kubectl` command you give will apply to the default namespace of
|
||||
the `scratch` cluster. And the command will use the credentials of the user
|
||||
listed in the `exp-scratch` context.
|
||||
the `test` cluster. And the command will use the credentials of the user
|
||||
listed in the `exp-test` context.
|
||||
|
||||
View configuration associated with the new current context, `exp-scratch`.
|
||||
View configuration associated with the new current context, `exp-test`.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
|
|
@ -338,10 +338,10 @@ contexts:
|
|||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
cluster: test
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
name: exp-test
|
||||
```
|
||||
|
||||
For more information about how kubeconfig files are merged, see
|
||||
|
|
|
|||
|
|
@ -722,7 +722,7 @@ Conditions:
|
|||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "registry.k8s.io/pause:0.8.0" already present on machine
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
|
||||
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
|
||||
|
|
|
|||
|
|
@ -840,7 +840,7 @@ spec:
|
|||
secretName: dotfile-secret
|
||||
containers:
|
||||
- name: dotfile-test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command:
|
||||
- ls
|
||||
- "-l"
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: cuda-test
|
||||
image: "k8s.gcr.io/cuda-vector-add:v0.1"
|
||||
image: "registry.k8s.io/cuda-vector-add:v0.1"
|
||||
resources:
|
||||
limits:
|
||||
nvidia.com/gpu: 1
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ metadata:
|
|||
name: test-ebs
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-ebs
|
||||
|
|
@ -160,7 +160,7 @@ metadata:
|
|||
name: test-cinder
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-cinder-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-cinder
|
||||
|
|
@ -271,7 +271,7 @@ metadata:
|
|||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /cache
|
||||
|
|
@ -349,7 +349,7 @@ metadata:
|
|||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
|
|
@ -496,7 +496,7 @@ metadata:
|
|||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
|
|
@ -526,7 +526,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-webserver
|
||||
image: k8s.gcr.io/test-webserver:latest
|
||||
image: registry.k8s.io/test-webserver:latest
|
||||
volumeMounts:
|
||||
- mountPath: /var/local/aaa
|
||||
name: mydir
|
||||
|
|
@ -657,7 +657,7 @@ metadata:
|
|||
name: test-portworx-volume-pod
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /mnt
|
||||
|
|
@ -847,7 +847,7 @@ metadata:
|
|||
name: pod-0
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: pod-0
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
|
|
@ -976,7 +976,7 @@ metadata:
|
|||
name: test-vmdk
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-vmdk
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ spec:
|
|||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
image: registry.k8s.io/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ Un [*Deployment*](/docs/concepts/workloads/controllers/deployment/) en Kubernete
|
|||
1. Ejecutar el comando `kubectl create` para crear un Deployment que maneje un Pod. El Pod ejecuta un contenedor basado en la imagen proveida por Docker.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
|
||||
kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
|
||||
```
|
||||
|
||||
2. Ver el Deployment:
|
||||
|
|
|
|||
|
|
@ -889,7 +889,7 @@ spec:
|
|||
secretName: dotfile-secret
|
||||
containers:
|
||||
- name: dotfile-test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command:
|
||||
- ls
|
||||
- "-l"
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ spec:
|
|||
path: /any/path/it/will/be/replaced
|
||||
containers:
|
||||
- name: pv-recycler
|
||||
image: "k8s.gcr.io/busybox"
|
||||
image: "registry.k8s.io/busybox"
|
||||
command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
|
||||
volumeMounts:
|
||||
- name: vol
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ metadata:
|
|||
name: test-ebs
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-ebs
|
||||
|
|
@ -190,7 +190,7 @@ metadata:
|
|||
name: test-cinder
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-cinder-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-cinder
|
||||
|
|
@ -294,7 +294,7 @@ metadata:
|
|||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /cache
|
||||
|
|
@ -369,7 +369,7 @@ metadata:
|
|||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
|
|
@ -509,7 +509,7 @@ metadata:
|
|||
name: test-pd
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
|
|
@ -759,7 +759,7 @@ metadata:
|
|||
name: test-portworx-volume-pod
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /mnt
|
||||
|
|
@ -824,7 +824,7 @@ metadata:
|
|||
name: pod-0
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: pod-0
|
||||
volumeMounts:
|
||||
- mountPath: /test-pd
|
||||
|
|
@ -953,7 +953,7 @@ metadata:
|
|||
name: test-vmdk
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/test-webserver
|
||||
- image: registry.k8s.io/test-webserver
|
||||
name: test-container
|
||||
volumeMounts:
|
||||
- mountPath: /test-vmdk
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ spec:
|
|||
terminationGracePeriodSeconds: 10
|
||||
containers:
|
||||
- name: nginx
|
||||
image: k8s.gcr.io/nginx-slim:0.8
|
||||
image: registry.k8s.io/nginx-slim:0.8
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
|
|
|
|||
|
|
@ -329,7 +329,7 @@ spec:
|
|||
containers:
|
||||
- args:
|
||||
- /server
|
||||
image: k8s.gcr.io/liveness
|
||||
image: registry.k8s.io/liveness
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
# lorsque "host" n'est pas défini, "PodIP" sera utilisé
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ cd <fed-base>
|
|||
hack/update-federation-api-reference-docs.sh
|
||||
```
|
||||
|
||||
Le script exécute le [k8s.gcr.io/gen-swagger-docs](https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/gen-swagger-docs?gcrImageListquery=%255B%255D&gcrImageListpage=%257B%2522t%2522%253A%2522%2522%252C%2522i%2522%253A0%257D&gcrImageListsize=50&gcrImageListsort=%255B%257B%2522p%2522%253A%2522uploaded%2522%252C%2522s%2522%253Afalse%257D%255D) image pour générer cet ensemble de documents de référence:
|
||||
Le script exécute le [registry.k8s.io/gen-swagger-docs](https://console.cloud.google.com/gcr/images/google-containers/GLOBAL/gen-swagger-docs?gcrImageListquery=%255B%255D&gcrImageListpage=%257B%2522t%2522%253A%2522%2522%252C%2522i%2522%253A0%257D&gcrImageListsize=50&gcrImageListsort=%255B%257B%2522p%2522%253A%2522uploaded%2522%252C%2522s%2522%253Afalse%257D%255D) image pour générer cet ensemble de documents de référence:
|
||||
|
||||
* /docs/api-reference/extensions/v1beta1/operations.html
|
||||
* /docs/api-reference/extensions/v1beta1/definitions.html
|
||||
|
|
|
|||
|
|
@ -359,8 +359,8 @@ Exemples utilisant `-o=custom-columns` :
|
|||
# Toutes les images s'exécutant dans un cluster
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
|
||||
|
||||
# Toutes les images excepté "k8s.gcr.io/coredns:1.6.2"
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
|
||||
# Toutes les images excepté "registry.k8s.io/coredns:1.6.2"
|
||||
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry.k8s.io/coredns:1.6.2")].image'
|
||||
|
||||
# Tous les champs dans metadata quel que soit leur nom
|
||||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ kubeadm init [flags]
|
|||
--feature-gates string Un ensemble de paires clef=valeur qui décrivent l'entrée de configuration pour des fonctionnalités diverses. Il n'y en a aucune dans cette version.
|
||||
-h, --help aide pour l'initialisation (init)
|
||||
--ignore-preflight-errors strings Une liste de contrôles dont les erreurs seront catégorisées comme "warnings" (avertissements). Par exemple : 'IsPrivilegedUser,Swap'. La valeur 'all' ignore les erreurs de tous les contrôles.
|
||||
--image-repository string Choisis un container registry d'où télécharger les images du control plane. (par défaut "k8s.gcr.io")
|
||||
--image-repository string Choisis un container registry d'où télécharger les images du control plane. (par défaut "registry.k8s.io")
|
||||
--kubernetes-version string Choisis une version Kubernetes spécifique pour le control plane. (par défaut "stable-1")
|
||||
--node-name string Spécifie le nom du noeud.
|
||||
--pod-network-cidr string Spécifie l'intervalle des adresses IP pour le réseau des pods. Si fournie, le control plane allouera automatiquement les CIDRs pour chacun des noeuds.
|
||||
|
|
|
|||
|
|
@ -131,12 +131,12 @@ Pour de l'information sur comment passer des options aux composants du control p
|
|||
|
||||
### Utiliser des images personnalisées {#custom-images}
|
||||
|
||||
Par défaut, kubeadm télécharge les images depuis `k8s.gcr.io`, à moins que la version demandée de Kubernetes soit une version Intégration Continue (CI). Dans ce cas, `gcr.io/k8s-staging-ci-images` est utilisé.
|
||||
Par défaut, kubeadm télécharge les images depuis `registry.k8s.io`, à moins que la version demandée de Kubernetes soit une version Intégration Continue (CI). Dans ce cas, `gcr.io/k8s-staging-ci-images` est utilisé.
|
||||
|
||||
Vous pouvez outrepasser ce comportement en utilisant [kubeadm avec un fichier de configuration](#config-file).
|
||||
Les personnalisations permises sont :
|
||||
|
||||
* fournir un `imageRepository` à utiliser à la place de `k8s.gcr.io`.
|
||||
* fournir un `imageRepository` à utiliser à la place de `registry.k8s.io`.
|
||||
* régler `useHyperKubeImage` à `true` pour utiliser l'image HyperKube.
|
||||
* fournir un `imageRepository` et un `imageTag` pour etcd et l'extension (add-on) DNS.
|
||||
|
||||
|
|
@ -264,7 +264,7 @@ kubeadm config images list
|
|||
kubeadm config images pull
|
||||
```
|
||||
|
||||
A partir de Kubernetes 1.12, les images prefixées par `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` et `k8s.gcr.io/pause`
|
||||
A partir de Kubernetes 1.12, les images prefixées par `registry.k8s.io/kube-*`, `registry.k8s.io/etcd` et `registry.k8s.io/pause`
|
||||
ne nécessitent pas un suffix `-${ARCH}`.
|
||||
|
||||
### Automatiser kubeadm
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ Suivez les étapes ci-dessous pour commencer et explorer Minikube.
|
|||
Créons un déploiement Kubernetes en utilisant une image existante nommée `echoserver`, qui est un serveur HTTP, et exposez-la sur le port 8080 à l’aide de `--port`.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
|
||||
kubectl create deployment hello-minikube --image=registry.k8s.io/echoserver:1.10
|
||||
```
|
||||
|
||||
Le résultat est similaire à ceci:
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Cela peut être utilisé dans le cas des liveness checks sur les conteneurs à d
|
|||
|
||||
De nombreuses applications fonctionnant pour des longues périodes finissent par passer à des états de rupture et ne peuvent pas se rétablir, sauf en étant redémarrées. Kubernetes fournit des liveness probes pour détecter et remédier à ces situations.
|
||||
|
||||
Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image `k8s.gcr.io/busybox`. Voici le fichier de configuration pour le Pod :
|
||||
Dans cet exercice, vous allez créer un Pod qui exécute un conteneur basé sur l'image `registry.k8s.io/busybox`. Voici le fichier de configuration pour le Pod :
|
||||
|
||||
{{< codenew file="pods/probe/exec-liveness.yaml" >}}
|
||||
|
||||
|
|
@ -61,8 +61,8 @@ La sortie indique qu'aucune liveness probe n'a encore échoué :
|
|||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
|
||||
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
|
||||
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
|
||||
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "registry.k8s.io/busybox"
|
||||
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "registry.k8s.io/busybox"
|
||||
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
|
||||
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
|
||||
```
|
||||
|
|
@ -79,8 +79,8 @@ Au bas de la sortie, il y a des messages indiquant que les liveness probes ont
|
|||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
|
||||
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
|
||||
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
|
||||
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "registry.k8s.io/busybox"
|
||||
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "registry.k8s.io/busybox"
|
||||
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
|
||||
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
|
||||
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
|
||||
|
|
@ -102,7 +102,7 @@ liveness-exec 1/1 Running 1 1m
|
|||
## Définir une requête HTTP de liveness
|
||||
|
||||
Un autre type de liveness probe utilise une requête GET HTTP. Voici la configuration
|
||||
d'un Pod qui fait fonctionner un conteneur basé sur l'image `k8s.gcr.io/liveness`.
|
||||
d'un Pod qui fait fonctionner un conteneur basé sur l'image `registry.k8s.io/liveness`.
|
||||
|
||||
{{< codenew file="pods/probe/http-liveness.yaml" >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ En quelques étapes, nous vous emmenons de Docker Compose à Kubernetes. Tous do
|
|||
services:
|
||||
|
||||
redis-master:
|
||||
image: k8s.gcr.io/redis:e2e
|
||||
image: registry.k8s.io/redis:e2e
|
||||
ports:
|
||||
- "6379"
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ Les déploiements sont le moyen recommandé pour gérer la création et la mise
|
|||
Pod utilise un conteneur basé sur l'image Docker fournie.
|
||||
|
||||
```shell
|
||||
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
|
||||
kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4
|
||||
```
|
||||
|
||||
2. Affichez le déploiement :
|
||||
|
|
|
|||
|
|
@ -41,9 +41,9 @@ spec:
|
|||
serviceAccountName: cloud-controller-manager
|
||||
containers:
|
||||
- name: cloud-controller-manager
|
||||
# pour les fournisseurs in-tree, nous utilisons k8s.gcr.io/cloud-controller-manager
|
||||
# pour les fournisseurs in-tree, nous utilisons registry.k8s.io/cloud-controller-manager
|
||||
# cela peut être remplacé par n'importe quelle autre image pour les fournisseurs out-of-tree
|
||||
image: k8s.gcr.io/cloud-controller-manager:v1.8.0
|
||||
image: registry.k8s.io/cloud-controller-manager:v1.8.0
|
||||
command:
|
||||
- /usr/local/bin/cloud-controller-manager
|
||||
- --cloud-provider=<YOUR_CLOUD_PROVIDER> # Ajoutez votre propre fournisseur de cloud ici!
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ spec:
|
|||
- name: varlog
|
||||
mountPath: /var/log
|
||||
- name: count-agent
|
||||
image: k8s.gcr.io/fluentd-gcp:1.30
|
||||
image: registry.k8s.io/fluentd-gcp:1.30
|
||||
env:
|
||||
- name: FLUENTD_ARGS
|
||||
value: -c /etc/fluentd-config/fluentd.conf
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ spec:
|
|||
spec:
|
||||
containers:
|
||||
- name: master
|
||||
image: k8s.gcr.io/redis:e2e # or just image: redis
|
||||
image: registry.k8s.io/redis:e2e # or just image: redis
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
|
||||
env:
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
envFrom:
|
||||
- configMapRef:
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/sh","-c","cat /etc/config/keys" ]
|
||||
volumeMounts:
|
||||
- name: config-volume
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
|
||||
volumeMounts:
|
||||
- name: config-volume
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
env:
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
command: [ "/bin/sh", "-c", "env" ]
|
||||
env:
|
||||
# Définie la variable d'environnement
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: liveness
|
||||
image: k8s.gcr.io/busybox
|
||||
image: registry.k8s.io/busybox
|
||||
args:
|
||||
- /bin/sh
|
||||
- -c
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: liveness
|
||||
image: k8s.gcr.io/liveness
|
||||
image: registry.k8s.io/liveness
|
||||
args:
|
||||
- /server
|
||||
livenessProbe:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ metadata:
|
|||
spec:
|
||||
containers:
|
||||
- name: goproxy
|
||||
image: k8s.gcr.io/goproxy:0.1
|
||||
image: registry.k8s.io/goproxy:0.1
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
readinessProbe:
|
||||
|
|
|
|||
|
|
@ -23,4 +23,4 @@ spec:
|
|||
- zoneC
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause:3.1
|
||||
image: registry.k8s.io/pause:3.1
|
||||
|
|
|
|||
|
|
@ -14,4 +14,4 @@ spec:
|
|||
foo: bar
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause:3.1
|
||||
image: registry.k8s.io/pause:3.1
|
||||
|
|
|
|||
|
|
@ -20,4 +20,4 @@ spec:
|
|||
foo: bar
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause:3.1
|
||||
image: registry.k8s.io/pause:3.1
|
||||
|
|
|
|||
|
|
@ -43,12 +43,12 @@ sitemap:
|
|||
<button id="desktopShowVideoButton" onclick="kub.showVideo()">वीडियो देखें</button>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">अक्टूबर 11-15, 2021 को KubeCon North America में भाग लें</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/" button id="desktopKCButton">अप्रैल 18-21, 2023 KubeCon + CloudNativeCon Europe में भाग लें</a>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">मई 17-20, 2022 को KubeCon Europe में भाग लें</a>
|
||||
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" button id="desktopKCButton">6-9 नवंबर, 2023 को KubeCon + CloudNativeCon North America में भाग लें</a>
|
||||
</div>
|
||||
<div id="videoPlayer">
|
||||
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Windows पर kubectl संस्थापित करने के लिए
|
|||
- `True` या `False` परिणाम प्राप्त करने के लिए `-eq` ऑपरेटर का उपयोग करके सत्यापन को ऑटोमेट करने के लिए powershell का उपयोग करें:
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
|
||||
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
|
||||
```
|
||||
|
||||
1. अपने `PATH` में बाइनरी जोड़ें।
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ deployment.apps/my-deployment created
|
|||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
`kubectl`についてさらに知りたい場合は、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。
|
||||
`kubectl`についてさらに知りたい場合は、[コマンドラインツール(kubectl)](/ja/docs/reference/kubectl/)を参照してください。
|
||||
|
||||
## ラベルを有効に使う
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ weight: 10
|
|||
|
||||
*カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。
|
||||
|
||||
カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/overview/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
|
||||
カスタムリソースは、稼働しているクラスターに動的に登録され、現れたり、消えたりし、クラスター管理者はクラスター自体とは無関係にカスタムリソースを更新できます。一度、カスタムリソースがインストールされると、ユーザーは[kubectl](/ja/docs/reference/kubectl/)を使い、ビルトインのリソースである *Pods* と同じように、オブジェクトを作成、アクセスすることが可能です。
|
||||
|
||||
## カスタムコントローラー
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ APIサーバーは、エンドユーザー、クラスターのさまざまな
|
|||
|
||||
Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。
|
||||
|
||||
ほとんどの操作は、APIを使用している[kubectl](/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。
|
||||
ほとんどの操作は、APIを使用している[kubectl](/ja/docs/reference/kubectl/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。
|
||||
RESTコールを利用して直接APIにアクセスすることも可能です。
|
||||
|
||||
Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。
|
||||
|
|
|
|||
|
|
@ -22,9 +22,9 @@ DaemonSetのいくつかの典型的な使用例は以下の通りです。
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## DaemonSet Specの記述
|
||||
## DaemonSet Specの記述 {#writing-a-daemonset-spec}
|
||||
|
||||
### DaemonSetの作成
|
||||
### DaemonSetの作成 {#create-a-daemonset}
|
||||
|
||||
ユーザーはYAMLファイル内でDaemonSetの設定を記述することができます。例えば、下記の`daemonset.yaml`ファイルでは`fluentd-elasticsearch`というDockerイメージを稼働させるDaemonSetの設定を記述します。
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ YAMLファイルに基づいてDaemonSetを作成します。
|
|||
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
```
|
||||
|
||||
### 必須のフィールド
|
||||
### 必須のフィールド {#required-fields}
|
||||
|
||||
他の全てのKubernetesの設定と同様に、DaemonSetは`apiVersion`、`kind`と`metadata`フィールドが必須となります。設定ファイルの活用法に関する一般的な情報は、[ステートレスアプリケーションの稼働](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[kubectlを用いたオブジェクトの管理](/ja/docs/concepts/overview/working-with-objects/object-management/)といったドキュメントを参照ください。
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ DaemonSetオブジェクトの名前は、有効な
|
|||
|
||||
また、DaemonSetにおいて[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)セクションも必須となります。
|
||||
|
||||
### Podテンプレート
|
||||
### Podテンプレート {#pod-template}
|
||||
|
||||
`.spec.template`は`.spec`内での必須のフィールドの1つです。
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ Podに対する必須のフィールドに加えて、DaemonSet内のPodテン
|
|||
|
||||
DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)フィールドを指定せずにデフォルトの`Always`を使用するか、明示的に`Always`を設定するかのどちらかである必要があります。
|
||||
|
||||
### Podセレクター
|
||||
### Podセレクター {#pod-selector}
|
||||
|
||||
`.spec.selector`フィールドはPodセレクターとなります。これは[Job](/ja/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。
|
||||
|
||||
|
|
@ -71,12 +71,12 @@ DaemonSet内のPodテンプレートでは、[`RestartPolicy`](/ja/docs/concepts
|
|||
|
||||
もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。
|
||||
|
||||
### 選択したNode上でPodを稼働させる
|
||||
### 選択したNode上でPodを稼働させる {#running-pods-on-select-nodes}
|
||||
|
||||
もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするNode上にPodを作成します。同様に、もし`.spec.template.spec.affinity`を指定したとき、DaemonSetコントローラーは[node affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にマッチするNode上にPodを作成します。
|
||||
もしユーザーがどちらも指定しないとき、DaemonSetコントローラーは全てのNode上にPodを作成します。
|
||||
|
||||
## Daemon Podがどのようにスケジューリングされるか
|
||||
## Daemon Podがどのようにスケジューリングされるか {#how-daemon-pods-are-scheduled}
|
||||
|
||||
DaemonSetは、全ての利用可能なNodeがPodのコピーを稼働させることを保証します。DaemonSetコントローラーは対象となる各Nodeに対してPodを作成し、ターゲットホストに一致するようにPodの`spec.affinity.nodeAffinity`フィールドを追加します。Podが作成されると、通常はデフォルトのスケジューラーが引き継ぎ、`.spec.nodeName`を設定することでPodをターゲットホストにバインドします。新しいNodeに適合できない場合、デフォルトスケジューラーは新しいPodの[優先度](/ja/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)に基づいて、既存Podのいくつかを先取り(退避)させることがあります。
|
||||
|
||||
|
|
@ -95,8 +95,7 @@ nodeAffinity:
|
|||
- target-host-name
|
||||
```
|
||||
|
||||
|
||||
### TaintとToleration
|
||||
### TaintとToleration {#taints-and-tolerations}
|
||||
|
||||
DaemonSetコントローラーはDaemonSet Podに一連の{{< glossary_tooltip
|
||||
text="Toleration" term_id="toleration" >}}を自動的に追加します:
|
||||
|
|
@ -122,7 +121,7 @@ DaemonSetコントローラーは`node.kubernetes.io/unschedulable:NoSchedule`
|
|||
[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)のような重要なNodeレベルの機能をDaemonSetで提供する場合、KubernetesがDaemonSet PodをNodeが準備完了になる前に配置することは有用です。
|
||||
例えば、その特別なTolerationがなければ、ネットワークプラグインがそこで実行されていないためにNodeが準備完了としてマークされず、同時にNodeがまだ準備完了でないためにそのNode上でネットワークプラグインが実行されていないというデッドロック状態に陥ってしまう可能性があるのです。
|
||||
|
||||
## Daemon Podとのコミュニケーション
|
||||
## Daemon Podとのコミュニケーション {#communicating-with-daemon-pods}
|
||||
|
||||
DaemonSet内のPodとのコミュニケーションをする際に考えられるパターンは以下の通りです:
|
||||
|
||||
|
|
@ -131,7 +130,7 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ
|
|||
- **DNS**: 同じPodセレクターを持つ[HeadlessService](/ja/docs/concepts/services-networking/service/#headless-service)を作成し、`endpoints`リソースを使ってDaemonSetを探すか、DNSから複数のAレコードを取得します。
|
||||
- **Service**: 同じPodセレクターを持つServiceを作成し、複数のうちのいずれかのNode上のDaemonに疎通させるためにそのServiceを使います。(特定のNodeにアクセスする方法はありません。)
|
||||
|
||||
## DaemonSetの更新
|
||||
## DaemonSetの更新 {#updating-a-daemonset}
|
||||
|
||||
もしNodeラベルが変更されたとき、そのDaemonSetは直ちに新しくマッチしたNodeにPodを追加し、マッチしなくなったNodeからPodを削除します。
|
||||
|
||||
|
|
@ -141,9 +140,9 @@ DaemonSet内のPodとのコミュニケーションをする際に考えられ
|
|||
|
||||
ユーザーはDaemonSet上で[ローリングアップデートの実施](/docs/tasks/manage-daemon/update-daemon-set/)が可能です。
|
||||
|
||||
## DaemonSetの代替案
|
||||
## DaemonSetの代替案 {#alternatives-to-daemonset}
|
||||
|
||||
### Initスクリプト
|
||||
### Initスクリプト {#init-scripts}
|
||||
|
||||
Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`を使用する)、デーモンプロセスを稼働することが可能です。この方法は非常に良いですが、このようなプロセスをDaemonSetを介して起動することはいくつかの利点があります。
|
||||
|
||||
|
|
@ -151,15 +150,15 @@ Node上で直接起動することにより(例: `init`、`upstartd`、`systemd`
|
|||
- デーモンとアプリケーションで同じ設定用の言語とツール(例: Podテンプレート、`kubectl`)を使える。
|
||||
- リソースリミットを使ったコンテナ内でデーモンを稼働させることにより、デーモンとアプリケーションコンテナの分離性が高まります。ただし、これはPod内ではなく、コンテナ内でデーモンを稼働させることでも可能です。
|
||||
|
||||
### ベアPod
|
||||
### ベアPod {#bare-pods}
|
||||
|
||||
特定のNode上で稼働するように指定したPodを直接作成することは可能です。しかし、DaemonSetはNodeの故障やNodeの破壊的なメンテナンスやカーネルのアップグレードなど、どのような理由に限らず、削除されたもしくは停止されたPodを置き換えます。このような理由で、ユーザーはPod単体を作成するよりもむしろDaemonSetを使うべきです。
|
||||
|
||||
### 静的Pod
|
||||
### 静的Pod {#static-pods}
|
||||
|
||||
Kubeletによって監視されているディレクトリに対してファイルを書き込むことによって、Podを作成することが可能です。これは[静的Pod](/ja/docs/tasks/configure-pod-container/static-pod/)と呼ばれます。DaemonSetと違い、静的Podはkubectlや他のKubernetes APIクライアントで管理できません。静的PodはApiServerに依存しておらず、クラスターの自立起動時に最適です。また、静的Podは将来的には廃止される予定です。
|
||||
|
||||
### Deployment
|
||||
### Deployment {#deployments}
|
||||
|
||||
DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ content_type: concept
|
|||
|
||||
## CLIリファレンス
|
||||
|
||||
* [kubectl](/ja/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
|
||||
* [kubectl](/ja/docs/reference/kubectl/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。
|
||||
* [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。
|
||||
* [kubeadm](/ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
title: Kubectl
|
||||
id: kubectl
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/kubectl/
|
||||
short_description: >
|
||||
Kubernetesクラスターと通信するためのコマンドラインツールです。
|
||||
|
||||
aka:
|
||||
- kubectl
|
||||
tags:
|
||||
- tool
|
||||
- fundamental
|
||||
---
|
||||
Kubernetes APIを使用してKubernetesクラスターの{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}と通信するためのコマンドラインツールです。
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetesオブジェクトの作成、検査、更新、削除には `kubectl` を使用することができます。
|
||||
|
|
@ -1,5 +1,495 @@
|
|||
---
|
||||
title: "kubectl CLI"
|
||||
title: コマンドラインツール(kubectl)
|
||||
content_type: reference
|
||||
weight: 110
|
||||
no_list: true
|
||||
card:
|
||||
name: reference
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{< glossary_definition prepend="Kubernetesが提供する、" term_id="kubectl" length="short" >}}
|
||||
|
||||
このツールの名前は、`kubectl` です。
|
||||
|
||||
`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
|
||||
|
||||
この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。
|
||||
|
||||
インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。クイックガイドは、[cheat sheet](/docs/reference/kubectl/cheatsheet/) をご覧ください。`docker`コマンドラインツールに慣れている方は、[`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/) でKubernetesの同等のコマンドを説明しています。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 構文
|
||||
|
||||
ターミナルウィンドウから`kubectl`コマンドを実行するには、以下の構文を使用します。
|
||||
|
||||
```shell
|
||||
kubectl [command] [TYPE] [NAME] [flags]
|
||||
```
|
||||
|
||||
ここで、`command`、`TYPE`、`NAME`、`flags`は、以下を表します。
|
||||
|
||||
* `command`: 1つ以上のリソースに対して実行したい操作を指定します。例えば、`create`、`get`、`describe`、`delete`です。
|
||||
|
||||
* `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。
|
||||
|
||||
```shell
|
||||
kubectl get pod pod1
|
||||
kubectl get pods pod1
|
||||
kubectl get po pod1
|
||||
```
|
||||
|
||||
* `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。
|
||||
|
||||
複数のリソースに対して操作を行う場合は、各リソースをタイプと名前で指定するか、1つまたは複数のファイルを指定することができます。
|
||||
|
||||
* リソースをタイプと名前で指定する場合
|
||||
|
||||
* タイプがすべて同じとき、リソースをグループ化するには`TYPE1 name1 name2 name<#>`とします。<br/>
|
||||
例: `kubectl get pod example-pod1 example-pod2`
|
||||
|
||||
* 複数のリソースタイプを個別に指定するには、`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`とします。<br/>
|
||||
例: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
|
||||
* リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。
|
||||
|
||||
* 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。<br/>
|
||||
例: `kubectl get pod -f ./pod.yaml`
|
||||
|
||||
* `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。<br/>
|
||||
|
||||
{{< caution >}}
|
||||
コマンドラインから指定したフラグは、デフォルト値および対応する任意の環境変数を上書きします。
|
||||
{{< /caution >}}
|
||||
|
||||
ヘルプが必要な場合は、ターミナルウィンドウから`kubectl help`を実行してください。
|
||||
|
||||
## 操作
|
||||
|
||||
以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。
|
||||
|
||||
操作 | 構文 | 説明
|
||||
-------------------- | -------------------- | --------------------
|
||||
`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。
|
||||
`annotate` | <code>kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのアノテーションを、追加または更新します。
|
||||
`api-resources` | `kubectl api-resources [flags]` | 利用可能なAPIリソースを一覧表示します。
|
||||
`api-versions` | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを一覧表示します。
|
||||
`apply` | `kubectl apply -f FILENAME [flags]`| ファイルまたは標準出力から、リソースの設定変更を適用します。
|
||||
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。
|
||||
`auth` | `kubectl auth [flags] [options]` | 認可を検査します。
|
||||
`autoscale` | <code>kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | ReplicationControllerで管理されているPodのセットを、自動的にスケールします。
|
||||
`certificate` | `kubectl certificate SUBCOMMAND [options]` | 証明書のリソースを変更します。
|
||||
`cluster-info` | `kubectl cluster-info [flags]` | クラスター内のマスターとサービスに関するエンドポイント情報を表示します。
|
||||
`completion` | `kubectl completion SHELL [options]` | 指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。
|
||||
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。
|
||||
`convert` | `kubectl convert -f FILENAME [options]` | 異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。
|
||||
`cordon` | `kubectl cordon NODE [options]` | Nodeをスケジュール不可に設定します。
|
||||
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | コンテナとの間でファイルやディレクトリをコピーします。
|
||||
`create` | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。
|
||||
`delete` | <code>kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]</code> | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。
|
||||
`describe` | <code>kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]</code> | 1つ以上のリソースの詳細な状態を表示します。
|
||||
`diff` | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。
|
||||
`drain` | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。
|
||||
`edit` | <code>kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]</code> | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。
|
||||
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。
|
||||
`explain` | `kubectl explain [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。
|
||||
`expose` | <code>kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。
|
||||
`get` | <code>kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]</code> | 1つ以上のリソースを表示します。
|
||||
`kustomize` | `kubectl kustomize <dir> [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。
|
||||
`label` | <code>kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのラベルを、追加または更新します。
|
||||
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。
|
||||
`options` | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。
|
||||
`patch` | <code>kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]</code> | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。
|
||||
`plugin` | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。
|
||||
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。
|
||||
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
|
||||
`replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
|
||||
`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
|
||||
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
|
||||
`scale` | <code>kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定したReplicationControllerのサイズを更新します。
|
||||
`set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。
|
||||
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。
|
||||
`top` | `kubectl top [flags] [options]` | リソース(CPU/メモリー/ストレージ)の使用量を表示します。
|
||||
`uncordon` | `kubectl uncordon NODE [options]` | Nodeをスケジュール可に設定します。
|
||||
`version` | `kubectl version [--client] [flags]` | クライアントとサーバーで実行中のKubernetesのバージョンを表示します。
|
||||
`wait` | <code>kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]</code> | 実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。
|
||||
|
||||
コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。
|
||||
|
||||
## リソースタイプ {#resource-types}
|
||||
|
||||
以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。
|
||||
|
||||
(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。)
|
||||
|
||||
| リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
|
||||
|---|---|---|---|---|
|
||||
| `bindings` | | | true | Binding|
|
||||
| `componentstatuses` | `cs` | | false | ComponentStatus |
|
||||
| `configmaps` | `cm` | | true | ConfigMap |
|
||||
| `endpoints` | `ep` | | true | Endpoints |
|
||||
| `limitranges` | `limits` | | true | LimitRange |
|
||||
| `namespaces` | `ns` | | false | Namespace |
|
||||
| `nodes` | `no` | | false | Node |
|
||||
| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
|
||||
| `persistentvolumes` | `pv` | | false | PersistentVolume |
|
||||
| `pods` | `po` | | true | Pod |
|
||||
| `podtemplates` | | | true | PodTemplate |
|
||||
| `replicationcontrollers` | `rc` | | true| ReplicationController |
|
||||
| `resourcequotas` | `quota` | | true | ResourceQuota |
|
||||
| `secrets` | | | true | Secret |
|
||||
| `serviceaccounts` | `sa` | | true | ServiceAccount |
|
||||
| `services` | `svc` | | true | Service |
|
||||
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
|
||||
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
|
||||
| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
|
||||
| `apiservices` | | apiregistration.k8s.io | false | APIService |
|
||||
| `controllerrevisions` | | apps | true | ControllerRevision |
|
||||
| `daemonsets` | `ds` | apps | true | DaemonSet |
|
||||
| `deployments` | `deploy` | apps | true | Deployment |
|
||||
| `replicasets` | `rs` | apps | true | ReplicaSet |
|
||||
| `statefulsets` | `sts` | apps | true | StatefulSet |
|
||||
| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
|
||||
| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
|
||||
| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
|
||||
| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
|
||||
| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
|
||||
| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
|
||||
| `cronjobs` | `cj` | batch | true | CronJob |
|
||||
| `jobs` | | batch | true | Job |
|
||||
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
|
||||
| `leases` | | coordination.k8s.io | true | Lease |
|
||||
| `events` | `ev` | events.k8s.io | true | Event |
|
||||
| `ingresses` | `ing` | extensions | true | Ingress |
|
||||
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
|
||||
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
|
||||
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
|
||||
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
|
||||
| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
|
||||
| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
|
||||
| `roles` | | rbac.authorization.k8s.io | true | Role |
|
||||
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
|
||||
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
|
||||
| `csinodes` | | storage.k8s.io | false | CSINode |
|
||||
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
|
||||
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
|
||||
|
||||
## 出力オプション
|
||||
|
||||
ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。
|
||||
|
||||
### 出力のフォーマット
|
||||
|
||||
すべての`kubectl`コマンドのデフォルトの出力フォーマットは、人間が読みやすいプレーンテキスト形式です。特定のフォーマットで、詳細をターミナルウィンドウに出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグのいずれかを追加します。
|
||||
|
||||
#### 構文
|
||||
|
||||
```shell
|
||||
kubectl [command] [TYPE] [NAME] -o <output_format>
|
||||
```
|
||||
|
||||
`kubectl`の操作に応じて、以下の出力フォーマットがサポートされています。
|
||||
|
||||
出力フォーマット | 説明
|
||||
--------------| -----------
|
||||
`-o custom-columns=<spec>` | [カスタムカラム](#custom-columns)のコンマ区切りのリストを使用して、テーブルを表示します。
|
||||
`-o custom-columns-file=<filename>` | `<filename>`ファイル内の[カスタムカラム](#custom-columns)のテンプレートを使用して、テーブルを表示します。
|
||||
`-o json` | JSON形式のAPIオブジェクトを出力します。
|
||||
`-o jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
|
||||
`-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
|
||||
`-o name` | リソース名のみを表示します。
|
||||
`-o wide` | 追加情報を含めて、プレーンテキスト形式で出力します。Podの場合は、Node名が含まれます。
|
||||
`-o yaml` | YAML形式のAPIオブジェクトを出力します。
|
||||
|
||||
##### 例
|
||||
|
||||
この例において、以下のコマンドは1つのPodの詳細を、YAML形式のオブジェクトとして出力します。
|
||||
|
||||
```shell
|
||||
kubectl get pod web-pod-13je7 -o yaml
|
||||
```
|
||||
|
||||
各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。
|
||||
|
||||
#### カスタムカラム {#custom-columns}
|
||||
|
||||
カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、`custom-columns`オプションを使います。カスタムカラムをインラインで定義するか、`-o custom-columns=<spec>`または`-o custom-columns-file=<filename>`のようにテンプレートファイルを使用するかを選択できます。
|
||||
|
||||
##### 例
|
||||
|
||||
インラインで定義する例は、以下の通りです。
|
||||
|
||||
```shell
|
||||
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
|
||||
```
|
||||
|
||||
テンプレートファイルを使用して定義する例は、以下の通りです。
|
||||
|
||||
```shell
|
||||
kubectl get pods <pod-name> -o custom-columns-file=template.txt
|
||||
```
|
||||
|
||||
ここで、`template.txt`には以下の内容が含まれます。
|
||||
|
||||
```
|
||||
NAME RSRC
|
||||
metadata.name metadata.resourceVersion
|
||||
```
|
||||
どちらのコマンドを実行した場合でも、以下の結果を得ます。
|
||||
|
||||
```
|
||||
NAME RSRC
|
||||
submit-queue 610995
|
||||
```
|
||||
|
||||
#### サーバーサイドカラム
|
||||
|
||||
`kubectl`は、サーバーからオブジェクトに関する特定のカラム情報を受け取ることをサポートしています。
|
||||
つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。
|
||||
これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。
|
||||
|
||||
この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
|
||||
|
||||
##### 例
|
||||
|
||||
Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。
|
||||
|
||||
```shell
|
||||
kubectl get pods <pod-name> --server-print=false
|
||||
```
|
||||
|
||||
以下のように出力されます。
|
||||
|
||||
```
|
||||
NAME AGE
|
||||
pod-name 1m
|
||||
```
|
||||
|
||||
### オブジェクトリストのソート
|
||||
|
||||
ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされている`kubectl`コマンドに`--sort-by`フラグを追加します。`--sort-by`フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式を使用します。
|
||||
|
||||
#### 構文
|
||||
|
||||
```shell
|
||||
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
|
||||
```
|
||||
|
||||
##### 例
|
||||
|
||||
名前でソートしたPodのリストを表示するには、以下のように実行します。
|
||||
|
||||
```shell
|
||||
kubectl get pods --sort-by=.metadata.name
|
||||
```
|
||||
|
||||
## 例: 一般的な操作
|
||||
|
||||
よく使われる`kubectl`の操作に慣れるために、以下の例を使用してください。
|
||||
|
||||
`kubectl apply` - ファイルや標準出力から、リソースの適用や更新を行います。
|
||||
|
||||
```shell
|
||||
# example-service.yaml内の定義を使用して、Serviceを作成します。
|
||||
kubectl apply -f example-service.yaml
|
||||
|
||||
# example-controller.yaml内の定義を使用して、ReplicationControllerを作成します。
|
||||
kubectl apply -f example-controller.yaml
|
||||
|
||||
# <directory>ディレクトリ内の、任意の.yaml、.yml、.jsonファイルで定義されているオブジェクトを作成します。
|
||||
kubectl apply -f <directory>
|
||||
```
|
||||
|
||||
`kubectl get` - 1つ以上のリソースの一覧を表示します。
|
||||
|
||||
```shell
|
||||
# すべてのPodの一覧をプレーンテキスト形式で表示します。
|
||||
kubectl get pods
|
||||
|
||||
# すべてのPodの一覧を、ノード名などの追加情報を含めて、プレーンテキスト形式で表示します。
|
||||
kubectl get pods -o wide
|
||||
|
||||
# 指定した名前のReplicationControllerの一覧をプレーンテキスト形式で表示します。'replicationcontroller'リソースタイプを短縮して、エイリアス'rc'で置き換えることもできます。
|
||||
kubectl get replicationcontroller <rc-name>
|
||||
|
||||
# すべてのReplicationControllerとServiceの一覧をまとめてプレーンテキスト形式で表示します。
|
||||
kubectl get rc,services
|
||||
|
||||
# すべてのDaemonSetの一覧をプレーンテキスト形式で表示します。
|
||||
kubectl get ds
|
||||
|
||||
# server01ノードで実行中のPodの一覧をプレーンテキスト形式で表示します。
|
||||
kubectl get pods --field-selector=spec.nodeName=server01
|
||||
```
|
||||
|
||||
`kubectl describe` - 1つ以上のリソースの詳細な状態を、デフォルトでは初期化されないものも含めて表示します。
|
||||
|
||||
```shell
|
||||
# Node <node-name>の詳細を表示します。
|
||||
kubectl describe nodes <node-name>
|
||||
|
||||
# Pod <pod-name>の詳細を表示します。
|
||||
kubectl describe pods/<pod-name>
|
||||
|
||||
# ReplicationController <rc-name>が管理しているすべてのPodの詳細を表示します。
|
||||
# ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。
|
||||
kubectl describe pods <rc-name>
|
||||
|
||||
# すべてのPodの詳細を表示します。
|
||||
kubectl describe pods
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl get`コマンドは通常、同じリソースタイプの1つ以上のリソースを取得するために使用します。豊富なフラグが用意されており、例えば`-o`や`--output`フラグを使って、出力フォーマットをカスタマイズできます。`-w`や`--watch`フラグを指定することで、特定のオブジェクトの更新を監視できます。`kubectl describe`コマンドは、指定されたリソースに関する多くの側面を説明することに重点を置いています。ユーザーに対してビューを構築するために、APIサーバーへ複数のAPIコールを呼び出すことができます。例えば、`kubectl describe node`コマンドは、Nodeに関する情報だけでなく、その上で動いているPodやNodeで生成されたイベントなどをまとめて表示します。
|
||||
{{< /note >}}
|
||||
|
||||
`kubectl delete` - ファイル、標準出力、または指定したラベルセレクター、名前、リソースセレクター、リソースを指定して、リソースを削除します。
|
||||
|
||||
```shell
|
||||
# pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。
|
||||
kubectl delete -f pod.yaml
|
||||
|
||||
# '<label-key>=<label-value>'というラベルを持つPodとServiceをすべて削除します。
|
||||
kubectl delete pods,services -l <label-key>=<label-value>
|
||||
|
||||
# 初期化されていないPodを含む、すべてのPodを削除します。
|
||||
kubectl delete pods --all
|
||||
```
|
||||
|
||||
`kubectl exec` - Pod内のコンテナに対してコマンドを実行します。
|
||||
|
||||
```shell
|
||||
# Pod <pod-name>から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。
|
||||
kubectl exec <pod-name> -- date
|
||||
|
||||
# Pod <pod-name>のコンテナ <container-name>から、'date'を実行している時の出力を取得します。
|
||||
kubectl exec <pod-name> -c <container-name> -- date
|
||||
|
||||
# インタラクティブな TTY を取得し、Pod <pod-name>から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。
|
||||
kubectl exec -ti <pod-name> -- /bin/bash
|
||||
```
|
||||
|
||||
`kubectl logs` - Pod内のコンテナのログを表示します。
|
||||
|
||||
```shell
|
||||
# Pod <pod-name>のログのスナップショットを返します。
|
||||
kubectl logs <pod-name>
|
||||
|
||||
# Pod <pod-name>から、ログのストリーミングを開始します。Linuxの'tail -f'コマンドと似ています。
|
||||
kubectl logs -f <pod-name>
|
||||
```
|
||||
|
||||
`kubectl diff` - 提案されたクラスタに対する更新の差分を表示します。
|
||||
|
||||
```shell
|
||||
# pod.jsonに含まれるリソースの差分を表示します。
|
||||
kubectl diff -f pod.json
|
||||
|
||||
# 標準出力から読み込んだファイルの差分を表示します。
|
||||
cat service.yaml | kubectl diff -f -
|
||||
```
|
||||
|
||||
## 例: プラグインの作成と使用
|
||||
|
||||
`kubectl`プラグインの書き方や使い方に慣れるために、以下の例を使用してください。
|
||||
|
||||
```shell
|
||||
# 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに
|
||||
# プレフィックス"kubectl-"で始まる名前を付けます。
|
||||
cat ./kubectl-hello
|
||||
```
|
||||
```shell
|
||||
#!/bin/sh
|
||||
|
||||
# このプラグインは、"hello world"という単語を表示します。
|
||||
echo "hello world"
|
||||
```
|
||||
プラグインを書いたら、実行可能にします。
|
||||
```bash
|
||||
chmod a+x ./kubectl-hello
|
||||
|
||||
# さらに、PATH内の場所に移動させます。
|
||||
sudo mv ./kubectl-hello /usr/local/bin
|
||||
sudo chown root:root /usr/local/bin
|
||||
|
||||
# これでkubectlプラグインを作成し、"インストール"できました。
|
||||
# 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。
|
||||
kubectl hello
|
||||
```
|
||||
```
|
||||
hello world
|
||||
```
|
||||
|
||||
```shell
|
||||
# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。
|
||||
sudo rm /usr/local/bin/kubectl-hello
|
||||
```
|
||||
|
||||
`kubectl`で利用可能なプラグインをすべて表示するには、`kubectl plugin list`サブコマンドを使用してください。
|
||||
|
||||
```shell
|
||||
kubectl plugin list
|
||||
```
|
||||
出力は以下のようになります。
|
||||
```
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
/usr/local/bin/kubectl-hello
|
||||
/usr/local/bin/kubectl-foo
|
||||
/usr/local/bin/kubectl-bar
|
||||
```
|
||||
|
||||
`kubectl plugin list`コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。
|
||||
```shell
|
||||
sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。
|
||||
kubectl plugin list
|
||||
```
|
||||
```
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
/usr/local/bin/kubectl-hello
|
||||
/usr/local/bin/kubectl-foo
|
||||
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
|
||||
/usr/local/bin/kubectl-bar
|
||||
|
||||
error: one plugin warning was found
|
||||
```
|
||||
|
||||
プラグインは、既存の`kubectl`コマンドの上に、より複雑な機能を構築するための手段であると考えることができます。
|
||||
|
||||
```shell
|
||||
cat ./kubectl-whoami
|
||||
```
|
||||
次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。
|
||||
```shell
|
||||
#!/bin/bash
|
||||
|
||||
# このプラグインは、`kubectl config`コマンドを使って
|
||||
# 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。
|
||||
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
|
||||
```
|
||||
|
||||
上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。
|
||||
|
||||
```shell
|
||||
# ファイルを実行可能にします。
|
||||
sudo chmod +x ./kubectl-whoami
|
||||
|
||||
# さらに、ファイルをPATHに移動します。
|
||||
sudo mv ./kubectl-whoami /usr/local/bin
|
||||
|
||||
kubectl whoami
|
||||
Current user: plugins-user
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* `kubectl`リファレンスドキュメントをお読みください。
|
||||
* kubectl[コマンドリファレンス](/docs/reference/kubectl/kubectl/)
|
||||
* [コマンドライン引数](/docs/reference/generated/kubectl/kubectl-commands/)リファレンス
|
||||
* [`kubectl`の使用規則](/ja/docs/reference/kubectl/conventions/)について学習してください。
|
||||
* kubectlの[JSONPathのサポート](/ja/docs/reference/kubectl/jsonpath/)についてお読みください。
|
||||
* [プラグインを使用して kubectl を拡張する](/docs/tasks/extend-kubectl/kubectl-plugins)方法についてお読みください。
|
||||
* プラグインについてより詳しく知りたい場合は、[example CLI plugin](https://github.com/kubernetes/sample-cli-plugin)をご覧ください。
|
||||
|
|
|
|||
|
|
@ -367,7 +367,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="registry
|
|||
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
|
||||
```
|
||||
|
||||
kubectlに関するより多くのサンプルは[カスタムカラムのリファレンス](/ja/docs/reference/kubectl/overview/#custom-columns)を参照してください。
|
||||
kubectlに関するより多くのサンプルは[カスタムカラムのリファレンス](/ja/docs/reference/kubectl/#custom-columns)を参照してください。
|
||||
|
||||
### Kubectlのログレベルとデバッグ
|
||||
kubectlのログレベルは、レベルを表す整数が後に続く`-v`または`--v`フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、[こちら](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)で説明します。
|
||||
|
|
@ -388,7 +388,7 @@ kubectlのログレベルは、レベルを表す整数が後に続く`-v`また
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* kubectlについてより深く学びたい方は[kubectl概要](/ja/docs/reference/kubectl/overview/)や[JsonPath](/docs/reference/kubectl/jsonpath)をご覧ください。
|
||||
* kubectlについてより深く学びたい方は[コマンドラインツール(kubectl)](/ja/docs/reference/kubectl/)や[JsonPath](/docs/reference/kubectl/jsonpath)をご覧ください。
|
||||
|
||||
* オプションについては[kubectl](/docs/reference/kubectl/kubectl/) optionsをご覧ください。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,485 +0,0 @@
|
|||
---
|
||||
title: kubectlの概要
|
||||
content_type: concept
|
||||
weight: 20
|
||||
card:
|
||||
name: reference
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
`kubectl`コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、`kubectl`は、`$HOME/.kube`ディレクトリにある`config`という名前のファイルを探します。他の[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)ファイルは、`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)フラグを設定することで指定できます。
|
||||
この概要では、`kubectl`の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、[kubectl](/docs/reference/generated/kubectl/kubectl-commands/)リファレンスドキュメントを参照してください。インストール方法については、[kubectlのインストールおよびセットアップ](/ja/docs/tasks/tools/install-kubectl/)をご覧ください。
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 構文
|
||||
|
||||
ターミナルウィンドウから`kubectl`コマンドを実行するには、以下の構文を使用します。
|
||||
|
||||
```shell
|
||||
kubectl [command] [TYPE] [NAME] [flags]
|
||||
```
|
||||
|
||||
ここで、`command`、`TYPE`、`NAME`、`flags`は、以下を表します。
|
||||
|
||||
* `command`: 1つ以上のリソースに対して実行したい操作を指定します。例えば、`create`、`get`、`describe`、`delete`です。
|
||||
|
||||
* `TYPE`: [リソースタイプ](#resource-types)を指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。
|
||||
|
||||
```shell
|
||||
kubectl get pod pod1
|
||||
kubectl get pods pod1
|
||||
kubectl get po pod1
|
||||
```
|
||||
|
||||
* `NAME`: リソースの名前を指定します。名前は大文字と小文字を区別します。`kubectl get pods`のように名前が省略された場合は、すべてのリソースの詳細が表示されます。
|
||||
|
||||
複数のリソースに対して操作を行う場合は、各リソースをタイプと名前で指定するか、1つまたは複数のファイルを指定することができます。
|
||||
|
||||
* リソースをタイプと名前で指定する場合
|
||||
|
||||
* タイプがすべて同じとき、リソースをグループ化するには`TYPE1 name1 name2 name<#>`とします。<br/>
|
||||
例: `kubectl get pod example-pod1 example-pod2`
|
||||
|
||||
* 複数のリソースタイプを個別に指定するには、`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`とします。<br/>
|
||||
例: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`
|
||||
|
||||
* リソースを1つ以上のファイルで指定する場合は、`-f file1 -f file2 -f file<#>`とします。
|
||||
|
||||
* 特に設定ファイルについては、YAMLの方がより使いやすいため、[JSONではなくYAMLを使用してください](/ja/docs/concepts/configuration/overview/#一般的な設定のtips)。<br/>
|
||||
例: `kubectl get pod -f ./pod.yaml`
|
||||
|
||||
* `flags`: オプションのフラグを指定します。例えば、`-s`または`--server`フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。<br/>
|
||||
|
||||
{{< caution >}}
|
||||
コマンドラインから指定したフラグは、デフォルト値および対応する任意の環境変数を上書きします。
|
||||
{{< /caution >}}
|
||||
|
||||
ヘルプが必要な場合は、ターミナルウィンドウから`kubectl help`を実行してください。
|
||||
|
||||
## 操作
|
||||
|
||||
以下の表に、`kubectl`のすべての操作の簡単な説明と一般的な構文を示します。
|
||||
|
||||
操作 | 構文 | 説明
|
||||
-------------------- | -------------------- | --------------------
|
||||
`alpha`| `kubectl alpha SUBCOMMAND [flags]` | アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。
|
||||
`annotate` | <code>kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのアノテーションを、追加または更新します。
|
||||
`api-resources` | `kubectl api-resources [flags]` | 利用可能なAPIリソースを一覧表示します。
|
||||
`api-versions` | `kubectl api-versions [flags]` | 利用可能なAPIバージョンを一覧表示します。
|
||||
`apply` | `kubectl apply -f FILENAME [flags]`| ファイルまたは標準出力から、リソースの設定変更を適用します。
|
||||
`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。
|
||||
`auth` | `kubectl auth [flags] [options]` | 認可を検査します。
|
||||
`autoscale` | <code>kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | ReplicationControllerで管理されているPodのセットを、自動的にスケールします。
|
||||
`certificate` | `kubectl certificate SUBCOMMAND [options]` | 証明書のリソースを変更します。
|
||||
`cluster-info` | `kubectl cluster-info [flags]` | クラスター内のマスターとサービスに関するエンドポイント情報を表示します。
|
||||
`completion` | `kubectl completion SHELL [options]` | 指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。
|
||||
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。
|
||||
`convert` | `kubectl convert -f FILENAME [options]` | 異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。
|
||||
`cordon` | `kubectl cordon NODE [options]` | Nodeをスケジュール不可に設定します。
|
||||
`cp` | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | コンテナとの間でファイルやディレクトリをコピーします。
|
||||
`create` | `kubectl create -f FILENAME [flags]` | ファイルまたは標準出力から、1つ以上のリソースを作成します。
|
||||
`delete` | <code>kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags]</code> | ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。
|
||||
`describe` | <code>kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags]</code> | 1つ以上のリソースの詳細な状態を表示します。
|
||||
`diff` | `kubectl diff -f FILENAME [flags]`| ファイルまたは標準出力と、現在の設定との差分を表示します。
|
||||
`drain` | `kubectl drain NODE [options]` | メンテナンスの準備のためにNodeをdrainします。
|
||||
`edit` | <code>kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags]</code> | デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。
|
||||
`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Pod内のコンテナに対して、コマンドを実行します。
|
||||
`explain` | `kubectl explain [--recursive=false] [flags]` | 様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。
|
||||
`expose` | <code>kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags]</code> | ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。
|
||||
`get` | <code>kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags]</code> | 1つ以上のリソースを表示します。
|
||||
`kustomize` | `kubectl kustomize <dir> [flags] [options]` | kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath，またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。
|
||||
`label` | <code>kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags]</code> | 1つ以上のリソースのラベルを、追加または更新します。
|
||||
`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Pod内のコンテナのログを表示します。
|
||||
`options` | `kubectl options` | すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。
|
||||
`patch` | <code>kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags]</code> | Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。
|
||||
`plugin` | `kubectl plugin [flags] [options]` | プラグインと対話するためのユーティリティを提供します。
|
||||
`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 1つ以上のローカルポートを、Podに転送します。
|
||||
`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Kubernetes APIサーバーへのプロキシーを実行します。
|
||||
`replace` | `kubectl replace -f FILENAME` | ファイルや標準出力から、リソースを置き換えます。
|
||||
`rollout` | `kubectl rollout SUBCOMMAND [options]` | リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。
|
||||
`run` | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags]</code> | 指定したイメージを、クラスタ上で実行します。
|
||||
`scale` | <code>kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | 指定したReplicationControllerのサイズを更新します。
|
||||
`set` | `kubectl set SUBCOMMAND [options]` | アプリケーションリソースを設定します。
|
||||
`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 1つ以上のNodeのtaintを更新します。
|
||||
`top` | `kubectl top [flags] [options]` | リソース(CPU/メモリー/ストレージ)の使用量を表示します。
|
||||
`uncordon` | `kubectl uncordon NODE [options]` | Nodeをスケジュール可に設定します。
|
||||
`version` | `kubectl version [--client] [flags]` | クライアントとサーバーで実行中のKubernetesのバージョンを表示します。
|
||||
`wait` | <code>kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options]</code> | 実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。
|
||||
|
||||
コマンド操作について詳しく知りたい場合は、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。
|
||||
|
||||
## リソースタイプ {#resource-types}
|
||||
|
||||
以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。
|
||||
|
||||
(この出力は`kubectl api-resources`から取得でき、Kubernetes 1.13.3時点で正確でした。)
|
||||
|
||||
| リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
|
||||
|---|---|---|---|---|
|
||||
| `bindings` | | | true | Binding|
|
||||
| `componentstatuses` | `cs` | | false | ComponentStatus |
|
||||
| `configmaps` | `cm` | | true | ConfigMap |
|
||||
| `endpoints` | `ep` | | true | Endpoints |
|
||||
| `limitranges` | `limits` | | true | LimitRange |
|
||||
| `namespaces` | `ns` | | false | Namespace |
|
||||
| `nodes` | `no` | | false | Node |
|
||||
| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
|
||||
| `persistentvolumes` | `pv` | | false | PersistentVolume |
|
||||
| `pods` | `po` | | true | Pod |
|
||||
| `podtemplates` | | | true | PodTemplate |
|
||||
| `replicationcontrollers` | `rc` | | true| ReplicationController |
|
||||
| `resourcequotas` | `quota` | | true | ResourceQuota |
|
||||
| `secrets` | | | true | Secret |
|
||||
| `serviceaccounts` | `sa` | | true | ServiceAccount |
|
||||
| `services` | `svc` | | true | Service |
|
||||
| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration |
|
||||
| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration |
|
||||
| `customresourcedefinitions` | `crd`, `crds` | apiextensions.k8s.io | false | CustomResourceDefinition |
|
||||
| `apiservices` | | apiregistration.k8s.io | false | APIService |
|
||||
| `controllerrevisions` | | apps | true | ControllerRevision |
|
||||
| `daemonsets` | `ds` | apps | true | DaemonSet |
|
||||
| `deployments` | `deploy` | apps | true | Deployment |
|
||||
| `replicasets` | `rs` | apps | true | ReplicaSet |
|
||||
| `statefulsets` | `sts` | apps | true | StatefulSet |
|
||||
| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
|
||||
| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
|
||||
| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
|
||||
| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
|
||||
| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
|
||||
| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
|
||||
| `cronjobs` | `cj` | batch | true | CronJob |
|
||||
| `jobs` | | batch | true | Job |
|
||||
| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest |
|
||||
| `leases` | | coordination.k8s.io | true | Lease |
|
||||
| `events` | `ev` | events.k8s.io | true | Event |
|
||||
| `ingresses` | `ing` | extensions | true | Ingress |
|
||||
| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy |
|
||||
| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget |
|
||||
| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy |
|
||||
| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding |
|
||||
| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
|
||||
| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
|
||||
| `roles` | | rbac.authorization.k8s.io | true | Role |
|
||||
| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass |
|
||||
| `csidrivers` | | storage.k8s.io | false | CSIDriver |
|
||||
| `csinodes` | | storage.k8s.io | false | CSINode |
|
||||
| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass |
|
||||
| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
|
||||
|
||||
## 出力オプション
|
||||
|
||||
ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントをご覧ください。
|
||||
|
||||
### 出力のフォーマット
|
||||
|
||||
すべての`kubectl`コマンドのデフォルトの出力フォーマットは、人間が読みやすいプレーンテキスト形式です。特定のフォーマットで、詳細をターミナルウィンドウに出力するには、サポートされている`kubectl`コマンドに`-o`または`--output`フラグのいずれかを追加します。
|
||||
|
||||
#### 構文
|
||||
|
||||
```shell
|
||||
kubectl [command] [TYPE] [NAME] -o <output_format>
|
||||
```
|
||||
|
||||
`kubectl`の操作に応じて、以下の出力フォーマットがサポートされています。
|
||||
|
||||
出力フォーマット | 説明
|
||||
--------------| -----------
|
||||
`-o custom-columns=<spec>` | [カスタムカラム](#custom-columns)のコンマ区切りのリストを使用して、テーブルを表示します。
|
||||
`-o custom-columns-file=<filename>` | `<filename>`ファイル内の[カスタムカラム](#custom-columns)のテンプレートを使用して、テーブルを表示します。
|
||||
`-o json` | JSON形式のAPIオブジェクトを出力します。
|
||||
`-o jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
|
||||
`-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。
|
||||
`-o name` | リソース名のみを表示します。
|
||||
`-o wide` | 追加情報を含めて、プレーンテキスト形式で出力します。Podの場合は、Node名が含まれます。
|
||||
`-o yaml` | YAML形式のAPIオブジェクトを出力します。
|
||||
|
||||
##### 例
|
||||
|
||||
この例において、以下のコマンドは1つのPodの詳細を、YAML形式のオブジェクトとして出力します。
|
||||
|
||||
```shell
|
||||
kubectl get pod web-pod-13je7 -o yaml
|
||||
```
|
||||
|
||||
各コマンドでサポートされている出力フォーマットの詳細については、[kubectl](/docs/reference/kubectl/kubectl/)リファレンスドキュメントを参照してください。
|
||||
|
||||
#### カスタムカラム {#custom-columns}
|
||||
|
||||
カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、`custom-columns`オプションを使います。カスタムカラムをインラインで定義するか、`-o custom-columns=<spec>`または`-o custom-columns-file=<filename>`のようにテンプレートファイルを使用するかを選択できます。
|
||||
|
||||
##### 例
|
||||
|
||||
インラインで定義する例は、以下の通りです。
|
||||
|
||||
```shell
|
||||
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
|
||||
```
|
||||
|
||||
テンプレートファイルを使用して定義する例は、以下の通りです。
|
||||
|
||||
```shell
|
||||
kubectl get pods <pod-name> -o custom-columns-file=template.txt
|
||||
```
|
||||
|
||||
ここで、`template.txt`には以下の内容が含まれます。
|
||||
|
||||
```
|
||||
NAME RSRC
|
||||
metadata.name metadata.resourceVersion
|
||||
```
|
||||
どちらのコマンドを実行した場合でも、以下の結果を得ます。
|
||||
|
||||
```
|
||||
NAME RSRC
|
||||
submit-queue 610995
|
||||
```
|
||||
|
||||
#### サーバーサイドカラム
|
||||
|
||||
`kubectl`は、サーバーからオブジェクトに関する特定のカラム情報を受け取ることをサポートしています。
|
||||
つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。
|
||||
これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。
|
||||
|
||||
この機能は、デフォルトで有効になっています。無効にするには、`kubectl get`コマンドに`--server-print=false`フラグを追加します。
|
||||
|
||||
##### 例
|
||||
|
||||
Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。
|
||||
|
||||
```shell
|
||||
kubectl get pods <pod-name> --server-print=false
|
||||
```
|
||||
|
||||
以下のように出力されます。
|
||||
|
||||
```
|
||||
NAME AGE
|
||||
pod-name 1m
|
||||
```
|
||||
|
||||
### オブジェクトリストのソート
|
||||
|
||||
ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされている`kubectl`コマンドに`--sort-by`フラグを追加します。`--sort-by`フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式を使用します。
|
||||
|
||||
#### 構文
|
||||
|
||||
```shell
|
||||
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
|
||||
```
|
||||
|
||||
##### 例
|
||||
|
||||
名前でソートしたPodのリストを表示するには、以下のように実行します。
|
||||
|
||||
```shell
|
||||
kubectl get pods --sort-by=.metadata.name
|
||||
```
|
||||
|
||||
## 例: 一般的な操作
|
||||
|
||||
よく使われる`kubectl`の操作に慣れるために、以下の例を使用してください。
|
||||
|
||||
`kubectl apply` - ファイルや標準出力から、リソースの適用や更新を行います。
|
||||
|
||||
```shell
|
||||
# example-service.yaml内の定義を使用して、Serviceを作成します。
|
||||
kubectl apply -f example-service.yaml
|
||||
|
||||
# example-controller.yaml内の定義を使用して、ReplicationControllerを作成します。
|
||||
kubectl apply -f example-controller.yaml
|
||||
|
||||
# <directory>ディレクトリ内の、任意の.yaml、.yml、.jsonファイルで定義されているオブジェクトを作成します。
|
||||
kubectl apply -f <directory>
|
||||
```
|
||||
|
||||
`kubectl get` - 1つ以上のリソースの一覧を表示します。
|
||||
|
||||
```shell
|
||||
# すべてのPodの一覧をプレーンテキスト形式で表示します。
|
||||
kubectl get pods
|
||||
|
||||
# すべてのPodの一覧を、ノード名などの追加情報を含めて、プレーンテキスト形式で表示します。
|
||||
kubectl get pods -o wide
|
||||
|
||||
# 指定した名前のReplicationControllerの一覧をプレーンテキスト形式で表示します。'replicationcontroller'リソースタイプを短縮して、エイリアス'rc'で置き換えることもできます。
|
||||
kubectl get replicationcontroller <rc-name>
|
||||
|
||||
# すべてのReplicationControllerとServiceの一覧をまとめてプレーンテキスト形式で表示します。
|
||||
kubectl get rc,services
|
||||
|
||||
# すべてのDaemonSetの一覧をプレーンテキスト形式で表示します。
|
||||
kubectl get ds
|
||||
|
||||
# server01ノードで実行中のPodの一覧をプレーンテキスト形式で表示します。
|
||||
kubectl get pods --field-selector=spec.nodeName=server01
|
||||
```
|
||||
|
||||
`kubectl describe` - 1つ以上のリソースの詳細な状態を、デフォルトでは初期化されないものも含めて表示します。
|
||||
|
||||
```shell
|
||||
# Node <node-name>の詳細を表示します。
|
||||
kubectl describe nodes <node-name>
|
||||
|
||||
# Pod <pod-name>の詳細を表示します。
|
||||
kubectl describe pods/<pod-name>
|
||||
|
||||
# ReplicationController <rc-name>が管理しているすべてのPodの詳細を表示します。
|
||||
# ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。
|
||||
kubectl describe pods <rc-name>
|
||||
|
||||
# すべてのPodの詳細を表示します。
|
||||
kubectl describe pods
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl get`コマンドは通常、同じリソースタイプの1つ以上のリソースを取得するために使用します。豊富なフラグが用意されており、例えば`-o`や`--output`フラグを使って、出力フォーマットをカスタマイズできます。`-w`や`--watch`フラグを指定することで、特定のオブジェクトの更新を監視できます。`kubectl describe`コマンドは、指定されたリソースに関する多くの側面を説明することに重点を置いています。ユーザーに対してビューを構築するために、APIサーバーへ複数のAPIコールを呼び出すことができます。例えば、`kubectl describe node`コマンドは、Nodeに関する情報だけでなく、その上で動いているPodやNodeで生成されたイベントなどをまとめて表示します。
|
||||
{{< /note >}}
|
||||
|
||||
`kubectl delete` - ファイル、標準出力、または指定したラベルセレクター、名前、リソースセレクター、リソースを指定して、リソースを削除します。
|
||||
|
||||
```shell
|
||||
# pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。
|
||||
kubectl delete -f pod.yaml
|
||||
|
||||
# '<label-key>=<label-value>'というラベルを持つPodとServiceをすべて削除します。
|
||||
kubectl delete pods,services -l <label-key>=<label-value>
|
||||
|
||||
# 初期化されていないPodを含む、すべてのPodを削除します。
|
||||
kubectl delete pods --all
|
||||
```
|
||||
|
||||
`kubectl exec` - Pod内のコンテナに対してコマンドを実行します。
|
||||
|
||||
```shell
|
||||
# Pod <pod-name>から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。
|
||||
kubectl exec <pod-name> -- date
|
||||
|
||||
# Pod <pod-name>のコンテナ <container-name>から、'date'を実行している時の出力を取得します。
|
||||
kubectl exec <pod-name> -c <container-name> -- date
|
||||
|
||||
# インタラクティブな TTY を取得し、Pod <pod-name>から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。
|
||||
kubectl exec -ti <pod-name> -- /bin/bash
|
||||
```
|
||||
|
||||
`kubectl logs` - Pod内のコンテナのログを表示します。
|
||||
|
||||
```shell
|
||||
# Pod <pod-name>のログのスナップショットを返します。
|
||||
kubectl logs <pod-name>
|
||||
|
||||
# Pod <pod-name>から、ログのストリーミングを開始します。Linuxの'tail -f'コマンドと似ています。
|
||||
kubectl logs -f <pod-name>
|
||||
```
|
||||
|
||||
`kubectl diff` - 提案されたクラスタに対する更新の差分を表示します。
|
||||
|
||||
```shell
|
||||
# pod.jsonに含まれるリソースの差分を表示します。
|
||||
kubectl diff -f pod.json
|
||||
|
||||
# 標準出力から読み込んだファイルの差分を表示します。
|
||||
cat service.yaml | kubectl diff -f -
|
||||
```
|
||||
|
||||
## 例: プラグインの作成と使用
|
||||
|
||||
`kubectl`プラグインの書き方や使い方に慣れるために、以下の例を使用してください。
|
||||
|
||||
```shell
|
||||
# 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに
|
||||
# プレフィックス"kubectl-"で始まる名前を付けます。
|
||||
cat ./kubectl-hello
|
||||
```
|
||||
```shell
|
||||
#!/bin/sh
|
||||
|
||||
# このプラグインは、"hello world"という単語を表示します。
|
||||
echo "hello world"
|
||||
```
|
||||
プラグインを書いたら、実行可能にします。
|
||||
```bash
|
||||
chmod a+x ./kubectl-hello
|
||||
|
||||
# さらに、PATH内の場所に移動させます。
|
||||
sudo mv ./kubectl-hello /usr/local/bin
|
||||
sudo chown root:root /usr/local/bin
|
||||
|
||||
# これでkubectlプラグインを作成し、"インストール"できました。
|
||||
# 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。
|
||||
kubectl hello
|
||||
```
|
||||
```
|
||||
hello world
|
||||
```
|
||||
|
||||
```shell
|
||||
# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。
|
||||
sudo rm /usr/local/bin/kubectl-hello
|
||||
```
|
||||
|
||||
`kubectl`で利用可能なプラグインをすべて表示するには、`kubectl plugin list`サブコマンドを使用してください。
|
||||
|
||||
```shell
|
||||
kubectl plugin list
|
||||
```
|
||||
出力は以下のようになります。
|
||||
```
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
/usr/local/bin/kubectl-hello
|
||||
/usr/local/bin/kubectl-foo
|
||||
/usr/local/bin/kubectl-bar
|
||||
```
|
||||
|
||||
`kubectl plugin list`コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。
|
||||
```shell
|
||||
sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。
|
||||
kubectl plugin list
|
||||
```
|
||||
```
|
||||
The following kubectl-compatible plugins are available:
|
||||
|
||||
/usr/local/bin/kubectl-hello
|
||||
/usr/local/bin/kubectl-foo
|
||||
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
|
||||
/usr/local/bin/kubectl-bar
|
||||
|
||||
error: one plugin warning was found
|
||||
```
|
||||
|
||||
プラグインは、既存の`kubectl`コマンドの上に、より複雑な機能を構築するための手段であると考えることができます。
|
||||
|
||||
```shell
|
||||
cat ./kubectl-whoami
|
||||
```
|
||||
次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。
|
||||
```shell
|
||||
#!/bin/bash
|
||||
|
||||
# このプラグインは、`kubectl config`コマンドを使って
|
||||
# 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。
|
||||
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
|
||||
```
|
||||
|
||||
上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。
|
||||
|
||||
```shell
|
||||
# ファイルを実行可能にします。
|
||||
sudo chmod +x ./kubectl-whoami
|
||||
|
||||
# さらに、ファイルをPATHに移動します。
|
||||
sudo mv ./kubectl-whoami /usr/local/bin
|
||||
|
||||
kubectl whoami
|
||||
Current user: plugins-user
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [kubectl](/docs/reference/generated/kubectl/kubectl-commands/)を使い始めてください。
|
||||
|
||||
* プラグインについてより詳しく知りたい場合は, [example cli plugin](https://github.com/kubernetes/sample-cli-plugin)を御覧ください。
|
||||
|
|
@ -198,7 +198,7 @@ MinikubeのサポートするKubernetesの機能:
|
|||
|
||||
`minikube start`コマンドを使用してクラスターを起動することができます。
|
||||
このコマンドはシングルノードのKubernetesクラスターを実行する仮想マシンを作成・設定します。
|
||||
また、このクラスターと通信する[kubectl](/ja/docs/reference/kubectl/overview/)のインストールも設定します。
|
||||
また、このクラスターと通信する[kubectl](/ja/docs/reference/kubectl/)のインストールも設定します。
|
||||
|
||||
{{< note >}}
|
||||
もしWebプロキシーを通している場合、そのプロキシー情報を`minikube start`コマンドに渡す必要があります:
|
||||
|
|
|
|||
|
|
@ -231,7 +231,7 @@ See the [list of add-ons](/ja/docs/concepts/cluster-administration/addons/) to e
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
|
||||
* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/ja/docs/reference/kubectl/).
|
||||
* Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
|
||||
* Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
|
||||
* Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
|
||||
|
|
|
|||
|
|
@ -394,7 +394,7 @@ kubectl delete node <node name>
|
|||
* [Sonobuoy](https://github.com/heptio/sonobuoy)を使用してクラスターが適切に動作しているか検証する。
|
||||
* <a id="lifecycle" />`kubeadm`を使用したクラスターをアップグレードする方法について、[kubeadmクラスターをアップグレードする](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を読む。
|
||||
* `kubeadm`の高度な利用方法について[kubeadmリファレンスドキュメント](/docs/reference/setup-tools/kubeadm/kubeadm)で学ぶ。
|
||||
* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/overview/)についてもっと学ぶ。
|
||||
* Kubernetesの[コンセプト](/ja/docs/concepts/)や[`kubectl`](/ja/docs/reference/kubectl/)についてもっと学ぶ。
|
||||
* Podネットワークアドオンのより完全なリストを[クラスターのネットワーク](/ja/docs/concepts/cluster-administration/networking/)で確認する。
|
||||
* <a id="other-addons" />ロギング、モニタリング、ネットワークポリシー、仮想化、Kubernetesクラスターの制御のためのツールなど、その他のアドオンについて、[アドオンのリスト](/ja/docs/concepts/cluster-administration/addons/)で確認する。
|
||||
* クラスターイベントやPod内で実行中のアプリケーションから送られるログをクラスターがハンドリングする方法を設定する。関係する要素の概要を理解するために、[ロギングのアーキテクチャ](/docs/concepts/cluster-administration/logging/)を読んでください。
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Windowsアプリケーションは、多くの組織で実行されるサービ
|
|||
## 始める前に
|
||||
|
||||
* [Windows Serverを実行するマスターノードとワーカーノード](/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)を含むKubernetesクラスターを作成します
|
||||
* Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/docs/reference/kubectl/overview/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。
|
||||
* Kubernetes上にServiceとワークロードを作成してデプロイすることは、LinuxコンテナとWindowsコンテナ共に、ほぼ同じように動作することに注意してください。クラスターとのインタフェースとなる[Kubectlコマンド](/ja/docs/reference/kubectl/)も同じです。Windowsコンテナをすぐに体験できる例を以下セクションに用意しています。
|
||||
|
||||
## はじめに:Windowsコンテナのデプロイ
|
||||
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ weight: 120
|
|||
<!-- overview -->
|
||||
このページでは、KubernetesのPodをKubernetesクラスター上の特定のノードに割り当てる方法を説明します。
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
## {{% heading "prerequisites" %}} {#before-you-begin}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## ラベルをノードに追加する
|
||||
## ラベルをノードに追加する {#add-a-label-to-a-node}
|
||||
|
||||
1. クラスター内の{{< glossary_tooltip term_id="node" text="ノード" >}}のリストをラベル付きで表示します。
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ weight: 120
|
|||
|
||||
上の出力を見ると、`worker0`に`disktype=ssd`というラベルがあることがわかります。
|
||||
|
||||
## 選択したノードにスケジューリングされるPodを作成する
|
||||
## 選択したノードにスケジューリングされるPodを作成する {#create-a-pod-that-gets-scheduled-to-your-chosen-node}
|
||||
|
||||
以下のPodの構成ファイルには、nodeSelectorに`disktype: ssd`を持つPodが書かれています。これにより、Podは`disktype: ssd`というラベルを持っているノードにスケジューリングされるようになります。
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ weight: 120
|
|||
nginx 1/1 Running 0 13s 10.200.0.4 worker0
|
||||
```
|
||||
|
||||
## 特定のノードにスケジューリングされるPodを作成する
|
||||
## 特定のノードにスケジューリングされるPodを作成する {#create-a-pod-that-gets-scheduled-to-specific-node}
|
||||
|
||||
`nodeName`という設定を使用して、Podを特定のノードにスケジューリングすることもできます。
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ card:
|
|||
---
|
||||
|
||||
<!-- overview -->
|
||||
Kubernetesのコマンドラインツールである[kubectl](/ja/docs/reference/kubectl/overview/)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理、検査およびログの表示を行うことができます。kubectlの操作に関する完全なリストは、[kubectlの概要](/ja/docs/reference/kubectl/overview/)を参照してください。
|
||||
Kubernetesのコマンドラインツールである[kubectl](/ja/docs/reference/kubectl/kubectl)を使用して、Kubernetesクラスターに対してコマンドを実行することができます。kubectlによってアプリケーションのデプロイや、クラスターのリソース管理、検査およびログの表示を行うことができます。kubectlの操作に関する完全なリストは、[kubectlリファレンスドキュメント](/ja/docs/reference/kubectl/)を参照してください。
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/) は、コンテナの管
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl`コマンドの詳細な情報は[kubectl overview](/ja/docs/reference/kubectl/overview/)を参照してください。
|
||||
`kubectl`コマンドの詳細な情報は[コマンドラインツール(kubectl)](/ja/docs/reference/kubectl/)を参照してください。
|
||||
{{< /note >}}
|
||||
|
||||
## Serviceの作成
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "k8s.gcr.io O registro de imagens será congelado a partir de 3 de abril de 2023"
|
||||
date: 2023-02-06
|
||||
slug: k8s-gcr-io-freeze-announcement
|
||||
---
|
||||
|
||||
**Autor**: Mahamed Ali (Rackspace Technology)
|
||||
|
||||
O projeto Kubernetes executa um registro de imagens de propriedade da comunidade chamado `registry.k8s.io` para hospedar suas imagens de contêiner.
|
||||
No dia 3 de abril de 2023, o antigo registro k8s.gcr.io será congelado e nenhuma nova imagem para o Kubernetes e subprojetos relacionados será enviada para o registro antigo.
|
||||
|
||||
Este registro `registry.k8s.io` substituiu o antigo e está disponível há vários meses. Publicamos uma [postagem no blog](/pt-br/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/) sobre seus benefícios para a comunidade e o projeto Kubernetes.
|
||||
Este post também anunciou que versões futuras do Kubernetes não estarão disponíveis no registro antigo. Agora chegou essa hora.
|
||||
|
||||
O que essa mudança significa para os colaboradores:
|
||||
- Se você é um mantenedor de um subprojeto, precisará atualizar seus manifestos e Helm charts para usar o novo registro.
|
||||
|
||||
O que essa mudança significa para os usuários finais:
|
||||
- A versão 1.27 do Kubernetes não será publicada no registro antigo.
|
||||
- As versões de patch para 1.24, 1.25 e 1.26 não serão mais publicadas no registro antigo a partir de abril. Leia a linha do tempo abaixo para obter detalhes sobre os lançamentos finais de patches no registro antigo.
|
||||
- A partir da versão 1.25, o registro de imagem padrão foi definido como `registry.k8s.io`. Este valor é substituível nos programas `kubeadm` e `kubelet`, mas defini-lo como `k8s.gcr.io` falhará para novas versões após abril, pois as imagens dessas novas versões não estarão disponíveis no registro antigo.
|
||||
- Se você quiser aumentar a confiabilidade do seu cluster e remover a dependência do registro de propriedade da comunidade ou se estiver executando o Kubernetes em redes onde o tráfego externo é restrito, considere hospedar uma cópia local do registro de imagens. Alguns fornecedores de nuvem podem oferecer soluções para isso.
|
||||
|
||||
## Linha do tempo das mudanças
|
||||
|
||||
- `k8s.gcr.io` será congelado no dia 3 de abril de 2023
|
||||
- Espera-se que a versão 1.27 seja lançada em 12 de abril de 2023
|
||||
- A última versão da 1.23 no `k8s.gcr.io` será 1.23.18 (a versão 1.23 deixará de ser suportada antes do congelamento do k8s.gcr.io)
|
||||
- A última versão 1.24 no `k8s.gcr.io` será 1.24.12
|
||||
- A última versão 1.25 no `k8s.gcr.io` será 1.25.8
|
||||
- A última versão 1.26 no `k8s.gcr.io` será 1.26.3
|
||||
|
||||
## Próximos passos
|
||||
|
||||
Certifique-se de que o seu cluster não tenha dependências no registro de imagens antigo. Por exemplo, você pode executar este comando para listar as imagens usadas pelos Pods:
|
||||
|
||||
```shell
|
||||
kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
|
||||
tr -s '[[:space:]]' '\n' |\
|
||||
sort |\
|
||||
uniq -c
|
||||
```
|
||||
|
||||
Pode haver outras dependências no antigo registro de imagens.
|
||||
Certifique-se de revisar quaisquer dependências potenciais para manter seu cluster saudável e atualizado.
|
||||
|
||||
## Agradecimentos
|
||||
|
||||
__A mudança é difícil__, e a evolução de nossa plataforma de serviço de imagem é necessária para garantir um futuro sustentável para o projeto. Nós nos esforçamos para melhorar as coisas para todos que utilizam o Kubernetes. Muitos colaboradores de todos os cantos da nossa comunidade têm trabalhado muito e com dedicação para garantir que estamos tomando as melhores decisões possíveis, executando planos e fazendo o nosso melhor para comunicar esses planos.
|
||||
|
||||
Obrigado a Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, e Tim Hockin do grupo de interesse especial (SIG) K8s Infra, Brian McQueen, e Sergey Kanzhelev do SIG Node, Lubomir Ivanov do SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, e Stephen Augustus do SIG Release, Bob Killen and Kaslin Fields do SIG Contribex, Tim Allclair do Comitê de Resposta de Segurança. Um grande obrigado também aos nossos amigos que atuam como pontos de contato com nossos provedores de nuvem parceiros: Jay Pipes da Amazon e Jon Johnson Jr. do Google.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
title: Rastreador de Issue Kubernetes
|
||||
weight: 10
|
||||
aliases: [/pt-br/cve/,/pt-br/cves/]
|
||||
---
|
||||
|
||||
Para reportar um problema de segurança, siga [processo de divulgação de segurança do Kubernetes](/docs/reference/issues-security/security/#report-a-vulnerability).
|
||||
|
||||
O trabalho no código do Kubernetes e os problemas de segurança podem ser encontrados usando [issues do GitHub](https://github.com/kubernetes/kubernetes/issues/).
|
||||
|
||||
* Lista [oficial de CVEs conhecidos](/docs/reference/issues-security/official-cve-feed/)
|
||||
(vulnerabilidades de segurança) que foram anunciados pelo
|
||||
[comitê de resposta de segurança](https://github.com/kubernetes/committee-security-response)
|
||||
* [Questões relacionadas ao CVE](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Aarea%2Fsecurity+in%3Atitle+CVE)
|
||||
|
||||
Anúncios relacionados à segurança são enviados para a lista de discussão [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce).
|
||||
|
|
@ -3,8 +3,10 @@ title: 节点与控制面之间的通信
|
|||
content_type: concept
|
||||
weight: 20
|
||||
---
|
||||
|
||||
<!--
|
||||
reviewers:
|
||||
- dchen1107
|
||||
- liggitt
|
||||
title: Communication between Nodes and the Control Plane
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -15,12 +17,14 @@ aliases:
|
|||
<!-- overview -->
|
||||
|
||||
<!--
|
||||
This document catalogs the communication paths between the API server and the Kubernetes cluster.
|
||||
This document catalogs the communication paths between the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}}
|
||||
and the Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}.
|
||||
The intent is to allow users to customize their installation to harden the network configuration
|
||||
such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud
|
||||
provider).
|
||||
-->
|
||||
本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。
|
||||
本文列举控制面节点（确切地说是 {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}}）和
|
||||
Kubernetes {{< glossary_tooltip text="集群" term_id="cluster" length="all" >}}之间的通信路径。
|
||||
目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，
|
||||
使得集群能够在不可信的网络上（或者在一个云服务商完全公开的 IP 上）运行。
|
||||
|
||||
|
|
@ -51,35 +55,38 @@ API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上
|
|||
或[服务账户令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。
|
||||
|
||||
<!--
|
||||
Nodes should be provisioned with the public root certificate for the cluster such that they can
|
||||
Nodes should be provisioned with the public root {{< glossary_tooltip text="certificate" term_id="certificate" >}} for the cluster such that they can
|
||||
connect securely to the API server along with valid client credentials. A good approach is that the
|
||||
client credentials provided to the kubelet are in the form of a client certificate. See
|
||||
[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
for automated provisioning of kubelet client certificates.
|
||||
-->
|
||||
应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。
|
||||
应该使用集群的公共根{{< glossary_tooltip text="证书" term_id="certificate" >}}开通节点，
|
||||
这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。
|
||||
一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。
|
||||
请查看 [kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
|
||||
以了解如何自动提供 kubelet 客户端证书。
|
||||
|
||||
<!--
|
||||
Pods that wish to connect to the API server can do so securely by leveraging a service account so
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}} that wish to connect to the API server can do so securely by leveraging a service account so
|
||||
that Kubernetes will automatically inject the public root certificate and a valid bearer token
|
||||
into the pod when it is instantiated.
|
||||
The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is
|
||||
redirected (via `kube-proxy`) to the HTTPS endpoint on the API server.
|
||||
redirected (via `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) to the HTTPS endpoint on the API server.
|
||||
|
||||
The control plane components also communicate with the API server over the secure port.
|
||||
-->
|
||||
想要连接到 API 服务器的 Pod 可以使用服务账号安全地进行连接。
|
||||
想要连接到 API 服务器的 {{< glossary_tooltip text="Pod" term_id="pod" >}}
|
||||
可以使用服务账号安全地进行连接。
|
||||
当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。
|
||||
`kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址，
|
||||
用于（通过 kube-proxy）转发请求到 API 服务器的 HTTPS 末端。
|
||||
用于（通过 `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`）转发请求到
|
||||
API 服务器的 HTTPS 末端。
|
||||
|
||||
控制面组件也通过安全端口与集群的 API 服务器通信。
|
||||
|
||||
<!--
|
||||
As a result, the default operating mode for connections from the nodes and pods running on the
|
||||
As a result, the default operating mode for connections from the nodes and pod running on the
|
||||
nodes to the control plane is secured by default and can run over untrusted and/or public
|
||||
networks.
|
||||
-->
|
||||
|
|
@ -90,15 +97,16 @@ networks.
|
|||
## Control plane to node
|
||||
|
||||
There are two primary communication paths from the control plane (the API server) to the nodes.
|
||||
The first is from the API server to the kubelet process which runs on each node in the cluster.
|
||||
The first is from the API server to the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} process which runs on each node in the cluster.
|
||||
The second is from the API server to any node, pod, or service through the API server's _proxy_
|
||||
functionality.
|
||||
-->
|
||||
## 控制面到节点 {#control-plane-to-node}
|
||||
|
||||
从控制面（API 服务器）到节点有两种主要的通信路径。
|
||||
第一种是从 API 服务器到集群中每个节点上运行的 kubelet 进程。
|
||||
第二种是从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。
|
||||
第一种是从 API 服务器到集群中每个节点上运行的
|
||||
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 进程。
|
||||
第二种是从 API 服务器通过它的**代理**功能连接到任何节点、Pod 或者服务。
|
||||
|
||||
<!--
|
||||
### API server to kubelet
|
||||
|
|
@ -117,8 +125,8 @@ attacks and **unsafe** to run over untrusted and/or public networks.
|
|||
|
||||
从 API 服务器到 kubelet 的连接用于：
|
||||
|
||||
* 获取 Pod 日志
|
||||
* 挂接（通过 kubectl）到运行中的 Pod
|
||||
* 获取 Pod 日志。
|
||||
* 挂接（通过 kubectl）到运行中的 Pod。
|
||||
* 提供 kubelet 的端口转发功能。
|
||||
|
||||
这些连接终止于 kubelet 的 HTTPS 末端。
|
||||
|
|
@ -167,7 +175,7 @@ connections **are not currently safe** to run over untrusted or public networks.
|
|||
<!--
|
||||
### SSH tunnels
|
||||
|
||||
Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this
|
||||
Kubernetes supports [SSH tunnels](https://www.ssh.com/academy/ssh/tunneling) to protect the control plane to nodes communication paths. In this
|
||||
configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to
|
||||
the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or
|
||||
service through the tunnel.
|
||||
|
|
@ -176,8 +184,9 @@ running.
|
|||
-->
|
||||
### SSH 隧道 {#ssh-tunnels}
|
||||
|
||||
Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，
|
||||
API 服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务器）
|
||||
Kubernetes 支持使用
|
||||
[SSH 隧道](https://www.ssh.com/academy/ssh/tunneling)来保护从控制面到节点的通信路径。
|
||||
在这种配置下，API 服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务器）
|
||||
并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。
|
||||
这一隧道保证通信不会被暴露到集群节点所运行的网络之外。
|
||||
|
||||
|
|
@ -219,3 +228,22 @@ Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
|
|||
请浏览 [Konnectivity 服务任务](/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
在你的集群中配置 Konnectivity 服务。
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read about the [Kubernetes control plane components](/docs/concepts/overview/components/#control-plane-components)
|
||||
* Learn more about [Hubs and Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors)
|
||||
* Learn how to [Secure a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
|
||||
* [Set up Konnectivity service](/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
* [Use Port Forwarding to Access Applications in a Cluster](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
* Learn how to [Fetch logs for Pods](/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs), [use kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod)
|
||||
-->
|
||||
* 阅读 [Kubernetes 控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)
|
||||
* 进一步了解 [Hubs and Spoke model](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors)
|
||||
* 进一步了解如何[保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)
|
||||
* 进一步了解 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)
|
||||
* [设置 Konnectivity 服务](/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity/)
|
||||
* [使用端口转发来访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
|
||||
* 学习如何[检查 Pod 的日志](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs)
|
||||
以及如何[使用 kubectl 端口转发](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod)
|
||||
|
|
|
|||
|
|
@ -20,27 +20,23 @@ of a cluster.
|
|||
使用 kubeconfig 文件来组织有关集群、用户、命名空间和身份认证机制的信息。
|
||||
`kubectl` 命令行工具使用 kubeconfig 文件来查找选择集群所需的信息，并与集群的 API 服务器进行通信。
|
||||
|
||||
<!--
|
||||
{{< note >}}
|
||||
<!--
|
||||
A file that is used to configure access to clusters is called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
{{< /note >}}
|
||||
-->
|
||||
{{< note >}}
|
||||
用于配置集群访问的文件称为“kubeconfig 文件”。
|
||||
这是引用配置文件的通用方法，并不意味着有一个名为 `kubeconfig` 的文件
|
||||
用于配置集群访问的文件称为 **kubeconfig 文件**。
|
||||
这是引用到配置文件的通用方法，并不意味着有一个名为 `kubeconfig` 的文件。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
{{< warning >}}
|
||||
<!--
|
||||
Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
|
||||
If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
|
||||
{{< /warning>}}
|
||||
-->
|
||||
{{< warning >}}
|
||||
只使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。
|
||||
如果必须使用不受信任的 kubeconfig 文件，请首先像检查 shell 脚本一样仔细检查它。
|
||||
请务必仅使用来源可靠的 kubeconfig 文件。使用特制的 kubeconfig 文件可能会导致恶意代码执行或文件暴露。
|
||||
如果必须使用不受信任的 kubeconfig 文件，请首先像检查 Shell 脚本一样仔细检查此文件。
|
||||
{{< /warning>}}
|
||||
|
||||
<!--
|
||||
|
|
@ -57,15 +53,15 @@ variable or by setting the
|
|||
For step-by-step instructions on creating and specifying kubeconfig files, see
|
||||
[Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
|
||||
-->
|
||||
有关创建和指定 kubeconfig 文件的分步说明，请参阅
|
||||
[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
|
||||
有关创建和指定 kubeconfig 文件的分步说明，
|
||||
请参阅[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。
|
||||
|
||||
<!-- body -->
|
||||
|
||||
<!--
|
||||
## Supporting multiple clusters, users, and authentication mechanisms
|
||||
-->
|
||||
## 支持多集群、用户和身份认证机制
|
||||
## 支持多集群、用户和身份认证机制 {#support-clusters-users-and-authn}
|
||||
|
||||
<!--
|
||||
Suppose you have several clusters, and your users and components authenticate
|
||||
|
|
@ -92,7 +88,7 @@ clusters and namespaces.
|
|||
<!--
|
||||
## Context
|
||||
-->
|
||||
## 上下文（Context）
|
||||
## 上下文（Context） {#context}
|
||||
|
||||
<!--
|
||||
A *context* element in a kubeconfig file is used to group access parameters
|
||||
|
|
@ -107,7 +103,7 @@ the *current context* to communicate with the cluster.
|
|||
<!--
|
||||
To choose the current context:
|
||||
-->
|
||||
选择当前上下文
|
||||
选择当前上下文：
|
||||
|
||||
```shell
|
||||
kubectl config use-context
|
||||
|
|
@ -116,7 +112,7 @@ kubectl config use-context
|
|||
<!--
|
||||
## The KUBECONFIG environment variable
|
||||
-->
|
||||
## KUBECONFIG 环境变量
|
||||
## KUBECONFIG 环境变量 {#kubeconfig-env-var}
|
||||
|
||||
<!--
|
||||
The `KUBECONFIG` environment variable holds a list of kubeconfig files.
|
||||
|
|
@ -126,21 +122,21 @@ required. If the `KUBECONFIG` environment variable doesn't exist,
|
|||
`kubectl` uses the default kubeconfig file, `$HOME/.kube/config`.
|
||||
-->
|
||||
`KUBECONFIG` 环境变量包含一个 kubeconfig 文件列表。
|
||||
对于 Linux 和 Mac，列表以冒号分隔。对于 Windows，列表以分号分隔。
|
||||
`KUBECONFIG` 环境变量不是必要的。
|
||||
如果 `KUBECONFIG` 环境变量不存在，`kubectl` 使用默认的 kubeconfig 文件，`$HOME/.kube/config`。
|
||||
对于 Linux 和 Mac，此列表以英文冒号分隔。对于 Windows，此列表以英文分号分隔。
|
||||
`KUBECONFIG` 环境变量不是必需的。
|
||||
如果 `KUBECONFIG` 环境变量不存在，`kubectl` 将使用默认的 kubeconfig 文件：`$HOME/.kube/config`。
|
||||
|
||||
<!--
|
||||
If the `KUBECONFIG` environment variable does exist, `kubectl` uses
|
||||
an effective configuration that is the result of merging the files
|
||||
listed in the `KUBECONFIG` environment variable.
|
||||
-->
|
||||
如果 `KUBECONFIG` 环境变量存在，`kubectl` 使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。
|
||||
如果 `KUBECONFIG` 环境变量存在，`kubectl` 将使用 `KUBECONFIG` 环境变量中列举的文件合并后的有效配置。
|
||||
|
||||
<!--
|
||||
## Merging kubeconfig files
|
||||
-->
|
||||
## 合并 kubeconfig 文件
|
||||
## 合并 kubeconfig 文件 {#merge-kubeconfig-files}
|
||||
|
||||
<!--
|
||||
To see your configuration, enter this command:
|
||||
|
|
@ -155,7 +151,7 @@ kubectl config view
|
|||
As described previously, the output might be from a single kubeconfig file,
|
||||
or it might be the result of merging several kubeconfig files.
|
||||
-->
|
||||
如前所述，输出可能来自 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。
|
||||
如前所述，输出可能来自单个 kubeconfig 文件，也可能是合并多个 kubeconfig 文件的结果。
|
||||
|
||||
<!--
|
||||
Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
||||
|
|
@ -186,34 +182,36 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
|||
* 忽略空文件名。
|
||||
* 对于内容无法反序列化的文件，产生错误信息。
|
||||
* 第一个设置特定值或者映射键的文件将生效。
|
||||
* 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 `current-context`。示例：如果两个文件都指定了 `red-user`，则仅使用第一个文件的 `red-user` 中的值。即使第二个文件在 `red-user` 下有非冲突条目，也要丢弃它们。
|
||||
* 永远不会更改值或者映射键。示例：保留第一个文件的上下文以设置 `current-context`。
|
||||
示例：如果两个文件都指定了 `red-user`，则仅使用第一个文件的 `red-user` 中的值。
|
||||
即使第二个文件在 `red-user` 下有非冲突条目，也要丢弃它们。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
For an example of setting the `KUBECONFIG` environment variable, see
|
||||
[Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
|
||||
-->
|
||||
有关设置 `KUBECONFIG` 环境变量的示例，请参阅
|
||||
[设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
|
||||
-->
|
||||
有关设置 `KUBECONFIG` 环境变量的示例，
|
||||
请参阅[设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
Otherwise, use the default kubeconfig file, `$HOME/.kube/config`, with no merging.
|
||||
-->
|
||||
否则，使用默认的 kubeconfig 文件， `$HOME/.kube/config`，不进行合并。
|
||||
-->
|
||||
否则，使用默认的 kubeconfig 文件（`$HOME/.kube/config`），不进行合并。
|
||||
|
||||
<!--
|
||||
1. Determine the context to use based on the first hit in this chain:
|
||||
|
||||
1. Use the `--context` command-line flag if it exists.
|
||||
2. Use the `current-context` from the merged kubeconfig files.
|
||||
1. Use the `current-context` from the merged kubeconfig files.
|
||||
-->
|
||||
2. 根据此链中的第一个匹配确定要使用的上下文。
|
||||
|
||||
1. 如果存在，使用 `--context` 命令行参数。
|
||||
1. 如果存在上下文，则使用 `--context` 命令行参数。
|
||||
2. 使用合并的 kubeconfig 文件中的 `current-context`。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
An empty context is allowed at this point.
|
||||
-->
|
||||
-->
|
||||
这种场景下允许空上下文。
|
||||
|
||||
<!--
|
||||
|
|
@ -222,16 +220,17 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
|||
which is run twice: once for user and once for cluster:
|
||||
|
||||
1. Use a command-line flag if it exists: `--user` or `--cluster`.
|
||||
2. If the context is non-empty, take the user or cluster from the context.
|
||||
1. If the context is non-empty, take the user or cluster from the context.
|
||||
-->
|
||||
3. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，这将运行两次：一次用于用户，一次用于集群。
|
||||
3. 确定集群和用户。此时，可能有也可能没有上下文。根据此链中的第一个匹配确定集群和用户，
|
||||
这将运行两次：一次用于用户，一次用于集群。
|
||||
|
||||
1. 如果存在，使用命令行参数：`--user` 或者 `--cluster`。
|
||||
2. 如果上下文非空，从上下文中获取用户或集群。
|
||||
1. 如果存在用户或集群，则使用命令行参数：`--user` 或者 `--cluster`。
|
||||
2. 如果上下文非空，则从上下文中获取用户或集群。
|
||||
|
||||
<!--
|
||||
<!--
|
||||
The user and cluster can be empty at this point.
|
||||
-->
|
||||
-->
|
||||
这种场景下用户和集群可以为空。
|
||||
|
||||
<!--
|
||||
|
|
@ -240,32 +239,33 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
|||
Build each piece of the cluster information based on this chain; the first hit wins:
|
||||
|
||||
1. Use command line flags if they exist: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`.
|
||||
2. If any cluster information attributes exist from the merged kubeconfig files, use them.
|
||||
3. If there is no server location, fail.
|
||||
1. If any cluster information attributes exist from the merged kubeconfig files, use them.
|
||||
1. If there is no server location, fail.
|
||||
-->
|
||||
4. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。基于此链构建每个集群信息；第一个匹配项会被采用：
|
||||
4. 确定要使用的实际集群信息。此时，可能有也可能没有集群信息。
|
||||
基于此链构建每个集群信息；第一个匹配项会被采用：
|
||||
|
||||
1. 如果存在：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`，使用命令行参数。
|
||||
2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用它们。
|
||||
1. 如果存在集群信息，则使用命令行参数：`--server`、`--certificate-authority` 和 `--insecure-skip-tls-verify`。
|
||||
2. 如果合并的 kubeconfig 文件中存在集群信息属性，则使用这些属性。
|
||||
3. 如果没有 server 配置，则配置无效。
|
||||
|
||||
<!--
|
||||
2. Determine the actual user information to use. Build user information using the same
|
||||
1. Determine the actual user information to use. Build user information using the same
|
||||
rules as cluster information, except allow only one authentication
|
||||
technique per user:
|
||||
|
||||
1. Use command line flags if they exist: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`.
|
||||
2. Use the `user` fields from the merged kubeconfig files.
|
||||
3. If there are two conflicting techniques, fail.
|
||||
1. Use the `user` fields from the merged kubeconfig files.
|
||||
1. If there are two conflicting techniques, fail.
|
||||
-->
|
||||
5. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但每个用户只允许一种身份认证技术：
|
||||
5. 确定要使用的实际用户信息。使用与集群信息相同的规则构建用户信息，但对于每个用户只允许使用一种身份认证技术：
|
||||
|
||||
1. 如果存在：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`，使用命令行参数。
|
||||
1. 如果存在用户信息，则使用命令行参数：`--client-certificate`、`--client-key`、`--username`、`--password` 和 `--token`。
|
||||
2. 使用合并的 kubeconfig 文件中的 `user` 字段。
|
||||
3. 如果存在两种冲突技术，则配置无效。
|
||||
|
||||
<!--
|
||||
3. For any information still missing, use default values and potentially
|
||||
1. For any information still missing, use default values and potentially
|
||||
prompt for authentication information.
|
||||
-->
|
||||
6. 对于仍然缺失的任何信息，使用其对应的默认值，并可能提示输入身份认证信息。
|
||||
|
|
@ -273,7 +273,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files:
|
|||
<!--
|
||||
## File references
|
||||
-->
|
||||
## 文件引用
|
||||
## 文件引用 {#file-reference}
|
||||
|
||||
<!--
|
||||
File and path references in a kubeconfig file are relative to the location of the kubeconfig file.
|
||||
|
|
@ -283,14 +283,14 @@ are stored absolutely.
|
|||
-->
|
||||
kubeconfig 文件中的文件和路径引用是相对于 kubeconfig 文件的位置。
|
||||
命令行上的文件引用是相对于当前工作目录的。
|
||||
在 `$HOME/.kube/config` 中，相对路径按相对路径存储，绝对路径按绝对路径存储。
|
||||
在 `$HOME/.kube/config` 中，相对路径按相对路径存储，而绝对路径按绝对路径存储。
|
||||
|
||||
<!--
|
||||
## Proxy
|
||||
|
||||
You can configure `kubectl` to use a proxy per cluster using `proxy-url` in your kubeconfig file, like this:
|
||||
-->
|
||||
## 代理
|
||||
## 代理 {#proxy}
|
||||
|
||||
你可以在 `kubeconfig` 文件中，为每个集群配置 `proxy-url` 来让 `kubectl` 使用代理，例如：
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,8 @@ content_type: concept
|
|||
weight: 10
|
||||
---
|
||||
<!--
|
||||
reviewers:
|
||||
- janetkuo
|
||||
title: Deployments
|
||||
feature:
|
||||
title: Automated rollouts and rollbacks
|
||||
|
|
@ -80,7 +82,7 @@ The following are typical use cases for Deployments:
|
|||
* [清理较旧的不再需要的 ReplicaSet](#clean-up-policy) 。
|
||||
|
||||
<!--
|
||||
## Creating a Deployment
|
||||
## Creating a Deployment
|
||||
|
||||
The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods:
|
||||
-->
|
||||
|
|
@ -97,8 +99,8 @@ In this example:
|
|||
|
||||
<!--
|
||||
* A Deployment named `nginx-deployment` is created, indicated by the
|
||||
`.metadata.name` field. This name will become the basis for the ReplicaSets
|
||||
and Pods which are created later. See [Writing a Deployment Spec](#writing-a-deployment-spec)
|
||||
`.metadata.name` field. This name will become the basis for the ReplicaSets
|
||||
and Pods which are created later. See [Writing a Deployment Spec](#writing-a-deployment-spec)
|
||||
for more details.
|
||||
* The Deployment creates a ReplicaSet that creates three replicated Pods, indicated by the `.spec.replicas` field.
|
||||
* The `.spec.selector` field defines how the created ReplicaSet finds which Pods to manage.
|
||||
|
|
@ -116,12 +118,12 @@ In this example:
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `spec.selector.matchLabels` field is a map of {key,value} pairs.
|
||||
The `.spec.selector.matchLabels` field is a map of {key,value} pairs.
|
||||
A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`,
|
||||
whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value".
|
||||
All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match.
|
||||
-->
|
||||
`spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。
|
||||
`.spec.selector.matchLabels` 字段是 `{key,value}` 键值对映射。
|
||||
在 `matchLabels` 映射中的每个 `{key,value}` 映射等效于 `matchExpressions` 中的一个元素，
|
||||
即其 `key` 字段是 “key”，`operator` 为 “In”，`values` 数组仅包含 “value”。
|
||||
在 `matchLabels` 和 `matchExpressions` 中给出的所有条件都必须满足才能匹配。
|
||||
|
|
@ -158,9 +160,9 @@ Follow the steps given below to create the above Deployment:
|
|||
```
|
||||
|
||||
<!--
|
||||
2. Run `kubectl get deployments` to check if the Deployment was created.
|
||||
2. Run `kubectl get deployments` to check if the Deployment was created.
|
||||
|
||||
If the Deployment is still being created, the output is similar to the following:
|
||||
If the Deployment is still being created, the output is similar to the following:
|
||||
-->
|
||||
2. 运行 `kubectl get deployments` 检查 Deployment 是否已创建。
|
||||
如果仍在创建 Deployment，则输出类似于：
|
||||
|
|
@ -208,7 +210,7 @@ Follow the steps given below to create the above Deployment:
|
|||
```
|
||||
|
||||
<!--
|
||||
4. Run the `kubectl get deployments` again a few seconds later.
|
||||
4. Run the `kubectl get deployments` again a few seconds later.
|
||||
The output is similar to this:
|
||||
-->
|
||||
4. 几秒钟后再次运行 `kubectl get deployments`。输出类似于：
|
||||
|
|
@ -255,7 +257,7 @@ Follow the steps given below to create the above Deployment:
|
|||
|
||||
<!--
|
||||
Notice that the name of the ReplicaSet is always formatted as
|
||||
`[DEPLOYMENT-NAME]-[HASH]`. This name will become the basis for the Pods
|
||||
`[DEPLOYMENT-NAME]-[HASH]`. This name will become the basis for the Pods
|
||||
which are created.
|
||||
The `HASH` string is the same as the `pod-template-hash` label on the ReplicaSet.
|
||||
-->
|
||||
|
|
@ -296,7 +298,7 @@ Kubernetes 不会阻止你这样做，但是如果多个控制器具有重叠的
|
|||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Pod-template-hash label
|
||||
### Pod-template-hash label
|
||||
-->
|
||||
### Pod-template-hash 标签
|
||||
|
||||
|
|
@ -323,13 +325,13 @@ and in any existing Pods that the ReplicaSet might have.
|
|||
可能拥有的任何现有 Pod 中。
|
||||
|
||||
<!--
|
||||
## Updating a Deployment
|
||||
## Updating a Deployment
|
||||
-->
|
||||
## 更新 Deployment {#updating-a-deployment}
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, `.spec.template`)
|
||||
A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, `.spec.template`)
|
||||
is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.
|
||||
-->
|
||||
仅当 Deployment Pod 模板（即 `.spec.template`）发生改变时，例如模板的标签或容器镜像被更新，
|
||||
|
|
@ -353,7 +355,7 @@ Follow the steps given below to update your Deployment:
|
|||
or use the following command:
|
||||
-->
|
||||
或者使用下面的命令：
|
||||
|
||||
|
||||
```shell
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
|
||||
```
|
||||
|
|
@ -492,7 +494,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
|||
then deletes an old Pod, and creates another new one. It does not kill old Pods until a sufficient number of
|
||||
new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed.
|
||||
It makes sure that at least 3 Pods are available and that at max 4 Pods in total are available. In case of
|
||||
a Deployment with 4 replicas, the number of Pods would be between 3 and 5.
|
||||
a Deployment with 4 replicas, the number of Pods would be between 3 and 5.
|
||||
-->
|
||||
例如，如果仔细查看上述 Deployment ，将看到它首先创建了一个新的 Pod，然后删除旧的 Pod，
|
||||
并创建了新的 Pod。它不会杀死旧 Pod，直到有足够数量的新 Pod 已经出现。
|
||||
|
|
@ -559,8 +561,7 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
|
|||
(nginx-deployment-1564180365) and scaled it up to 1 and waited for it to come up. Then it scaled down the old ReplicaSet
|
||||
to 2 and scaled up the new ReplicaSet to 2 so that at least 3 Pods were available and at most 4 Pods were created at all times.
|
||||
It then continued scaling up and down the new and the old ReplicaSet, with the same rolling update strategy.
|
||||
Finally, you'll have 3 available replicas
|
||||
in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
|
||||
Finally, you'll have 3 available replicas in the new ReplicaSet, and the old ReplicaSet is scaled down to 0.
|
||||
-->
|
||||
可以看到，当第一次创建 Deployment 时，它创建了一个 ReplicaSet（`nginx-deployment-2035384211`）
|
||||
并将其直接扩容至 3 个副本。更新 Deployment 时，它创建了一个新的 ReplicaSet
|
||||
|
|
@ -624,7 +625,7 @@ before changing course.
|
|||
<!--
|
||||
### Label selector updates
|
||||
|
||||
It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front.
|
||||
It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front.
|
||||
In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped
|
||||
all of the implications.
|
||||
-->
|
||||
|
|
@ -665,7 +666,7 @@ removed label still exists in any existing Pods and ReplicaSets.
|
|||
## 回滚 Deployment {#rolling-back-a-deployment}
|
||||
|
||||
<!--
|
||||
Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
|
||||
Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping.
|
||||
By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want
|
||||
(you can change that by modifying revision history limit).
|
||||
-->
|
||||
|
|
@ -697,7 +698,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
|
|||
`nginx:1.161` 而不是 `nginx:1.16.1`：
|
||||
|
||||
```shell
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
|
||||
kubectl set image deployment/nginx-deployment nginx=nginx:1.161
|
||||
```
|
||||
|
||||
<!--
|
||||
|
|
@ -734,7 +735,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
|
|||
* 按 Ctrl-C 停止上述上线状态观测。有关上线停滞的详细信息，[参考这里](#deployment-status)。
|
||||
|
||||
<!--
|
||||
* You see that the number of old replicas (`nginx-deployment-1564180365` and `nginx-deployment-2035384211`) is 2, and new replicas (nginx-deployment-3066724191) is 1.
|
||||
* You see that the number of old replicas (`nginx-deployment-1564180365` and `nginx-deployment-2035384211`) is 2, and new replicas (nginx-deployment-3066724191) is 1.
|
||||
-->
|
||||
* 你可以看到旧的副本有两个（`nginx-deployment-1564180365` 和 `nginx-deployment-2035384211`），
|
||||
新的副本有 1 个（`nginx-deployment-3066724191`）：
|
||||
|
|
@ -748,7 +749,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1564180365 3 3 3 25s
|
||||
nginx-deployment-2035384211 0 0 0 36s
|
||||
|
|
@ -769,7 +770,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
|
||||
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
|
||||
|
|
@ -828,7 +829,7 @@ Deployment 被触发上线时，系统就会创建 Deployment 的新的修订版
|
|||
OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created)
|
||||
NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created)
|
||||
Events:
|
||||
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
|
||||
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
|
||||
--------- -------- ----- ---- ------------- -------- ------ -------
|
||||
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
|
||||
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
|
||||
|
|
@ -855,7 +856,7 @@ Follow the steps given below to check the rollout history:
|
|||
按照如下步骤检查回滚历史：
|
||||
|
||||
<!--
|
||||
1. First, check the revisions of this Deployment:
|
||||
1. First, check the revisions of this Deployment:
|
||||
-->
|
||||
1. 首先，检查 Deployment 修订历史：
|
||||
|
||||
|
|
@ -929,7 +930,7 @@ Follow the steps given below to rollback the Deployment from the current version
|
|||
按照下面给出的步骤将 Deployment 从当前版本回滚到以前的版本（即版本 2）。
|
||||
|
||||
<!--
|
||||
1. Now you've decided to undo the current rollout and rollback to the previous revision:
|
||||
1. Now you've decided to undo the current rollout and rollback to the previous revision:
|
||||
-->
|
||||
1. 假定现在你已决定撤消当前上线并回滚到以前的修订版本：
|
||||
|
||||
|
|
@ -1229,7 +1230,7 @@ The output is similar to this:
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-deployment-1989198191 7 7 0 7m
|
||||
nginx-deployment-618515232 11 11 11 7m
|
||||
|
|
@ -1307,7 +1308,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
```
|
||||
deployment.apps/nginx-deployment paused
|
||||
```
|
||||
|
||||
|
|
@ -1363,7 +1364,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
```
|
||||
NAME DESIRED CURRENT READY AGE
|
||||
nginx-2142116321 3 3 3 2m
|
||||
```
|
||||
|
|
@ -1388,7 +1389,8 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
|
|||
|
||||
<!--
|
||||
The initial state of the Deployment prior to pausing its rollout will continue its function, but new updates to
|
||||
the Deployment will not have any effect as long as the Deployment is paused.
|
||||
the Deployment will not have any effect as long as the Deployment rollout is paused.
|
||||
|
||||
-->
|
||||
暂停 Deployment 上线之前的初始状态将继续发挥作用，但新的更新在 Deployment
|
||||
上线被暂停期间不会产生任何效果。
|
||||
|
|
@ -1573,7 +1575,7 @@ The output is similar to this:
|
|||
-->
|
||||
输出类似于：
|
||||
|
||||
```shell
|
||||
```
|
||||
Waiting for rollout to finish: 2 of 3 updated replicas are available...
|
||||
deployment "nginx-deployment" successfully rolled out
|
||||
```
|
||||
|
|
@ -1584,7 +1586,7 @@ and the exit status from `kubectl rollout` is 0 (success):
|
|||
从 `kubectl rollout` 命令获得的返回状态为 0（成功）：
|
||||
|
||||
```shell
|
||||
$ echo $?
|
||||
echo $?
|
||||
```
|
||||
```
|
||||
0
|
||||
|
|
@ -1603,7 +1605,7 @@ due to some of the following factors:
|
|||
造成此情况一些可能因素如下：
|
||||
|
||||
<!--
|
||||
* Insufficient quota
|
||||
* Insufficient quota
|
||||
* Readiness probe failures
|
||||
* Image pull errors
|
||||
* Insufficient permissions
|
||||
|
|
@ -1676,7 +1678,7 @@ See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/d
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
Kubernetes takes no action on a stalled Deployment other than to report a status condition with
|
||||
Kubernetes takes no action on a stalled Deployment other than to report a status condition with
|
||||
`reason: ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
|
||||
example, rollback the Deployment to its previous version.
|
||||
-->
|
||||
|
|
@ -1687,8 +1689,8 @@ Deployment 不执行任何操作。更高级别的编排器可以利用这一设
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline.
|
||||
You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering
|
||||
If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline.
|
||||
You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering
|
||||
the condition for exceeding the deadline.
|
||||
-->
|
||||
如果你暂停了某个 Deployment 上线，Kubernetes 不再根据指定的截止时间检查 Deployment 上线的进展。
|
||||
|
|
@ -1831,7 +1833,7 @@ and the exit status from `kubectl rollout` is 1 (indicating an error):
|
|||
`kubectl rollout` 命令的退出状态为 1（表明发生了错误）：
|
||||
|
||||
```shell
|
||||
$ echo $?
|
||||
echo $?
|
||||
```
|
||||
```
|
||||
1
|
||||
|
|
@ -1899,9 +1901,9 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
|
|||
|
||||
<!--
|
||||
When the control plane creates new Pods for a Deployment, the `.metadata.name` of the
|
||||
Deployment is part of the basis for naming those Pods. The name of a Deployment must be a valid
|
||||
Deployment is part of the basis for naming those Pods. The name of a Deployment must be a valid
|
||||
[DNS subdomain](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
|
||||
value, but this can produce unexpected results for the Pod hostnames. For best compatibility,
|
||||
value, but this can produce unexpected results for the Pod hostnames. For best compatibility,
|
||||
the name should follow the more restrictive rules for a
|
||||
[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names).
|
||||
|
||||
|
|
@ -2056,11 +2058,11 @@ All existing Pods are killed before new ones are created when `.spec.strategy.ty
|
|||
|
||||
{{< note >}}
|
||||
<!--
|
||||
This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods
|
||||
of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new
|
||||
revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the
|
||||
replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an
|
||||
"at most" guarantee for your Pods, you should consider using a
|
||||
This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods
|
||||
of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new
|
||||
revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the
|
||||
replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an
|
||||
"at most" guarantee for your Pods, you should consider using a
|
||||
[StatefulSet](/docs/concepts/workloads/controllers/statefulset/).
|
||||
-->
|
||||
这只会确保为了升级而创建新 Pod 之前其他 Pod 都已终止。如果你升级一个 Deployment，
|
||||
|
|
@ -2114,7 +2116,7 @@ at all times during the update is at least 70% of the desired Pods.
|
|||
<!--
|
||||
##### Max Surge
|
||||
|
||||
`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
|
||||
`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods
|
||||
that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a
|
||||
percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number
|
||||
is calculated from the percentage by rounding up. The default value is 25%.
|
||||
|
|
@ -2137,11 +2139,11 @@ total number of Pods running at any time during the update is at most 130% of de
|
|||
同时确保更新期间的任何时候运行中的 Pod 总数最多为所需 Pod 总数的 130%。
|
||||
|
||||
<!--
|
||||
### Progress Deadline Seconds
|
||||
### Progress Deadline Seconds
|
||||
|
||||
`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
|
||||
`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want
|
||||
to wait for your Deployment to progress before the system reports back that the Deployment has
|
||||
[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: False`.
|
||||
[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: "False"`.
|
||||
and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep
|
||||
retrying the Deployment. This defaults to 600. In the future, once automatic rollback will be implemented, the Deployment
|
||||
controller will roll back a Deployment as soon as it observes such a condition.
|
||||
|
|
@ -2162,7 +2164,7 @@ If specified, this field needs to be greater than `.spec.minReadySeconds`.
|
|||
<!--
|
||||
### Min Ready Seconds
|
||||
|
||||
`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
|
||||
`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly
|
||||
created Pod should be ready without any of its containers crashing, for it to be considered available.
|
||||
This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
|
||||
a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
|
||||
|
|
|
|||
|
|
@ -574,6 +574,9 @@ prioritize scaling down pods based on the following general algorithm:
|
|||
（当 `LogarithmicScaleDown` 这一[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
被启用时，创建时间是按整数幂级来分组的）。
|
||||
|
||||
<!--
|
||||
If all of the above match, then selection is random.
|
||||
-->
|
||||
如果以上比较结果都相同，则随机选择。
|
||||
|
||||
<!--
|
||||
|
|
@ -688,7 +691,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
|
|||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is an object which can own ReplicaSets and update
|
||||
them and their Pods via declarative, server-side rolling updates.
|
||||
While ReplicaSets can be used independently, today they're mainly used by Deployments as a mechanism to orchestrate Pod
|
||||
While ReplicaSets can be used independently, today they're mainly used by Deployments as a mechanism to orchestrate Pod
|
||||
creation, deletion and updates. When you use Deployments you don't have to worry about managing the ReplicaSets that
|
||||
they create. Deployments own and manage their ReplicaSets.
|
||||
As such, it is recommended to use Deployments when you want ReplicaSets.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,9 @@ weight: 20
|
|||
-->
|
||||
|
||||
{{% alert title="Note" %}}
|
||||
<!-- This tutorial applies only for new clusters. -->
|
||||
<!--
|
||||
This tutorial applies only for new clusters.
|
||||
-->
|
||||
本教程仅适用于新集群。
|
||||
{{% /alert %}}
|
||||
|
||||
|
|
@ -24,7 +26,7 @@ when pods are created. In this tutorial, you will enforce the `baseline` Pod Sec
|
|||
one namespace at a time.
|
||||
|
||||
You can also apply Pod Security Standards to multiple namespaces at once at the cluster
|
||||
level. For instructions, refer to
|
||||
level. For instructions, refer to
|
||||
[Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/).
|
||||
-->
|
||||
Pod 安全准入（PSA）在 v1.23 及更高版本默认启用，
|
||||
|
|
@ -59,15 +61,17 @@ Install the following on your workstation:
|
|||
2. 按照如下方式创建一个 `KinD` 集群：
|
||||
|
||||
```shell
|
||||
kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
|
||||
kind create cluster --name psa-ns-level
|
||||
```
|
||||
|
||||
<!-- The output is similar to this: -->
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Creating cluster "psa-ns-level" ...
|
||||
✓ Ensuring node image (kindest/node:v1.23.0) 🖼
|
||||
✓ Ensuring node image (kindest/node:v{{< skew currentVersion >}}.0) 🖼
|
||||
✓ Preparing nodes 📦
|
||||
✓ Writing configuration 📜
|
||||
✓ Starting control-plane 🕹️
|
||||
|
|
@ -75,26 +79,30 @@ Install the following on your workstation:
|
|||
✓ Installing StorageClass 💾
|
||||
Set kubectl context to "kind-psa-ns-level"
|
||||
You can now use your cluster with:
|
||||
|
||||
|
||||
kubectl cluster-info --context kind-psa-ns-level
|
||||
|
||||
|
||||
Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/
|
||||
```
|
||||
|
||||
<!-- 1. Set the kubectl context to the new cluster: -->
|
||||
<!--
|
||||
1. Set the kubectl context to the new cluster:
|
||||
-->
|
||||
1. 将 kubectl 上下文设置为新集群：
|
||||
|
||||
```shell
|
||||
kubectl cluster-info --context kind-psa-ns-level
|
||||
```
|
||||
|
||||
<!-- The output is similar to this: -->
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
Kubernetes control plane is running at https://127.0.0.1:50996
|
||||
CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
|
||||
|
||||
|
||||
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
|
||||
```
|
||||
|
||||
|
|
@ -111,7 +119,9 @@ Create a new namespace called `example`:
|
|||
kubectl create ns example
|
||||
```
|
||||
|
||||
<!-- The output is similar to this: -->
|
||||
<!--
|
||||
The output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
|
|
@ -119,34 +129,35 @@ namespace/example created
|
|||
```
|
||||
|
||||
<!--
|
||||
## Apply Pod Security Standards
|
||||
## Enable Pod Security Standards checking for that namespace
|
||||
|
||||
1. Enable Pod Security Standards on this namespace using labels supported by
|
||||
built-in Pod Security Admission. In this step we will warn on baseline pod
|
||||
security standard as per the latest version (default value)
|
||||
built-in Pod Security Admission. In this step you will configure a check to
|
||||
warn on Pods that don't meet the latest version of the _baseline_ pod
|
||||
security standard.
|
||||
-->
|
||||
## 应用 Pod 安全标准 {#apply-pod-security-standards}
|
||||
## 为该命名空间启用 Pod 安全标准检查 {#enable-pod-security-standards-checking-for-that-namespace}
|
||||
|
||||
1. 使用内置 Pod 安全准入所支持的标签在此名字空间上启用 Pod 安全标准。
|
||||
在这一步中，我们将根据最新版本（默认值）对基线 Pod 安全标准发出警告。
|
||||
|
||||
```shell
|
||||
kubectl label --overwrite ns example \
|
||||
pod-security.kubernetes.io/warn=baseline \
|
||||
pod-security.kubernetes.io/warn-version=latest
|
||||
pod-security.kubernetes.io/warn=baseline \
|
||||
pod-security.kubernetes.io/warn-version=latest
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Multiple pod security standards can be enabled on any namespace, using labels.
|
||||
Following command will `enforce` the `baseline` Pod Security Standard, but
|
||||
2. You can configure multiple pod security standard checks on any namespace, using labels.
|
||||
The following command will `enforce` the `baseline` Pod Security Standard, but
|
||||
`warn` and `audit` for `restricted` Pod Security Standards as per the latest
|
||||
version (default value)
|
||||
-->
|
||||
2. 可以使用标签在任何名字空间上启用多个 Pod 安全标准。
|
||||
1. 你可以使用标签在任何名字空间上配置多个 Pod 安全标准检查。
|
||||
以下命令将强制（`enforce`） 执行基线（`baseline`）Pod 安全标准，
|
||||
但根据最新版本（默认值）对受限（`restricted`）Pod 安全标准执行警告（`warn`）和审核（`audit`）。
|
||||
|
||||
```
|
||||
```shell
|
||||
kubectl label --overwrite ns example \
|
||||
pod-security.kubernetes.io/enforce=baseline \
|
||||
pod-security.kubernetes.io/enforce-version=latest \
|
||||
|
|
@ -157,56 +168,39 @@ namespace/example created
|
|||
```
|
||||
|
||||
<!--
|
||||
## Verify the Pod Security Standards
|
||||
## Verify the Pod Security Standard enforcement
|
||||
|
||||
1. Create a minimal pod in `example` namespace:
|
||||
1. Create a baseline Pod in the `example` namespace:
|
||||
-->
|
||||
## 验证 Pod 安全标准 {#verify-the-pod-security-standards}
|
||||
|
||||
1. 在 `example` 名字空间中创建一个最小的 Pod：
|
||||
1. 在 `example` 名字空间中创建一个基线 Pod：
|
||||
|
||||
```shell
|
||||
cat <<EOF > /tmp/pss/nginx-pod.yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
EOF
|
||||
kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml
|
||||
```
|
||||
|
||||
<!--
|
||||
2. Apply the pod spec to the cluster in `example` namespace:
|
||||
-->
|
||||
1. 将 Pod 规约应用到集群中的 `example` 名字空间中：
|
||||
|
||||
```shell
|
||||
kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
|
||||
```
|
||||
|
||||
<!-- The output is similar to this: -->
|
||||
输出类似于：
|
||||
<!--
|
||||
The Pod does start OK; the output includes a warning. For example:
|
||||
-->
|
||||
Pod 确实启动正常；输出包括一条警告信息。例如：
|
||||
|
||||
```
|
||||
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext seccompProfile.type to "RuntimeDefault" or "Localhost")
|
||||
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
|
||||
pod/nginx created
|
||||
```
|
||||
|
||||
<!--
|
||||
1. Apply the pod spec to the cluster in `default` namespace:
|
||||
1. Create a baseline Pod in the `default` namespace:
|
||||
-->
|
||||
3. 将 Pod 规约应用到集群中的 `default` 名字空间中：
|
||||
1. 在 `default` 名字空间中创建一个基线 Pod：
|
||||
|
||||
```shell
|
||||
kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
|
||||
kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml
|
||||
```
|
||||
|
||||
<!-- Output is similar to this: -->
|
||||
<!--
|
||||
Output is similar to this:
|
||||
-->
|
||||
输出类似于：
|
||||
|
||||
```
|
||||
|
|
@ -214,10 +208,11 @@ namespace/example created
|
|||
```
|
||||
|
||||
<!--
|
||||
The Pod Security Standards were applied only to the `example`
|
||||
namespace. You could create the same Pod in the `default` namespace
|
||||
with no warnings.
|
||||
The Pod Security Standards enforcement and warning settings were applied only
|
||||
to the `example` namespace. You could create the same Pod in the `default`
|
||||
namespace with no warnings.
|
||||
-->
|
||||
Pod 安全标准实施和警告设置仅被应用到 `example` 名字空间。
|
||||
以上 Pod 安全标准仅被应用到 `example` 名字空间。
|
||||
你可以在没有警告的情况下在 `default` 名字空间中创建相同的 Pod。
|
||||
|
||||
|
|
@ -246,6 +241,7 @@ kind delete cluster --name psa-ns-level
|
|||
3. Apply `baseline` Pod Security Standard in `enforce` mode while applying
|
||||
`restricted` Pod Security Standard also in `warn` and `audit` mode.
|
||||
4. Create a new pod with the following pod security standards applied
|
||||
|
||||
- [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
|
||||
- [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
|
||||
- [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/)
|
||||
|
|
|
|||
Loading…
Reference in New Issue