fix some broken links (#17897)

content/en/blog/_posts/2017-05-00-Kubernetes-Security-Process-Explained.md

@@ -13,7 +13,7 @@ The Kubernetes community believes that we can help teams restore their footing o
 
 With over 1,200 contributors and [over a million lines of code](https://www.openhub.net/p/kubernetes), each release of Kubernetes is a massive undertaking staffed by brave volunteer [release managers](https://github.com/kubernetes/community/wiki). These normal releases are fully transparent and the process happens in public. However, security releases must be handled differently to keep potential attackers in the dark until a fix is made available to users.  
 
-We drew inspiration from other open source projects in order to create the [**Kubernetes security release process**](https://github.com/kubernetes/community/blob/master/contributors/devel/security-release-process.md). Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the [Product Security Team](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc) to handle this process.
+We drew inspiration from other open source projects in order to create the [**Kubernetes security release process**](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md). Unlike a regularly scheduled release, a security release must be delivered on an accelerated schedule, and we created the [Product Security Team](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc) to handle this process.
 
 This team quickly selects a lead to coordinate work and manage communication with the persons that disclosed the vulnerability and the Kubernetes community. The security release process also documents ways to measure vulnerability severity using the [Common Vulnerability Scoring System (CVSS) Version 3.0 Calculator](https://www.first.org/cvss/calculator/3.0). This calculation helps inform decisions on release cadence in the face of holidays or limited developer bandwidth. By making severity criteria transparent we are able to better set expectations and hit critical timelines during an incident where we strive to:  
 

content/en/blog/_posts/2017-06-00-Kubernetes-1-7-Security-Hardening-Stateful-Application-Extensibility-Updates.md

@@ -32,7 +32,8 @@ Stateful workloads:
 Extensibility:  
 
 - [API aggregation](/docs/concepts/api-extension/apiserver-aggregation/) at runtime is the most powerful extensibility features in this release, allowing power users to add Kubernetes-style pre-built, 3rd party or user-created APIs to their cluster.
-- [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. [Validation tests for the CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md) have been published and Alpha integration with [containerd](http://containerd.io/), which supports basic pod lifecycle and image management is now available. Read our previous [in-depth post introducing CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes).
+
+- [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) (CRI) has been enhanced with New RPC calls to retrieve container metrics from the runtime. [Validation tests for the CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-validation.md) have been published and Alpha integration with [containerd](http://containerd.io/), which supports basic pod lifecycle and image management is now available. Read our previous [in-depth post introducing CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes).
 
 Additional Features:  
 

content/en/blog/_posts/2017-11-00-Containerd-Container-Runtime-Options-Kubernetes.md

@@ -72,9 +72,9 @@ Cri-containerd v1.0.0-alpha.0 was released on Sep. 25, 2017.
 
 It is feature complete. All Kubernetes features are supported.  
 
-All [CRI validation test](https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md)s have passed. (A CRI validation is a test framework for validating whether a CRI implementation meets all the requirements expected by Kubernetes.)  
+All [CRI validation tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-validation.md) have passed. (A CRI validation is a test framework for validating whether a CRI implementation meets all the requirements expected by Kubernetes.)  
 
-All regular [node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md)s have passed. (The Kubernetes test framework for testing Kubernetes node level functionalities such as managing pods, mounting volumes etc.)  
+All regular [node e2e tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md) have passed. (The Kubernetes test framework for testing Kubernetes node level functionalities such as managing pods, mounting volumes etc.)  
 
 To learn more about the v1.0.0-alpha.0 release, see the [project repository](https://github.com/kubernetes-incubator/cri-containerd/releases/tag/v1.0.0-alpha.0).
 

content/ja/docs/setup/release/version-skew-policy.md

@@ -104,7 +104,7 @@ HAクラスター内の`kube-apiserver`間にバージョンの差異がある
 `kube-apiserver`を**1.(n+1)**にアップグレードしてください。
 
 {{< note >}}
-[非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
+[非推奨API](/docs/reference/using-api/deprecation-policy/)および[APIの変更ガイドライン](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)のプロジェクトポリシーにおいては、シングルインスタンスの場合でも`kube-apiserver`のアップグレードの際にマイナーバージョンをスキップしてはなりません。
 {{< /note >}}
 
 ### kube-controller-manager、kube-scheduler、およびcloud-controller-manager