New Crowdin updates

uk/content/uk/releases/_index.md

@@ -0,0 +1,26 @@
+---
+linktitle: Release History
+title: Releases
+type: docs
+---
+
+
+<!-- overview -->
+
+The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support.
+
+Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
+
+More information in the [version skew policy](/releases/version-skew-policy/) document.
+
+<!-- body -->
+
+## Release History
+
+{{< release-data >}}
+
+## Upcoming Release
+
+Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release!
+
+## Helpful Resources

uk/content/uk/releases/download.md

@@ -0,0 +1,55 @@
+---
+title: Завантажити Kubernetes
+type: docs
+---
+
+Kubernetes ships binaries for each component as well as a standard set of client applications to bootstrap or interact with a cluster. Components like the API server are capable of running within container images inside of a cluster. Those components are also shipped in container images as part of the official release process. All binaries as well as container images are available for multiple operating systems as well as hardware architectures.
+
+## Container Images
+
+All Kubernetes container images are deployed to the `registry.k8s.io` container image registry.
+
+{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
+
+For Kubernetes {{< param "version" >}}, the following container images are signed using [cosign](https://github.com/sigstore/cosign) signatures:
+
+| Container Image                                                     | Supported Architectures           |
+| ------------------------------------------------------------------- | --------------------------------- |
+| registry.k8s.io/kube-apiserver:{{< param "fullversion" >}}          | amd64, arm, arm64, ppc64le, s390x |
+| registry.k8s.io/kube-controller-manager:{{< param "fullversion" >}} | amd64, arm, arm64, ppc64le, s390x |
+| registry.k8s.io/kube-proxy:{{< param "fullversion" >}}              | amd64, arm, arm64, ppc64le, s390x |
+| registry.k8s.io/kube-scheduler:{{< param "fullversion" >}}          | amd64, arm, arm64, ppc64le, s390x |
+| registry.k8s.io/conformance:{{< param "fullversion" >}}             | amd64, arm, arm64, ppc64le, s390x |
+
+All container images are available for multiple architectures, whereas the container runtime should choose the correct one based on the underlying platform. It is also possible to pull a dedicated architecture by suffixing the container image name, for example `registry.k8s.io/kube-apiserver-arm64:{{< param "fullversion" >}}`. All those derivations are signed in the same way as the multi-architecture manifest lists.
+
+The Kubernetes project publishes a list of signed Kubernetes container images in [SPDX 2.2](https://spdx.dev/specifications/) format. You can fetch that list using:
+
+```shell
+curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/latest.txt)/release"  | awk '/Package: registry.k8s.io\// {print $3}'
+```
+For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that you can verify integrity for is a container image, using the experimental signing support.
+
+To manually verify signed container images of Kubernetes core components, refer to [Verify Signed Container Images](/docs/tasks/administer-cluster/verify-signed-artifacts).
+
+
+
+## Binaries
+
+Find links to download Kubernetes components (and their checksums) in the [CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) files.
+
+Alternately, use [downloadkubernetes.com](https://www.downloadkubernetes.com/) to filter by version and architecture.
+
+### kubectl
+
+<!-- overview -->
+
+The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows you to run commands against Kubernetes clusters.
+
+You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. For more information including a complete list of kubectl operations, see the [`kubectl` reference documentation](/docs/reference/kubectl/).
+
+kubectl is installable on a variety of Linux platforms, macOS and Windows. Find your preferred operating system below.
+
+- [Install kubectl on Linux](/docs/tasks/tools/install-kubectl-linux)
+- [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos)
+- [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows)

uk/content/uk/releases/notes.md

@@ -0,0 +1,13 @@
+---
+linktitle: Release Notes
+title: Notes
+type: docs
+description: >
+  Kubernetes release notes.
+sitemap:
+  priority: 0.5
+---
+
+Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) that matches your Kubernetes version. View the changelog for {{< skew currentVersionAddMinor 0 >}} on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md).
+
+Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io). View filtered release notes for {{< skew currentVersionAddMinor 0 >}} on [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0).

uk/content/uk/releases/patch-releases.md

@@ -0,0 +1,75 @@
+---
+title: Patch Releases
+type: docs
+---
+
+Schedule and team contact information for Kubernetes patch releases.
+
+For general information about Kubernetes release cycle, see the [release process description][].
+
+## Cadence
+
+Our typical patch release cadence is monthly. It is commonly a bit faster (1 to 2 weeks) for the earliest patch releases after a 1.X minor release. Critical bug fixes may cause a more immediate release outside of the normal cadence. We also aim to not make releases during major holiday periods.
+
+## Contact
+
+See the [Release Managers page][release-managers] for full contact details on the Patch Release Team.
+
+Please give us a business day to respond - we may be in a different timezone!
+
+In between releases the team is looking at incoming cherry pick requests on a weekly basis. The team will get in touch with submitters via GitHub PR, SIG channels in Slack, and direct messages in Slack and [email](mailto:[email protected]) if there are questions on the PR.
+
+## Cherry picks
+
+Please follow the [cherry pick process][cherry-picks].
+
+Cherry picks must be merge-ready in GitHub with proper labels (e.g., `approved`, `lgtm`, `release-note`) and passing CI tests ahead of the cherry pick deadline. This is typically two days before the target release, but may be more. Earlier PR readiness is better, as we need time to get CI signal after merging your cherry picks ahead of the actual release.
+
+Cherry pick PRs which miss merge criteria will be carried over and tracked for the next patch release.
+
+## Support Period
+
+In accordance with the [yearly support KEP][yearly-support], the Kubernetes Community will support active patch release series for a period of roughly fourteen (14) months.
+
+The first twelve months of this timeframe will be considered the standard period.
+
+Towards the end of the twelve month, the following will happen:
+
+- [Release Managers][release-managers] will cut a release
+- The patch release series will enter maintenance mode
+
+During the two-month maintenance mode period, Release Managers may cut additional maintenance releases to resolve:
+
+- CVEs (under the advisement of the Security Response Committee)
+- dependency issues (including base image updates)
+- critical core component issues
+
+At the end of the two-month maintenance mode period, the patch release series will be considered EOL (end of life) and cherry picks to the associated branch are to be closed soon afterwards.
+
+Note that the 28th of the month was chosen for maintenance mode and EOL target dates for simplicity (every month has it).
+
+## Upcoming Monthly Releases
+
+Timelines may vary with the severity of bug fixes, but for easier planning we will target the following monthly release points. Unplanned, critical releases may also occur in between these.
+
+| Monthly Patch Release | Cherry Pick Deadline | Target date |
+| --------------------- | -------------------- | ----------- |
+| April 2023            | 2023-04-07           | 2023-04-12  |
+| May 2023              | 2023-05-12           | 2023-05-17  |
+| June 2023             | 2023-06-09           | 2023-06-14  |
+
+## Detailed Release History for Active Branches
+
+{{< release-branches >}}
+
+## Non-Active Branch history
+
+These releases are no longer supported.
+
+{{< eol-releases >}}
+
+[cherry-picks]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md
+[release-managers]: /releases/release-managers
+[release-managers]: /releases/release-managers
+[release process description]: /releases/release
+[yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md