Release 20.01.2022

* Cloud Functions: add quick start for Java.

* Managed Service for ClickHouse: added CPU-optimized host types.

* Managed Service for Greenplum: added CPU-optimized host types.

* Managed Service for Kubernetes: added information about taint and toleration.

* Managed Service for MongoDB: added CPU-optimized host types.

* Managed Service for MySQL: added CPU-optimized host types.

* Managed Service for PostgreSQL: added CPU-optimized host types.

* Tracker: added reference for YFM markup used in issue descriptions and comments.

* Translations updated.

* Fixes and improvements.

Author: DataUI VCS Robot

en/_includes/datasphere/notebook-support.md

@@ -7,5 +7,5 @@ To contact technical support in the service:
 1. Click **Report a bug**.
    You'll receive your request number by email.
 
-You can monitor the request status via the Yandex.Cloud mobile app for [iOS](https://apps.apple.com/app/yandex-cloud/id1515465314) or [Android](https://play.google.com/store/apps/details?id=ru.yandex.cloud) and in the [Support]({{ link-console-support }}) section in the management console.
+You can monitor the request status via the Yandex.Cloud mobile app for [iOS](https://apps.apple.com/ru/app/yandex-cloud/id1515465314) or [Android](https://play.google.com/store/apps/details?id=ru.yandex.cloud) and in the [Support]({{ link-console-support }}) section in the management console.
 

en/_includes/mdb/mmy-dbms-user-settings.md

@@ -6,7 +6,7 @@
 
   To learn more about authentication plugins, see the [{{ MY }} documentation](https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html).
 
-- **Administrative privileges**{#setting-administrative-priveleges} {{ tag-con }} {{ tag-cli }} {{ tag-tf }}
+- **Administrative privileges**{#setting-administrative-privileges} {{ tag-con }} {{ tag-cli }} {{ tag-tf }}
 
   Administrative privileges are [user permissions](../../managed-mysql/concepts/user-rights.md) that apply at the level of the entire DB cluster.
 

en/_includes/solutions/terraform-install.md

@@ -4,7 +4,7 @@
 
   Use one of the following methods:
 
-  * [Download the Terraform distribution](https://www.terraform.io/downloads.html) and install it by following the [instructions](https://www.terraform.io/intro/getting-started/install.html).
+  * [Download the Terraform distribution](https://www.terraform.io/downloads.html) and install it by following the [instructions](https://learn.hashicorp.com/tutorials/terraform/install-cli?in=terraform/aws-get-started).
 
   * Install Terraform using the [Chocolatey](https://chocolatey.org/install) package manager. To do this, run the command:
 
@@ -14,13 +14,13 @@
 
 - Linux
 
-  [Download the Terraform distribution](https://www.terraform.io/downloads.html) and install it by following the [instructions](https://www.terraform.io/intro/getting-started/install.html).
+  [Download the Terraform distribution](https://www.terraform.io/downloads.html) and install it by following the [instructions](https://learn.hashicorp.com/tutorials/terraform/install-cli?in=terraform/aws-get-started).
 
 - macOS
 
   Use one of the following methods:
 
-    * [Download the Terraform distribution](https://www.terraform.io/downloads.html) and install it by following the [instructions](https://www.terraform.io/intro/getting-started/install.html).
+    * [Download the Terraform distribution](https://www.terraform.io/downloads.html) and install it by following the [instructions](https://learn.hashicorp.com/tutorials/terraform/install-cli?in=terraform/aws-get-started).
 
     * Install Terraform using the [Homebrew](https://brew.sh) package manager. To do  this, run the command:
 

en/data-proc/operations/cluster-update.md

@@ -10,7 +10,7 @@ After creating a cluster, you can modify its basic and advanced settings.
 
     1. Select the cluster and click **Edit cluster** in the top panel.
 
-    1. To edit the [log group](../../logging/concepts/log-group.md/) that cluster logs are sent to, select a new log group from the list. If necessary, [create a new log group](../../logging/operations/create-group.md).
+    1. To edit the [log group](../../logging/concepts/log-group.md) that cluster logs are sent to, select a new log group from the list. If necessary, [create a new log group](../../logging/operations/create-group.md).
 
         To enable this feature, [assign the cluster service account](../../iam/operations/roles/grant.md#access-to-sa) the `logging.writer` role. For more information, see the [{{ cloud-logging-full-name }} documentation](../../logging/security/index.md).
 

en/datasphere/concepts/preinstalled-packages.md

@@ -75,7 +75,7 @@ Packages for data analysis and machine learning are pre-installed in {{ ml-platf
 * [fairseq](https://github.com/pytorch/fairseq)
 * [fastai](https://docs.fast.ai/)
 * [fastprogress](https://github.com/fastai/fastprogress)
-* [filelock](https://filelock.readthedocs.io/en/latest/)
+* [filelock](https://py-filelock.readthedocs.io/en/latest/index.html#installation)
 * [flatten-json](https://github.com/amirziai/flatten)
 * [flufl.lock](https://flufllock.readthedocs.io/en/stable/)
 * [FSSPEC](https://filesystem-spec.readthedocs.io/en/latest/?badge=latest)
@@ -214,7 +214,7 @@ Packages for data analysis and machine learning are pre-installed in {{ ml-platf
 * [python-jose](https://python-jose.readthedocs.io/en/latest/)
 * [python-slugify](https://github.com/un33k/python-slugify)
 * [pytorch-ranger](https://github.com/mpariente/Ranger-Deep-Learning-Optimizer)
-* [pytz](https://tidelift.com/subscription/pkg/pypi-pytz)
+* [pytz](https://github.com/stub42/pytz)
 * [pyxdg](https://github.com/takluyver/pyxdg)
 * [PyYAML](https://pyyaml.org/wiki/PyYAMLDocumentation)
 * [PyZMQ](https://pyzmq.readthedocs.io/en/latest/)

en/managed-gitlab/index.yaml

@@ -2,7 +2,7 @@ title: Yandex Managed Service for GitLab
 description:
   - >-
     <em>Yandex Managed Service for GitLab is at the<a
-    href=\"/docs/overview/concepts/launch-stages\">Preview</a> stage.</em>
+    href="docs/overview/concepts/launch-stages">Preview</a> stage.</em>
   - >-
     Managed Service for GitLab helps you deploy and maintain GitLab instances in
     the Yandex.Cloud infrastructure.

en/managed-kubernetes/concepts/index.md

@@ -21,7 +21,7 @@ Groups of {{ k8s }} nodes require internet access for downloading images and com
 
 Internet access can be provided in the following ways:
 * By assigning each node in the group a [public IP address](../../vpc/concepts/address.md#public-addresses).
-* [Configuring a VM as a NAT instance](../../solutions/routing/nat-instance.md).
+* [Configuring a virtual machine as a NAT instance](../../solutions/routing/nat-instance.md).
 * [Enabling NAT to the internet](../../vpc/operations/enable-nat.md).
 
 {% endnote %}
@@ -99,17 +99,15 @@ By default, a service is only available within a specific {{ k8s }} cluster, but
 
 _A namespace_ is an abstraction that logically isolates {{ k8s }} cluster resources and distributes quotas to them. This is useful for isolating resources of different teams and projects in a single {{ k8s }} cluster.
 
-### Service accounts {#service-accounts}
+## Service accounts {#service-accounts}
 
 {{ managed-k8s-full-name }} clusters use two types of service accounts:
 * **Cloud service accounts**
-
-  These accounts exist at the individual folder level in the cloud and can be used by {{ managed-k8s-name }} and other services.
+  These accounts exist on the level of a cloud's individual folders and can be used by {{ managed-k8s-name }} and other services.
 
   For more information, see [{#T}](../security/index.md) and [{#T}](../../iam/concepts/users/service-accounts.md).
 * **{{ k8s }} service accounts**
-
-  These accounts exist and function only at the individual {{ managed-k8s-name }} cluster level. {{ k8s }} uses them:
+  These accounts exist and are only valid on the level of an individual {{ managed-k8s-name }} cluster. They are applied by {{ k8s }}:
   * To authenticate cluster API calls from applications deployed in the cluster.
   * To configure access for these applications.
 
@@ -127,7 +125,7 @@ In the service documentation, _service account_ refers to a regular cloud servic
 
 {% endnote %}
 
-### Node labels {#node-labels}
+## Node labels {#node-labels}
 
 _Node labels_, `node_labels` are a mechanism for grouping nodes together in {{ k8s }}. You can use node labels to manage pod distribution across the nodes of a cluster. For more information, see the [{{ k8s }} documentation](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes).
 

en/managed-kubernetes/concepts/limits.md

@@ -1,13 +1,14 @@
 ---
 title: Quotas and Limits in Managed Service for Kubernetes
-description: 'Managed Service for Kubernetes has limits and quotas for the total number of vCPUs for all nodes, the total amount of RAM, the total amount of disks, the maximum number of Kubernetes clusters in one cloud. You will learn more about the limitations of the service in this article. '
+description: 'Managed Service for Kubernetes has limits and quotas for the total number of vCPUs for all nodes, the total amount of RAM, the total amount of disks, the maximum number of Kubernetes clusters in one cloud. You will learn more about the limitations of the service in this article.'
 ---
 
 # Quotas and limits in {{ managed-k8s-name }}
 
-In the {{ managed-k8s-name }} service, the following limitations apply:
+{{ managed-k8s-name }} has the following limits:
 
 {% include [quotes-limits-def.md](../../_includes/quotes-limits-def.md) %}
 
-{% include [limits-managed-kube](../../_includes/managed-kube-limits.md) %}
+{{ managed-k8s-name }} uses the specified maximum node group size as the actual size, regardless of the current size.
 
+{% include [limits-managed-kube](../../_includes/managed-kube-limits.md) %}

en/managed-kubernetes/concepts/release-channels-and-updates.md

@@ -2,59 +2,56 @@
 
 {{ managed-k8s-name }} provides updates through [release channels](#release-channels).
 
-The service supports three versions of {{ k8s }}. Master and node group versions are independent and you can specify different versions of {{ k8s }} available within a single release channel when creating them.
+The service supports three {{ k8s }} release channels. Master and node group versions are independent and you can specify different versions of {{ k8s }} available within a single release channel when creating them.
 
 {% include [note-about-version](../../_includes/managed-kubernetes/note-about-version.md) %}
 
 When creating a {{ k8s }} cluster, specify one of three release channels. You can't change the channel once the {{ k8s }} cluster is created, you can only recreate the {{ k8s }} cluster and specify a new release channel. The table below describes release channels and contains up-to-date information about supported {{ k8s }} versions.
 
-| Channel | versions {{ k8s }} | Automatic updates | Channel description |
-| ---- | ---- | ---- | ---- |
-| `rapid` | 1.17, 1.18, 1.19, 1.20, 1.21 | Can't disable automatic updates. Can specify a time period for automatic updates. | Contains the latest versions of {{ k8s }}. Minor updates with new functions and improvements are often added. |
-| `regular` | 1.17, 1.18, 1.19, 1.20, 1.21 | Can disable automatic updates. | Contains different versions of {{ k8s }}. New functions and improvements are added in chunks shortly after they appear on `rapid`. |
-| `stable` | 1.17, 1.18, 1.19, 1.20, 1.21 | Can disable automatic updates. | Contains the stable version of {{ k8s }}. Only updates related to bug fixes or security improvements are added to the channel. |
+Channel | {{ k8s }} versions | Automatic updates | Channel description
+--- | --- | --- | ---
+`rapid` | 1.17, 1.18, 1.19, 1.20, and 1.21 | Can't disable automatic updates. Can specify a time period for automatic updates. | Contains the latest versions of {{ k8s }}. Minor updates with new functions and improvements are often added.
+`regular` | 1.17, 1.18, 1.19, 1.20, and 1.21 | Can disable automatic updates. | Contains different versions of {{ k8s }}. New functions and improvements are added in chunks shortly after they appear on `rapid`.
+`stable` | 1.17, 1.18, 1.19, 1.20, and 1.21 | Can disable automatic updates. | Contains the stable version of {{ k8s }}. Only updates related to bug fixes or security improvements are added to the channel.
 
 ## Updates {#updates}
 
 When an update appears on a release channel, the corresponding information is displayed in the management console. You can install updates automatically or manually.
+* Automatic updates are installed in the specified period of time with no interaction from the user.
 
-- Automatic updates are installed in the specified period of time with no interaction from the user.
+  Updates are triggered and should be completed within the specified period. In some cases, when updating a node group, an update may continue beyond such period.
 
-    Updates are triggered and should be completed within the specified period. In some cases, when updating a node group, an update may continue beyond such period.
+  Automatic updates include: new {{ managed-k8s-name }} functions, improvements, and fixes, as well as {{ k8s }} component fixes.
 
-    Automatic updates include: new {{ managed-k8s-name }} functions, improvements, and fixes, as well as {{ k8s }} component fixes.
+  {% note alert %}
 
-    {% note alert %}
+  If [{{ k8s }} version support ends](#unsupported), minor {{ k8s }} versions get updated as well.
 
-    If [{{ k8s }} version support ends](#unsupported), minor {{ k8s }} versions get updated as well.
+  {% endnote %}
 
-    {% endnote %}
+* Manual updates can be initiated by the user at any time.
 
-- Manual updates can be initiated by the user at any time.
-
-    These include {{ k8s }} minor version updates.
+  These include {{ k8s }} minor version updates.
 
 Read more about [{{k8s}} version support termination](#unsupported) and the [cluster component update{{ k8s }}](#cluster-upd) process.
 
-### Version support termination {{ k8s }} {#unsupported}
+### {{ k8s }} version support termination {#unsupported}
 
 When an old version of {{ k8s }} is no longer supported after an update:
-
-- The master is automatically updated even if automatic updates are disabled.
-- Node groups are automatically updated if automatic updates are enabled. If automatic updates are disabled, the old version of {{ k8s }} remains on the node groups. In this case, the user is fully responsible for solving problems related to the node group, since the old version of {{ k8s }} is deprecated.
+* The master is automatically updated even if automatic updates are disabled.
+* Node groups are automatically updated if automatic updates are enabled. If automatic updates are disabled, the old version of {{ k8s }} remains on the node groups. In this case, the user is fully responsible for solving problems related to the node group, since the old version of {{ k8s }} is deprecated.
 
 ### Updating Kubernetes cluster components {#cluster-upd}
 
 The update process is different for [masters](#master) and [node groups](#node-group).
 
-#### Masters {#master}
+#### Master {#master}
 
 Depending on the type of master, it may or may not be available during an update:
+* Zonal masters are unavailable during updates.
+* Regional masters remain available during updates.
 
-- Zonal masters are unavailable during updates.
-- Regional masters remain available during updates.
-
-#### Node groups {#node-group}
+#### Node group {#node-group}
 
 You can update node groups with additional resources by creating nodes with a new configuration.
 
@@ -65,10 +62,23 @@ For an update to be successful, you need enough [quotas](limits.md) to create a
 {% endnote %}
 
 Update node group algorithm:
-
 1. An updated node is created with the configuration specified for the entire node group.
 1. All pods are [evicted](node-group/node-drain.md) from one of the old nodes based on the pre-defined PodDisruptionBudgets policy. Then the node is deleted.
 1. The process is repeated until all nodes in the group are updated.
 
 This ensures that the number of nodes in the node group never falls below the number specified when the group is created.
 
+#### Certificates {#certificates}
+
+In accordance with the safety recommendations, [cluster and node group certificates](https://kubernetes.io/docs/setup/best-practices/certificates/) are issued for a year. When a certificate expires, a cluster or node group is disabled. To avoid this, {{ managed-k8s-name }} automatically updates their certificates.
+* Each time a cluster or node group is updated.
+* For node groups with automatic updates disabled:
+  * If you use {{ k8s }} 1.16 or higher, certificates are forcibly updated one week before the expiry.
+
+    Updates do not disrupt the operation of pods running on nodes.
+
+    This applies to nodes created or updated at least once since May 2021.
+
+  * If the {{ k8s }} version is lower than 1.16, certificates are updated at any cluster or node group update.
+
+For more information about updating certificates, see the [{{ k8s }} documentation](https://kubernetes.io/docs/tasks/tls/certificate-rotation/).