diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 568a258a1c..29a8e1ecf8 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -639,3 +639,10 @@ body.td-documentation { } } +.td-content { + table code { + background-color: inherit !important; + color: inherit !important; + font-size: inherit !important; + } +} diff --git a/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md b/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md new file mode 100644 index 0000000000..c65069460a --- /dev/null +++ b/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md @@ -0,0 +1,74 @@ +--- +layout: blog +title: "PodSecurityPolicy Deprecation: Past, Present, and Future" +date: 2021-04-06 +slug: podsecuritypolicy-deprecation-past-present-and-future +--- + +**Author:** Tabitha Sable (Kubernetes SIG Security) + +PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably. + +What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes. + +## What does deprecation mean in Kubernetes? + +Whenever a Kubernetes feature is set to go away, our [deprecation policy](/docs/reference/using-api/deprecation-policy/) is our guide. First the feature is marked as deprecated, then after enough time has passed, it can finally be removed. + +Kubernetes 1.21 starts the deprecation process for PodSecurityPolicy. As with all feature deprecations, PodSecurityPolicy will continue to be fully functional for several more releases. The current plan is to remove PSP from Kubernetes in the 1.25 release. + +Until then, PSP is still PSP. There will be at least a year during which the newest Kubernetes releases will still support PSP, and nearly two years until PSP will pass fully out of all supported Kubernetes versions. + +## What is PodSecurityPolicy? + +[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) is a built-in [admission controller](/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/) that allows a cluster administrator to control security-sensitive aspects of the Pod specification. + +First, one or more PodSecurityPolicy resources are created in a cluster to define the requirements Pods must meet. Then, RBAC rules are created to control which PodSecurityPolicy applies to a given pod. If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual. In some cases, PSP can also modify Pod fields, effectively creating new defaults for those fields. If a Pod does not meet the PSP requirements, it is rejected, and cannot run. + +One more important thing to know about PodSecurityPolicy: it’s not the same as [PodSecurityContext](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context). + +A part of the Pod specification, PodSecurityContext (and its per-container counterpart `SecurityContext`) is the collection of fields that specify many of the security-relevant settings for a Pod. The security context dictates to the kubelet and container runtime how the Pod should actually be run. In contrast, the PodSecurityPolicy only constrains (or defaults) the values that may be set on the security context. + +The deprecation of PSP does not affect PodSecurityContext in any way. + +## Why did we need PodSecurityPolicy? + +In Kubernetes, we define resources such as Deployments, StatefulSets, and Services that represent the building blocks of software applications. The various controllers inside a Kubernetes cluster react to these resources, creating further Kubernetes resources or configuring some software or hardware to accomplish our goals. + +In most Kubernetes clusters, RBAC (Role-Based Access Control) [rules](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) control access to these resources. `list`, `get`, `create`, `edit`, and `delete` are the sorts of API operations that RBAC cares about, but _RBAC does not consider what settings are being put into the resources it controls_. For example, a Pod can be almost anything from a simple webserver to a privileged command prompt offering full access to the underlying server node and all the data. It’s all the same to RBAC: a Pod is a Pod is a Pod. + +To control what sorts of settings are allowed in the resources defined in your cluster, you need Admission Control in addition to RBAC. Since Kubernetes 1.3, PodSecurityPolicy has been the built-in way to do that for security-related Pod fields. Using PodSecurityPolicy, you can prevent “create Pod” from automatically meaning “root on every cluster node,” without needing to deploy additional external admission controllers. + +## Why is PodSecurityPolicy going away? + +In the years since PodSecurityPolicy was first introduced, we have realized that PSP has some serious usability problems that can’t be addressed without making breaking changes. + +The way PSPs are applied to Pods has proven confusing to nearly everyone that has attempted to use them. It is easy to accidentally grant broader permissions than intended, and difficult to inspect which PSP(s) apply in a given situation. The “changing Pod defaults” feature can be handy, but is only supported for certain Pod settings and it’s not obvious when they will or will not apply to your Pod. Without a “dry run” or audit mode, it’s impractical to retrofit PSP to existing clusters safely, and it’s impossible for PSP to ever be enabled by default. + +For more information about these and other PSP difficulties, check out SIG Auth’s KubeCon NA 2019 Maintainer Track session video: {{< youtube "SFtHRmPuhEw?start=953" youtube-quote-sm >}} + +Today, you’re not limited only to deploying PSP or writing your own custom admission controller. Several external admission controllers are available that incorporate lessons learned from PSP to provide a better user experience. [K-Rail](https://github.com/cruise-automation/k-rail), [Kyverno](https://github.com/kyverno/kyverno/), and [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper/) are all well-known, and each has its fans. + +Although there are other good options available now, we believe there is still value in having a built-in admission controller available as a choice for users. With this in mind, we turn toward building what’s next, inspired by the lessons learned from PSP. + +## What’s next? + +Kubernetes SIG Security, SIG Auth, and a diverse collection of other community members have been working together for months to ensure that what’s coming next is going to be awesome. We have developed a Kubernetes Enhancement Proposal ([KEP 2579](https://github.com/kubernetes/enhancements/issues/2579)) and a prototype for a new feature, currently being called by the temporary name "PSP Replacement Policy." We are targeting an Alpha release in Kubernetes 1.22. + +PSP Replacement Policy starts with the realization that since there is a robust ecosystem of external admission controllers already available, PSP’s replacement doesn’t need to be all things to all people. Simplicity of deployment and adoption is the key advantage a built-in admission controller has compared to an external webhook, so we have focused on how to best utilize that advantage. + +PSP Replacement Policy is designed to be as simple as practically possible while providing enough flexibility to really be useful in production at scale. It has soft rollout features to enable retrofitting it to existing clusters, and is configurable enough that it can eventually be active by default. It can be deactivated partially or entirely, to coexist with external admission controllers for advanced use cases. + +## What does this mean for you? + +What this all means for you depends on your current PSP situation. If you’re already using PSP, there’s plenty of time to plan your next move. Please review the PSP Replacement Policy KEP and think about how well it will suit your use case. + +If you’re making extensive use of the flexibility of PSP with numerous PSPs and complex binding rules, you will likely find the simplicity of PSP Replacement Policy too limiting. Use the next year to evaluate the other admission controller choices in the ecosystem. There are resources available to ease this transition, such as the [Gatekeeper Policy Library](https://github.com/open-policy-agent/gatekeeper-library). + +If your use of PSP is relatively simple, with a few policies and straightforward binding to service accounts in each namespace, you will likely find PSP Replacement Policy to be a good match for your needs. Evaluate your PSPs compared to the Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) to get a feel for where you’ll be able to use the Restricted, Baseline, and Privileged policies. Please follow along with or contribute to the KEP and subsequent development, and try out the Alpha release of PSP Replacement Policy when it becomes available. + +If you’re just beginning your PSP journey, you will save time and effort by keeping it simple. You can approximate the functionality of PSP Replacement Policy today by using the Pod Security Standards’ PSPs. If you set the cluster default by binding a Baseline or Restricted policy to the `system:serviceaccounts` group, and then make a more-permissive policy available as needed in certain Namespaces [using ServiceAccount bindings](/docs/concepts/policy/pod-security-policy/#run-another-pod), you will avoid many of the PSP pitfalls and have an easy migration to PSP Replacement Policy. If your needs are much more complex than this, your effort is probably better spent adopting one of the more fully-featured external admission controllers mentioned above. + +We’re dedicated to making Kubernetes the best container orchestration tool we can, and sometimes that means we need to remove longstanding features to make space for better things to come. When that happens, the Kubernetes deprecation policy ensures you have plenty of time to plan your next move. In the case of PodSecurityPolicy, several options are available to suit a range of needs and use cases. Start planning ahead now for PSP’s eventual removal, and please consider contributing to its replacement! Happy securing! + +**Acknowledgment:** It takes a wonderful group to make wonderful software. Thanks are due to everyone who has contributed to the PSP replacement effort, especially (in alphabetical order) Tim Allclair, Ian Coldwater, and Jordan Liggitt. It’s been a joy to work with y’all on this. diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 6320a1609c..726207c9fe 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -582,10 +582,9 @@ Each feature gate is designed for enabling/disabling a specific feature: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - `CustomResourceWebhookConversion`: Enable webhook-based conversion on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - troubleshoot a running Pod. - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints). -- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/) +- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) based resource provisioning on nodes. - `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/system-metrics/#disable-accelerator-metrics). @@ -786,8 +785,6 @@ Each feature gate is designed for enabling/disabling a specific feature: topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details. -- `SizeMemoryBackedVolumes`: Enables kubelet support to size memory backed volumes. - See [volumes](/docs/concepts/storage/volumes) for more details. - `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain Name(FQDN) as the hostname of a pod. See [Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field). diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index b2b41f9128..58cd1ca133 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -75,7 +75,7 @@ kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: extraArgs: - address: 0.0.0.0 + bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml ``` diff --git a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md index 963df78524..da7c286f89 100644 --- a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md @@ -49,7 +49,6 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー 出力はこのようになります: - user@computer:~/website$ kubectl describe deployment nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 diff --git a/content/ja/docs/tutorials/stateless-application/guestbook.md b/content/ja/docs/tutorials/stateless-application/guestbook.md index e08abdb62c..aff86a2289 100644 --- a/content/ja/docs/tutorials/stateless-application/guestbook.md +++ b/content/ja/docs/tutorials/stateless-application/guestbook.md @@ -185,7 +185,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい 1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。 ```shell - kubectl get pods -l app=guestbook -l tier=frontend + kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend ``` 結果は次のようになるはずです。 diff --git a/content/pt/docs/concepts/architecture/master-node-communication.md b/content/pt/docs/concepts/architecture/control-plane-node-communication.md similarity index 66% rename from content/pt/docs/concepts/architecture/master-node-communication.md rename to content/pt/docs/concepts/architecture/control-plane-node-communication.md index 8cf2ad86c6..de69ad8ea8 100644 --- a/content/pt/docs/concepts/architecture/master-node-communication.md +++ b/content/pt/docs/concepts/architecture/control-plane-node-communication.md @@ -1,15 +1,12 @@ --- -reviewers: -- dchen1107 -- liggitt -title: Comunicação entre Node e Master +title: Comunicação entre Nó e Control Plane content_type: concept weight: 20 --- -Este documento cataloga os caminhos de comunicação entre o Master (o +Este documento cataloga os caminhos de comunicação entre o control plane (o apiserver) e o cluster Kubernetes. A intenção é permitir que os usuários personalizem sua instalação para proteger a configuração de rede então o cluster pode ser executado em uma rede não confiável (ou em IPs totalmente públicos em um @@ -20,10 +17,10 @@ provedor de nuvem). -## Cluster para o Master +## Nó para o Control Plane -Todos os caminhos de comunicação do cluster para o Master terminam no -apiserver (nenhum dos outros componentes do Master são projetados para expor +Todos os caminhos de comunicação do cluster para o control plane terminam no +apiserver (nenhum dos outros componentes do control plane são projetados para expor Serviços remotos). Em uma implantação típica, o apiserver é configurado para escutar conexões remotas em uma porta HTTPS segura (443) com uma ou mais clientes [autenticação](/docs/reference/access-authn-authz/authentication/) habilitado. Uma ou mais formas de [autorização](/docs/reference/access-authn-authz/authorization/) @@ -41,21 +38,21 @@ para provisionamento automatizado de certificados de cliente kubelet. Os pods que desejam se conectar ao apiserver podem fazê-lo com segurança, aproveitando conta de serviço para que o Kubernetes injetará automaticamente o certificado raiz público certificado e um token de portador válido no pod quando ele é instanciado. -O serviço `kubernetes` (em todos os namespaces) é configurado com um IP virtual +O serviço `kubernetes` (no namespace `default`) é configurado com um IP virtual endereço que é redirecionado (via kube-proxy) para o endpoint com HTTPS no apiserver. -Os componentes principais também se comunicam com o apiserver do cluster através da porta segura. +Os componentes do control plane também se comunicam com o apiserver do cluster através da porta segura. Como resultado, o modo de operação padrão para conexões do cluster -(nodes e pods em execução nos Nodes) para o Master é protegido por padrão -e pode passar por redes não confiáveis ​​e / ou públicas. +(nodes e pods em execução nos Nodes) para o control plane é protegido por padrão +e pode passar por redes não confiáveis ​​e/ou públicas. -## Master para o Cluster +## Control Plane para o nó -Existem dois caminhos de comunicação primários do mestre (apiserver) para o -cluster. O primeiro é do apiserver para o processo do kubelet que é executado em -cada Node no cluster. O segundo é do apiserver para qualquer Node, pod, +Existem dois caminhos de comunicação primários do control plane (apiserver) para os nós. +O primeiro é do apiserver para o processo do kubelet que é executado em +cada nó no cluster. O segundo é do apiserver para qualquer nó, pod, ou serviço através da funcionalidade de proxy do apiserver. ### apiserver para o kubelet @@ -63,8 +60,8 @@ ou serviço através da funcionalidade de proxy do apiserver. As conexões do apiserver ao kubelet são usadas para: * Buscar logs para pods. -  * Anexar (através de kubectl) pods em execução. -  * Fornecer a funcionalidade de encaminhamento de porta do kubelet. + * Anexar (através de kubectl) pods em execução. + * Fornecer a funcionalidade de encaminhamento de porta do kubelet. Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão, o apiserver não verifica o certificado de serviço do kubelet, @@ -94,12 +91,18 @@ Estas conexões **não são atualmente seguras** para serem usados por redes nã ### SSH Túnel -O Kubernetes suporta túneis SSH para proteger o Servidor Master -> caminhos de comunicação no cluster. Nesta configuração, o apiserver inicia um túnel SSH para cada nó +O Kubernetes suporta túneis SSH para proteger os caminhos de comunicação do control plane para os nós. Nesta configuração, o apiserver inicia um túnel SSH para cada nó no cluster (conectando ao servidor ssh escutando na porta 22) e passa todo o tráfego destinado a um kubelet, nó, pod ou serviço através do túnel. Este túnel garante que o tráfego não seja exposto fora da rede aos quais os nós estão sendo executados. -Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que saiba o que está fazendo. Um substituto para este canal de comunicação está sendo projetado. +Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que saiba o que está fazendo. O serviço Konnectivity é um substituto para este canal de comunicação. +### Konnectivity service +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +Como uma substituição aos túneis SSH, o serviço Konnectivity fornece proxy de nível TCP para a comunicação do control plane para o cluster. O serviço Konnectivity consiste em duas partes: o servidor Konnectivity na rede control plane e os agentes Konnectivity na rede dos nós. Os agentes Konnectivity iniciam conexões com o servidor Konnectivity e mantêm as conexões de rede. Depois de habilitar o serviço Konnectivity, todo o tráfego do control plane para os nós passa por essas conexões. + +Veja a [tarefa do Konnectivity](docs/tasks/extend-kubernetes/setup-konnectivity/) para configurar o serviço Konnectivity no seu cluster. diff --git a/content/vi/docs/reference/glossary/api-group.md b/content/vi/docs/reference/glossary/api-group.md index ce2cfd4532..66c215e0a6 100644 --- a/content/vi/docs/reference/glossary/api-group.md +++ b/content/vi/docs/reference/glossary/api-group.md @@ -2,7 +2,7 @@ title: API Group id: api-group date: 2019-12-16 -full_link: /docs/concepts/overview/kubernetes-api/#api-groups +full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning short_description: > Một tập những đường dẫn tương đối đến Kubernetes API. @@ -18,4 +18,4 @@ Một tập những đường dẫn tương đối đến Kubernetes API. Bạn có thể cho phép hay vô hiệu từng API group bằng cách thay đổi cấu hình trên API server của mình. Đồng thời bạn cũng có thể vô hiệu hay kích hoạt các đường dẫn cho những tài nguyên cụ thể. API group đơn giản hóa việc mở rộng Kubernetes API. Nó được chỉ định dưới dạng REST và trong trường `apiVersion` của một đối tượng đã được chuyển hóa. -- Đọc thêm về [API Group](/docs/concepts/overview/kubernetes-api/#api-groups). \ No newline at end of file +- Đọc thêm về [API Group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning). \ No newline at end of file diff --git a/content/vi/docs/reference/kubectl/cheatsheet.md b/content/vi/docs/reference/kubectl/cheatsheet.md index 38e51750e6..079b36a42b 100644 --- a/content/vi/docs/reference/kubectl/cheatsheet.md +++ b/content/vi/docs/reference/kubectl/cheatsheet.md @@ -1,381 +1,381 @@ ---- -title: kubectl Cheat Sheet -reviewers: -- ngtuna -content_type: concept -card: - name: reference - weight: 30 ---- - - - -Xem thêm: [Kubectl Overview](/docs/reference/kubectl/overview/) và [JsonPath Guide](/docs/reference/kubectl/jsonpath). - -Trang này là trang tổng quan của lệnh `kubectl`. - - - - - -# kubectl - Cheat Sheet - -## Kubectl Autocomplete - -### BASH - -```bash -source <(kubectl completion bash) # thiết lập autocomplete trong bash vào shell hiện tại, gói bash-completion nên được cài đặt trước tiên -echo "source <(kubectl completion bash)" >> ~/.bashrc # thêm vĩnh viễn autocomplete vào trong bash shell -``` - -Bạn có thể dùng một alias cho `kubectl` cũng hoạt động với completion: - -```bash -alias k=kubectl -complete -F __start_kubectl k -``` - -### ZSH - -```bash -source <(kubectl completion zsh) # thiết lập autocomplete trong zsh vào shell hiện tại -echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # thêm vĩnh viễn autocomplete vào trong zsh shell -``` - -## Ngữ cảnh và cấu hình kubectl - -Thiết lập cụm Kubernetes nào mà `kubectl` sẽ giao tiếp với và sửa đổi thông tin cấu hình. -Xem tài liệu [Xác thực giữa các cụm với kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) -để biết thông tin chi tiết của tệp cấu hình. - -```bash -kubectl config view # Hiển thị các thiết lập kubeconfig đã được merged - -# sử dụng nhiều tệp kubeconfig cùng một lúc và xem cấu hình hợp nhất -KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 - -kubectl config view - -# lấy mật khẩu cho người dùng e2e -kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' - -kubectl config view -o jsonpath='{.users[].name}' # hiển thị người dùng đầu tiên -kubectl config view -o jsonpath='{.users[*].name}' # lấy danh sách người dùng -kubectl config get-contexts # hiển thị danh sách các ngữ cảnh -kubectl config current-context # hiển thị ngữ cảnh hiện tại -kubectl config use-context my-cluster-name # thiết lập ngữ cảnh mặc định cho my-cluster-name - -# thêm một cụm mới vào kubeconf hỗ trợ xác thực cơ bản -kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword - -# lưu vĩnh viễn namespace cho tất cả các lệnh kubectl tiếp theo trong ngữ cảnh đó -kubectl config set-context --current --namespace=ggckad-s2 - -# thiết lập ngữ cảnh sử dụng tên người dùng và namespace cụ thể -kubectl config set-context gce --user=cluster-admin --namespace=foo \ - && kubectl config use-context gce - -kubectl config unset users.foo # xóa người dùng foo -``` - -## Apply -`apply` quản lý các ứng dụng thông qua các tệp định nghĩa tài nguyên Kubernetes. Nó tạo và cập nhật các tài nguyên trong một cụm thông qua việc chạy `kubectl apply`. Đây là cách được đề xuất để quản lý các ứng dụng Kubernetes trong thực tế. Xem thêm [Kubectl Book](https://kubectl.docs.kubernetes.io). - -## Tạo một đối tượng - -Kubernetes manifests có thể được định nghĩa trong tệp json hoặc yaml. Phần mở rộng `.yaml`, -`.yml`, và `.json` có thể được dùng. - -```bash -kubectl apply -f ./my-manifest.yaml # tạo tài nguyên -kubectl apply -f ./my1.yaml -f ./my2.yaml # tạo từ nhiều tệp -kubectl apply -f ./dir # tạo tài nguyên từ tất cả các tệp manifest trong thư mục dir -kubectl apply -f https://git.io/vPieo # tạo tài nguyên từ url -kubectl create deployment nginx --image=nginx # tạo một deployment nginx -kubectl explain pods,svc # lấy thông tin pod và service manifest - -# Tạo nhiều đối tượng YAML từ stdin -cat < pod.yaml - -kubectl attach my-pod -i # Đính kèm với container đang chạy -kubectl port-forward my-pod 5000:6000 # Lắng nghe trên cổng 5000 của máy local và chuyển tiếp sang cổng 6000 trên pod my-pod -kubectl exec my-pod -- ls / # Chạy lệnh trong một pod (trường hợp 1 container) -kubectl exec my-pod -c my-container -- ls / # Chạy lệnh trong pod (trường hợp nhiều container) -kubectl top pod POD_NAME --containers # Hiển thị số liệu của pod và container chạy trong nó -``` - -## Tương tác với các nodes và cụm - -```bash -kubectl cordon my-node # Đánh dấu my-node là không thể lập lịch -kubectl drain my-node # Gỡ my-node ra khỏi cụm để chuẩn bị cho việc bảo trì -kubectl uncordon my-node # Đánh dấu my-node có thể lập lịch trở lại -kubectl top node my-node # Hiển thị số liệu của node -kubectl cluster-info # Hiển thị địa chỉ master và các services -kubectl cluster-info dump # Kết xuất trạng thái hiện tại của cụm ra ngoài stdout -kubectl cluster-info dump --output-directory=/path/to/cluster-state # Kết xuất trạng thái hiện tại của cụm vào /path/to/cluster-state - -kubectl taint nodes foo dedicated=special-user:NoSchedule -``` - -### Các loại tài nguyên - -Liệt kê tất cả các loại tài nguyên được hỗ trợ cùng với tên viết tắt của chúng, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), cho dù chúng là [namespaced](/docs/concepts/overview/working-with-objects/namespaces), và [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): - -```bash -kubectl api-resources -``` - -Các hoạt động khác để khám phá các tài nguyên API: - -```bash -kubectl api-resources --namespaced=true # Tất cả các tài nguyên được đặt tên -kubectl api-resources --namespaced=false # Tất cả các tài nguyên không được đặt tên -kubectl api-resources -o name # Tất cả các tài nguyên với đầu ra đơn giản (chỉ gồm tên tài nguyên) -kubectl api-resources -o wide # Tất cả các tài nguyên với đầu ra mở rộng -kubectl api-resources --verbs=list,get # Tất cả các tài nguyên hỗ trợ yêu cầu "list" và "get" -kubectl api-resources --api-group=extensions # Tất cả tài nguyên trong nhóm API "tiện ích mở rộng" -``` - -### Định dạng đầu ra - -Để xuất thông tin chi tiết ra cửa sổ terminal của bạn theo một định dạng cụ thể, bạn có thể thêm các cờ `-o` hoặc `--output` vào lệnh `kubectl` được hỗ trợ. - -Định dạng đầu ra | Mô tả ---------------| ----------- -`-o=custom-columns=` | In một bảng bằng danh sách, các cột tùy chỉnh được phân tách bằng dấu phẩy -`-o=custom-columns-file=` | In một bảng bằng cách sử dụng mẫu cột tùy chỉnh trong tệp `` -`-o=json` | Xuất ra một đối tượng API theo định dạng JSON -`-o=jsonpath=