Merge remote-tracking branch 'upstream/master' into dev-1.20
This commit is contained in:
Somtochi Onyekwere
@@ -8,7 +8,7 @@ sitemap:
|
||||
|
||||
{{< blocks/section id="oceanNodes" >}}
|
||||
{{% blocks/feature image="flower" %}}
|
||||
[Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) is an open-source system for automating deployment, scaling, and management of containerized applications.
|
||||
[Kubernetes]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}), also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
|
||||
|
||||
It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community.
|
||||
{{% /blocks/feature %}}
|
||||
@@ -28,7 +28,7 @@ Whether testing locally or running a global enterprise, Kubernetes flexibility g
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature image="suitcase" %}}
|
||||
#### Run Anywhere
|
||||
#### Run K8s Anywhere
|
||||
|
||||
Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.
|
||||
|
||||
|
||||
+1
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 66 KiB |
@@ -0,0 +1,57 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "Cloud native security for your clusters"
|
||||
date: 2020-11-18
|
||||
slug: cloud-native-security-for-your-clusters
|
||||
---
|
||||
|
||||
**Author**: [Pushkar Joglekar](https://twitter.com/pudijoglekar)
|
||||
|
||||
Over the last few years a small, security focused community has been working diligently to deepen our understanding of security, given the evolving cloud native infrastructure and corresponding iterative deployment practices. To enable sharing of this knowledge with the rest of the community, members of [CNCF SIG Security](https://github.com/cncf/sig-security) (a group which reports into [CNCF TOC](https://github.com/cncf/toc#sigs) and who are friends with [Kubernetes SIG Security](https://github.com/kubernetes/community/tree/master/sig-security)) led by Emily Fox, collaborated on a whitepaper outlining holistic cloud native security concerns and best practices. After over 1200 comments, changes, and discussions from 35 members across the world, we are proud to share [cloud native security whitepaper v1.0](https://www.cncf.io/blog/2020/11/18/announcing-the-cloud-native-security-white-paper) that serves as essential reading for security leadership in enterprises, financial and healthcare industries, academia, government, and non-profit organizations.
|
||||
|
||||
The paper attempts to _not_ focus on any specific [cloud native project](https://www.cncf.io/projects/). Instead, the intent is to model and inject security into four logical phases of cloud native application lifecycle: _Develop, Distribute, Deploy, and Runtime_.
|
||||
|
||||
<img alt="Cloud native application lifecycle phases"
|
||||
src="cloud-native-app-lifecycle-phases.svg"
|
||||
style="width:60em;max-width:100%;">
|
||||
|
||||
|
||||
## Kubernetes native security controls
|
||||
When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are:
|
||||
* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/): Implement a single source of truth for “least privilege” workloads across the entire cluster
|
||||
* [Resource requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits): Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU
|
||||
* [Audit log analysis](/docs/tasks/debug-application-cluster/audit/): Enable Kubernetes API auditing and filtering for security relevant events
|
||||
* [Control plane authentication and certificate root of trust](/docs/concepts/architecture/control-plane-node-communication/): Enable mutual TLS authentication with a trusted CA for communication within the cluster
|
||||
* [Secrets management](/docs/concepts/configuration/secret/): Integrate with a built-in or external secrets store
|
||||
|
||||
## Cloud native complementary security controls
|
||||
|
||||
Kubernetes has direct involvement in the _deploy_ phase and to a lesser extent in the _runtime_ phase. Ensuring the artifacts are securely _developed_ and _distributed_ is necessary for, enabling workloads in Kubernetes to run “secure by default”. Throughout all phases of the Cloud native application life cycle, several complementary security controls exist for Kubernetes orchestrated workloads, which includes but are not limited to:
|
||||
* Develop:
|
||||
- Image signing and verification
|
||||
- Image vulnerability scanners
|
||||
* Distribute:
|
||||
- Pre-deployment checks for detecting excessive privileges
|
||||
- Enabling observability and logging
|
||||
* Deploy:
|
||||
- Using a service mesh for workload authentication and authorization
|
||||
- Enforcing “default deny” network policies for inter-workload communication via [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
|
||||
* Runtime:
|
||||
- Deploying security monitoring agents for workloads
|
||||
- Isolating applications that run on the same node using SELinux, AppArmor, etc.
|
||||
- Scanning configuration against recognized secure baselines for node, workload and orchestrator
|
||||
|
||||
## Understand first, secure next
|
||||
The cloud native way, including containers, provides great security benefits for its users: immutability, modularity, faster upgrades and consistent state across the environment. Realizing this fundamental change in “the way things are done”, motivates us to look at security with a cloud native lens. One of the things that was evident for all the authors of the paper was the fact that it’s tough to make smarter decisions on how and what to secure in a cloud native ecosystem if you do not understand the tools, patterns, and frameworks at hand (in addition to knowing your own critical assets). Hence, for all the security practitioners out there who want to be partners rather than a gatekeeper for your friends in Operations, Product Development, and Compliance, let’s make an attempt to _learn more so we can secure better_.
|
||||
|
||||
We recommend following this **7 step R.U.N.T.I.M.E. path** to get started on cloud native security:
|
||||
1. <b>R</b>ead the paper and any linked material in it
|
||||
2. <b>U</b>nderstand challenges and constraints for your environment
|
||||
3. <b>N</b>ote the content and controls that apply to your environment
|
||||
4. <b>T</b>alk about your observations with your peers
|
||||
5. <b>I</b>nvolve your leadership and ask for help
|
||||
6. <b>M</b>ake a risk profile based on existing and missing security controls
|
||||
7. <b>E</b>xpend time, money, and resources that improve security posture and reduce risk where appropriate.
|
||||
|
||||
## Acknowledgements
|
||||
Huge shout out to _Emily Fox, Tim Bannister (The Scale Factory), Chase Pettet (Mirantis), and Wayne Haber (GitLab)_ for contributing with their wonderful suggestions for this blog post.
|
||||
@@ -31,7 +31,7 @@ This lets you fetch a container image running in the cloud and
|
||||
debug the exact same code locally if needed.
|
||||
|
||||
A ConfigMap is not designed to hold large chunks of data. The data stored in a
|
||||
ConfigMap cannot exeed 1 MiB. If you need to store settings that are
|
||||
ConfigMap cannot exceed 1 MiB. If you need to store settings that are
|
||||
larger than this limit, you may want to consider mounting a volume or use a
|
||||
separate database or file service.
|
||||
|
||||
@@ -88,7 +88,7 @@ data:
|
||||
There are four different ways that you can use a ConfigMap to configure
|
||||
a container inside a Pod:
|
||||
|
||||
1. Command line arguments to the entrypoint of a container
|
||||
1. Inside a container command and args
|
||||
1. Environment variables for a container
|
||||
1. Add a file in read-only volume, for the application to read
|
||||
1. Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap
|
||||
|
||||
@@ -22,6 +22,8 @@ Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.i
|
||||
|
||||
## Additional controllers
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
|
||||
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io) based ingress
|
||||
controller with [community](https://www.getambassador.io/docs) or
|
||||
|
||||
@@ -94,7 +94,7 @@ run, what volume plugin it uses (including Flex), etc. The repository
|
||||
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
|
||||
houses a library for writing external provisioners that implements the bulk of
|
||||
the specification. Some external provisioners are listed under the repository
|
||||
[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns).
|
||||
[kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner).
|
||||
|
||||
For example, NFS doesn't provide an internal provisioner, but an external
|
||||
provisioner can be used. There are also cases when 3rd party storage
|
||||
|
||||
@@ -150,7 +150,7 @@ remembered and reused, even after the Pod is running, for at least a few seconds
|
||||
If you need to discover Pods promptly after they are created, you have a few options:
|
||||
|
||||
- Query the Kubernetes API directly (for example, using a watch) rather than relying on DNS lookups.
|
||||
- Decrease the time of caching in your Kubernetes DNS provider (tpyically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
|
||||
- Decrease the time of caching in your Kubernetes DNS provider (typically this means editing the config map for CoreDNS, which currently caches for 30 seconds).
|
||||
|
||||
|
||||
As mentioned in the [limitations](#limitations) section, you are responsible for
|
||||
|
||||
@@ -142,7 +142,7 @@ The `restartPolicy` applies to all containers in the Pod. `restartPolicy` only
|
||||
refers to restarts of the containers by the kubelet on the same node. After containers
|
||||
in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s,
|
||||
40s, …), that is capped at five minutes. Once a container has executed for 10 minutes
|
||||
without any problems, the kubelet resets the restart backoff timer forthat container.
|
||||
without any problems, the kubelet resets the restart backoff timer for that container.
|
||||
|
||||
## Pod conditions
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
content_type: concept
|
||||
title: Contribute to Kubernetes docs
|
||||
title: Contribute to K8s docs
|
||||
linktitle: Contribute
|
||||
main_menu: true
|
||||
no_list: true
|
||||
@@ -8,7 +8,7 @@ weight: 80
|
||||
card:
|
||||
name: contribute
|
||||
weight: 10
|
||||
title: Start contributing
|
||||
title: Start contributing to K8s
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
@@ -43,7 +43,7 @@ When opening a pull request, you need to know in advance which branch to base yo
|
||||
Scenario | Branch
|
||||
:---------|:------------
|
||||
Existing or new English language content for the current release | `master`
|
||||
Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-release-<version>`. For example, if a feature changes in the `{{< latest-version >}}` release, then add documentation changes to the ``dev-{{< release-branch >}}`` branch.
|
||||
Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
|
||||
Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
|
||||
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ cards:
|
||||
button: "View Tutorials"
|
||||
button_path: "/docs/tutorials"
|
||||
- name: setup
|
||||
title: "Set up a cluster"
|
||||
title: "Set up a K8s cluster"
|
||||
description: "Get Kubernetes running based on your resources and needs."
|
||||
button: "Set up Kubernetes"
|
||||
button_path: "/docs/setup"
|
||||
@@ -57,7 +57,7 @@ cards:
|
||||
button: Contribute to the docs
|
||||
button_path: /docs/contribute
|
||||
- name: release-notes
|
||||
title: Release Notes
|
||||
title: K8s Release Notes
|
||||
description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes.
|
||||
button: "Download Kubernetes"
|
||||
button_path: "/docs/setup/release/notes"
|
||||
|
||||
@@ -143,13 +143,15 @@ different Kubernetes components.
|
||||
| `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |
|
||||
| `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | |
|
||||
| `RunAsGroup` | `true` | Beta | 1.14 | |
|
||||
| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
|
||||
| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
|
||||
| `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 |
|
||||
| `RuntimeClass` | `true` | Beta | 1.14 | |
|
||||
| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 |
|
||||
| `SCTPSupport` | `true` | Beta | 1.19 | |
|
||||
| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 |
|
||||
| `ServerSideApply` | `true` | Beta | 1.16 | |
|
||||
| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 |
|
||||
| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | |
|
||||
| `ServiceAppProtocol` | `false` | Alpha | 1.18 | |
|
||||
| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | |
|
||||
| `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 |
|
||||
| `ServiceAppProtocol` | `true` | Beta | 1.19 | |
|
||||
| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 |
|
||||
| `ServiceNodeExclusion` | `true` | Beta | 1.19 | |
|
||||
| `ServiceTopology` | `false` | Alpha | 1.17 | |
|
||||
|
||||
@@ -27,15 +27,15 @@ The following examples will show how you can interact with the health API endpoi
|
||||
For all endpoints you can use the `verbose` parameter to print out the checks and their status.
|
||||
This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
|
||||
|
||||
```shell
|
||||
curl -k https://localhost:6443/livez?verbose
|
||||
```
|
||||
```shell
|
||||
curl -k https://localhost:6443/livez?verbose
|
||||
```
|
||||
|
||||
or from a remote host with authentication:
|
||||
|
||||
```shell
|
||||
kubectl get --raw='/readyz?verbose'
|
||||
```
|
||||
```shell
|
||||
kubectl get --raw='/readyz?verbose'
|
||||
```
|
||||
|
||||
The output will look like this:
|
||||
|
||||
@@ -62,9 +62,9 @@ The output will look like this:
|
||||
The Kubernetes API server also supports to exclude specific checks.
|
||||
The query parameters can also be combined like in this example:
|
||||
|
||||
```shell
|
||||
curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
|
||||
```
|
||||
```shell
|
||||
curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
|
||||
```
|
||||
|
||||
The output show that the `etcd` check is excluded:
|
||||
|
||||
@@ -98,6 +98,6 @@ The schema for the individual health checks is `/livez/<healthcheck-name>` where
|
||||
The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
|
||||
These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
|
||||
|
||||
```shell
|
||||
curl -k https://localhost:6443/livez/etcd
|
||||
```
|
||||
```shell
|
||||
curl -k https://localhost:6443/livez/etcd
|
||||
```
|
||||
|
||||
@@ -25,10 +25,11 @@ daemons installed:
|
||||
## Running Node Conformance Test
|
||||
|
||||
To run the node conformance test, perform the following steps:
|
||||
|
||||
1. Point your Kubelet to localhost `--api-servers="http://localhost:8080"`,
|
||||
because the test framework starts a local master to test Kubelet. There are some
|
||||
other Kubelet flags you may care:
|
||||
1. Work out the value of the `--kubeconfig` option for the kubelet; for example:
|
||||
`--kubeconfig=/var/lib/kubelet/config.yaml`.
|
||||
Because the test framework starts a local control plane to test the kubelet,
|
||||
use `http://localhost:8080` as the URL of the API server.
|
||||
There are some other kubelet command line parameters you may want to use:
|
||||
* `--pod-cidr`: If you are using `kubenet`, you should specify an arbitrary CIDR
|
||||
to Kubelet, for example `--pod-cidr=10.180.0.0/24`.
|
||||
* `--cloud-provider`: If you are using `--cloud-provider=gce`, you should
|
||||
|
||||
+7
-1
@@ -50,7 +50,7 @@ this example.
|
||||
|
||||
|
||||
1. Configure the kubelet to be a service manager for etcd.
|
||||
|
||||
|
||||
{{< note >}}You must do this on every host where etcd should be running.{{< /note >}}
|
||||
Since etcd was created first, you must override the service priority by creating a new unit file
|
||||
that has higher precedence than the kubeadm-provided kubelet unit file.
|
||||
@@ -68,6 +68,12 @@ this example.
|
||||
systemctl restart kubelet
|
||||
```
|
||||
|
||||
Check the kubelet status to ensure it is running.
|
||||
|
||||
```sh
|
||||
systemctl status kubelet
|
||||
```
|
||||
|
||||
1. Create configuration files for kubeadm.
|
||||
|
||||
Generate one kubeadm configuration file for each host that will have an etcd
|
||||
|
||||
@@ -140,7 +140,7 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow
|
||||
### Joining a Windows worker node
|
||||
{{< note >}}
|
||||
You must install the `Containers` feature and install Docker. Instructions
|
||||
to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.mirantis.com/docker-enterprise/v3.1/dockeree-products/docker-engine-enterprise/dee-windows.html).
|
||||
to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows).
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
|
||||
@@ -532,7 +532,7 @@ This functionality is available in Kubernetes v1.6 and later.
|
||||
|
||||
## Use ConfigMap-defined environment variables in Pod commands
|
||||
|
||||
You can use ConfigMap-defined environment variables in the `command` section of the Pod specification using the `$(VAR_NAME)` Kubernetes substitution syntax.
|
||||
You can use ConfigMap-defined environment variables in the `command` and `args` of a container using the `$(VAR_NAME)` Kubernetes substitution syntax.
|
||||
|
||||
For example, the following Pod specification
|
||||
|
||||
|
||||
@@ -24,10 +24,35 @@ The following steps require an egress configuration, for example:
|
||||
You need to configure the API Server to use the Konnectivity service
|
||||
and direct the network traffic to the cluster nodes:
|
||||
|
||||
1. Make sure that
|
||||
the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
is enabled. You can enable
|
||||
[service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)
|
||||
by providing the following flags to the kube-apiserver:
|
||||
```
|
||||
--service-account-issuer=api
|
||||
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key
|
||||
--api-audiences=system:konnectivity-server
|
||||
```
|
||||
1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`.
|
||||
1. Set the `--egress-selector-config-file` flag of the API Server to the path of
|
||||
your API Server egress configuration file.
|
||||
|
||||
Generate or obtain a certificate and kubeconfig for konnectivity-server.
|
||||
For example, you can use the OpenSSL command line tool to issue a X.509 certificate,
|
||||
using the cluster CA certificate `/etc/kubernetes/pki/ca.crt` from a control-plane host.
|
||||
|
||||
```bash
|
||||
openssl req -subj "/CN=system:konnectivity-server" -new -newkey rsa:2048 -nodes -out konnectivity.csr -keyout konnectivity.key -out konnectivity.csr
|
||||
openssl x509 -req -in konnectivity.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out konnectivity.crt -days 375 -sha256
|
||||
SERVER=$(kubectl config view -o jsonpath='{.clusters..server}')
|
||||
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-credentials system:konnectivity-server --client-certificate konnectivity.crt --client-key konnectivity.key --embed-certs=true
|
||||
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-cluster kubernetes --server "$SERVER" --certificate-authority /etc/kubernetes/pki/ca.crt --embed-certs=true
|
||||
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config set-context system:konnectivity-server@kubernetes --cluster kubernetes --user system:konnectivity-server
|
||||
kubectl --kubeconfig /etc/kubernetes/konnectivity-server.conf config use-context system:konnectivity-server@kubernetes
|
||||
rm -f konnectivity.crt konnectivity.key konnectivity.csr
|
||||
```
|
||||
|
||||
Next, you need to deploy the Konnectivity server and agents.
|
||||
[kubernetes-sigs/apiserver-network-proxy](https://github.com/kubernetes-sigs/apiserver-network-proxy)
|
||||
is a reference implementation.
|
||||
|
||||
@@ -46,7 +46,7 @@ tutorial.
|
||||
After this tutorial, you will know the following.
|
||||
|
||||
- How to deploy a ZooKeeper ensemble using StatefulSet.
|
||||
- How to consistently configure the ensemble using ConfigMaps.
|
||||
- How to consistently configure the ensemble.
|
||||
- How to spread the deployment of ZooKeeper servers in the ensemble.
|
||||
- How to use PodDisruptionBudgets to ensure service availability during planned maintenance.
|
||||
|
||||
@@ -770,7 +770,7 @@ In one terminal window, use the following command to watch the Pods in the `zk`
|
||||
kubectl get pod -w -l app=zk
|
||||
```
|
||||
|
||||
In another window, using the following command to delete the `zkOk.sh` script from the file system of Pod `zk-0`.
|
||||
In another window, using the following command to delete the `zookeeper-ready` script from the file system of Pod `zk-0`.
|
||||
|
||||
```shell
|
||||
kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
|
||||
|
||||
@@ -18,4 +18,4 @@ egressSelections:
|
||||
# The other supported transport is "tcp". You will need to set up TLS
|
||||
# config to secure the TCP transport.
|
||||
uds:
|
||||
udsName: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket
|
||||
udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket
|
||||
|
||||
@@ -22,7 +22,7 @@ spec:
|
||||
- key: "CriticalAddonsOnly"
|
||||
operator: "Exists"
|
||||
containers:
|
||||
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.8
|
||||
- image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.12
|
||||
name: konnectivity-agent
|
||||
command: ["/proxy-agent"]
|
||||
args: [
|
||||
@@ -32,6 +32,8 @@ spec:
|
||||
# this is the IP address of the master machine.
|
||||
"--proxy-server-host=35.225.206.7",
|
||||
"--proxy-server-port=8132",
|
||||
"--admin-server-port=8133",
|
||||
"--health-server-port=8134",
|
||||
"--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token"
|
||||
]
|
||||
volumeMounts:
|
||||
@@ -39,7 +41,7 @@ spec:
|
||||
name: konnectivity-agent-token
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
port: 8093
|
||||
port: 8134
|
||||
path: /healthz
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 15
|
||||
|
||||
@@ -8,34 +8,33 @@ spec:
|
||||
hostNetwork: true
|
||||
containers:
|
||||
- name: konnectivity-server-container
|
||||
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.8
|
||||
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.12
|
||||
command: ["/proxy-server"]
|
||||
args: [
|
||||
"--log-file=/var/log/konnectivity-server.log",
|
||||
"--logtostderr=false",
|
||||
"--log-file-max-size=0",
|
||||
"--logtostderr=true",
|
||||
# This needs to be consistent with the value set in egressSelectorConfiguration.
|
||||
"--uds-name=/etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket",
|
||||
"--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket",
|
||||
# The following two lines assume the Konnectivity server is
|
||||
# deployed on the same machine as the apiserver, and the certs and
|
||||
# key of the API Server are at the specified location.
|
||||
"--cluster-cert=/etc/srv/kubernetes/pki/apiserver.crt",
|
||||
"--cluster-key=/etc/srv/kubernetes/pki/apiserver.key",
|
||||
"--cluster-cert=/etc/kubernetes/pki/apiserver.crt",
|
||||
"--cluster-key=/etc/kubernetes/pki/apiserver.key",
|
||||
# This needs to be consistent with the value set in egressSelectorConfiguration.
|
||||
"--mode=grpc",
|
||||
"--server-port=0",
|
||||
"--agent-port=8132",
|
||||
"--admin-port=8133",
|
||||
"--health-port=8134",
|
||||
"--agent-namespace=kube-system",
|
||||
"--agent-service-account=konnectivity-agent",
|
||||
"--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig",
|
||||
"--kubeconfig=/etc/kubernetes/konnectivity-server.conf",
|
||||
"--authentication-audience=system:konnectivity-server"
|
||||
]
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
scheme: HTTP
|
||||
host: 127.0.0.1
|
||||
port: 8133
|
||||
port: 8134
|
||||
path: /healthz
|
||||
initialDelaySeconds: 30
|
||||
timeoutSeconds: 60
|
||||
@@ -46,25 +45,28 @@ spec:
|
||||
- name: adminport
|
||||
containerPort: 8133
|
||||
hostPort: 8133
|
||||
- name: healthport
|
||||
containerPort: 8134
|
||||
hostPort: 8134
|
||||
volumeMounts:
|
||||
- name: varlogkonnectivityserver
|
||||
mountPath: /var/log/konnectivity-server.log
|
||||
readOnly: false
|
||||
- name: pki
|
||||
mountPath: /etc/srv/kubernetes/pki
|
||||
- name: k8s-certs
|
||||
mountPath: /etc/kubernetes/pki
|
||||
readOnly: true
|
||||
- name: kubeconfig
|
||||
mountPath: /etc/kubernetes/konnectivity-server.conf
|
||||
readOnly: true
|
||||
- name: konnectivity-uds
|
||||
mountPath: /etc/srv/kubernetes/konnectivity-server
|
||||
mountPath: /etc/kubernetes/konnectivity-server
|
||||
readOnly: false
|
||||
volumes:
|
||||
- name: varlogkonnectivityserver
|
||||
- name: k8s-certs
|
||||
hostPath:
|
||||
path: /var/log/konnectivity-server.log
|
||||
path: /etc/kubernetes/pki
|
||||
- name: kubeconfig
|
||||
hostPath:
|
||||
path: /etc/kubernetes/konnectivity-server.conf
|
||||
type: FileOrCreate
|
||||
- name: pki
|
||||
hostPath:
|
||||
path: /etc/srv/kubernetes/pki
|
||||
- name: konnectivity-uds
|
||||
hostPath:
|
||||
path: /etc/srv/kubernetes/konnectivity-server
|
||||
path: /etc/kubernetes/konnectivity-server
|
||||
type: DirectoryOrCreate
|
||||
|
||||
@@ -6,7 +6,7 @@ spec:
|
||||
containers:
|
||||
- name: test-container
|
||||
image: k8s.gcr.io/busybox
|
||||
command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
|
||||
command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
|
||||
env:
|
||||
- name: SPECIAL_LEVEL_KEY
|
||||
valueFrom:
|
||||
|
||||
@@ -10,16 +10,19 @@ class: training
|
||||
<section class="call-to-action">
|
||||
<div class="main-section">
|
||||
<div class="call-to-action" id="cta-certification">
|
||||
<div class="logo-certification cta-image cta-image-before" id="logo-cka">
|
||||
<img src="/images/training/kubernetes-cka-white.svg"/>
|
||||
</div>
|
||||
<div class="logo-certification cta-image cta-image-after" id="logo-ckad">
|
||||
<img src="/images/training/kubernetes-ckad-white.svg"/>
|
||||
</div>
|
||||
<div class="cta-text">
|
||||
<h2>Build your cloud native career</h2>
|
||||
<p>Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.</p>
|
||||
</div>
|
||||
<div class="logo-certification cta-image" id="logo-cka">
|
||||
<img src="/images/training/kubernetes-cka-white.svg"/>
|
||||
</div>
|
||||
<div class="logo-certification cta-image" id="logo-ckad">
|
||||
<img src="/images/training/kubernetes-ckad-white.svg"/>
|
||||
</div>
|
||||
<div class="logo-certification cta-image" id="logo-cks">
|
||||
<img src="/images/training/kubernetes-cks-white.svg"/>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
@@ -74,31 +77,36 @@ class: training
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<section>
|
||||
<section id="get-certified">
|
||||
<div class="main-section padded">
|
||||
<center>
|
||||
<h2>Get Kubernetes Certified</h2>
|
||||
</center>
|
||||
<h2>Get Kubernetes Certified</h2>
|
||||
<div class="col-container">
|
||||
<div class="col-nav">
|
||||
<center>
|
||||
<h5>
|
||||
<b>Certified Kubernetes Application Developer (CKAD)</b>
|
||||
</h5>
|
||||
<p>The Certified Kubernetes Application Developer exam certifies that users can design, build, configure, and expose cloud native applications for Kubernetes.</p>
|
||||
<p>A CKAD can define application resources and use core primitives to build, monitor, and troubleshoot scalable applications and tools in Kubernetes.</p>
|
||||
<br>
|
||||
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Go to Certification</a>
|
||||
</center>
|
||||
</div>
|
||||
<div class="col-nav">
|
||||
<center>
|
||||
<h5>
|
||||
<b>Certified Kubernetes Administrator (CKA)</b>
|
||||
</h5>
|
||||
<p>The Certified Kubernetes Administrator (CKA) program provides assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators.</p>
|
||||
<p>A certified Kubernetes administrator has demonstrated the ability to do basic installation as well as configuring and managing production-grade Kubernetes clusters.</p>
|
||||
<br>
|
||||
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Go to Certification</a>
|
||||
</center>
|
||||
</div>
|
||||
<div class="col-nav">
|
||||
<h5>
|
||||
<b>Certified Kubernetes Security Specialist (CKS)</b>
|
||||
</h5>
|
||||
<p>The Certified Kubernetes Security Specialist program provides assurance that the holder is comfortable and competent with a broad range of best practices. CKS certification covers skills for securing container-based applications and Kubernetes platforms during build, deployment and runtime.</p>
|
||||
<p><em>Candidates for CKS must hold a current Certified Kubernetes Administrator (CKA) certification to demonstrate they possess sufficient Kubernetes expertise before sitting for the CKS.</em></p>
|
||||
<br>
|
||||
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">Go to Certification</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user