Fix blog links after migration from blog.kubernetes.io to kubernetes.io/blog

6 files changed, 7 insertions, 7 deletions

diff --git a/contributors/design-proposals/architecture/architecture.md b/contributors/design-proposals/architecture/architecture.md
index 1c3971f9..ff46f81f 100644
--- a/contributors/design-proposals/architecture/architecture.md
+++ b/contributors/design-proposals/architecture/architecture.md
@@ -65,7 +65,7 @@ The project is committed to the following (aspirational) [design ideals](princip
   approach is key to the system’s self-healing and autonomic capabilities. 
 * _Advance the state of the art_. While Kubernetes intends to support non-cloud-native
   applications, it also aspires to advance the cloud-native and DevOps state of the art, such as
-  in the [participation of applications in their own management](http://blog.kubernetes.io/2016/09/cloud-native-application-interfaces.html).
+  in the [participation of applications in their own management](https://kubernetes.io/blog/2016/09/cloud-native-application-interfaces/).
   However, in doing
   so, we strive not to force applications to lock themselves into Kubernetes APIs, which is, for
   example, why we prefer configuration over convention in the [downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api).
diff --git a/contributors/design-proposals/architecture/declarative-application-management.md b/contributors/design-proposals/architecture/declarative-application-management.md
index 14b3677c..a5fbdf24 100644
--- a/contributors/design-proposals/architecture/declarative-application-management.md
+++ b/contributors/design-proposals/architecture/declarative-application-management.md
@@ -30,7 +30,7 @@ What form should this configuration take in Kubernetes? The requirements are as
 
 * In particular, it should be straightforward (but not required) to manage declarative intent under **version control**, which is [standard industry best practice](http://martinfowler.com/bliki/InfrastructureAsCode.html) and what Google does internally. Version control facilitates reproducibility, reversibility, and an audit trail. Unlike generated build artifacts, configuration is primary human-authored, or at least it is desirable to be human-readable, and it is typically changed with a human in the loop, as opposed to fully automated processes, such as autoscaling. Version control enables the use of familiar tools and processes for change control, review, and conflict resolution.
 
-* Users need the ability to **customize** off-the-shelf configurations and to instantiate multiple **variants**, without crossing the [line into the ecosystem](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.g21b1f16809_5_86) of [configuration domain-specific languages, platform as a service, functions as a service](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/#what-kubernetes-is-not), and so on, though users should be able to [layer such tools/systems on top](http://blog.kubernetes.io/2017/02/caas-the-foundation-for-next-gen-paas.html) of the mechanism, should they choose to do so.
+* Users need the ability to **customize** off-the-shelf configurations and to instantiate multiple **variants**, without crossing the [line into the ecosystem](https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.g21b1f16809_5_86) of [configuration domain-specific languages, platform as a service, functions as a service](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/#what-kubernetes-is-not), and so on, though users should be able to [layer such tools/systems on top](https://kubernetes.io/blog/2017/02/caas-the-foundation-for-next-gen-paas/) of the mechanism, should they choose to do so.
 
 * We need to develop clear **conventions**, **examples**, and mechanisms that foster **structure**, to help users understand how to combine Kubernetes’s flexible mechanisms in an effective manner.
 
@@ -384,7 +384,7 @@ Consider more automation, such as autoscaling, self-configuration, etc. to reduc
 
 #### What about providing an intentionally restrictive simplified, tailored developer experience to streamline a specific use case, environment, workflow, etc.?
 
-This is essentially a [DIY PaaS](http://blog.kubernetes.io/2017/02/caas-the-foundation-for-next-gen-paas.html). Write a configuration generator, either client-side or using CRDs ([example](https://github.com/pearsontechnology/environment-operator/blob/dev/User_Guide.md)). The effort involved to document the format, validate it, test it, etc. is similar to building a new API, but I could imagine someone eventually building a SDK to make that easier.
+This is essentially a [DIY PaaS](https://kubernetes.io/blog/2017/02/caas-the-foundation-for-next-gen-paas/). Write a configuration generator, either client-side or using CRDs ([example](https://github.com/pearsontechnology/environment-operator/blob/dev/User_Guide.md)). The effort involved to document the format, validate it, test it, etc. is similar to building a new API, but I could imagine someone eventually building a SDK to make that easier.
 
 #### What about more sophisticated deployment orchestration?
 
diff --git a/contributors/design-proposals/architecture/resource-management.md b/contributors/design-proposals/architecture/resource-management.md
index 888bb21e..5b6d66b8 100644
--- a/contributors/design-proposals/architecture/resource-management.md
+++ b/contributors/design-proposals/architecture/resource-management.md
@@ -87,7 +87,7 @@ status:
 
 API groups may be exposed as a unified API surface while being served by distinct [servers](https://kubernetes.io/docs/tasks/access-kubernetes-api/setup-extension-api-server/) using [**aggregation**](https://kubernetes.io/docs/concepts/api-extension/apiserver-aggregation/), which is particularly useful for APIs with special storage needs. However, Kubernetes also supports [**custom resources**](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) (CRDs), which enables users to define new types that fit the standard API conventions without needing to build and run another server. CRDs can be used to make systems declaratively and dynamically configurable in a Kubernetes-compatible manner, without needing another storage system.
 
-Each API server supports a custom [discovery API](https://github.com/kubernetes/client-go/blob/master/discovery/discovery_client.go) to enable clients to discover available API groups, versions, and types, and also [OpenAPI](http://blog.kubernetes.io/2016/12/kubernetes-supports-openapi.html), which can be used to extract documentation and validation information about the resource types.
+Each API server supports a custom [discovery API](https://github.com/kubernetes/client-go/blob/master/discovery/discovery_client.go) to enable clients to discover available API groups, versions, and types, and also [OpenAPI](https://kubernetes.io/blog/2016/12/kubernetes-supports-openapi/), which can be used to extract documentation and validation information about the resource types.
 
 See the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md ) for more details.
 
diff --git a/contributors/devel/architectural-roadmap.md b/contributors/devel/architectural-roadmap.md
index afe37b1a..04a9002a 100644
--- a/contributors/devel/architectural-roadmap.md
+++ b/contributors/devel/architectural-roadmap.md
@@ -761,7 +761,7 @@ therefore wouldn’t be considered to be part of Kubernetes.
       applications, but not for specific applications.
 
     * Platform as a Service: Kubernetes [provides a
-      foundation](http://blog.kubernetes.io/2017/02/caas-the-foundation-for-next-gen-paas.html)
+      foundation](https://kubernetes.io/blog/2017/02/caas-the-foundation-for-next-gen-paas/)
       for a multitude of focused, opinionated PaaSes, including DIY
       ones.
 
diff --git a/contributors/devel/container-runtime-interface.md b/contributors/devel/container-runtime-interface.md
index a408b60a..1a121c9e 100644
--- a/contributors/devel/container-runtime-interface.md
+++ b/contributors/devel/container-runtime-interface.md
@@ -51,7 +51,7 @@ The old, pre-CRI Docker integration was removed in 1.7.
 
 ## Specifications, design documents and proposals
 
-The Kubernetes 1.5 [blog post on CRI](http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html)
+The Kubernetes 1.5 [blog post on CRI](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
 serves as a general introduction.
 
 
diff --git a/contributors/devel/e2e-tests.md b/contributors/devel/e2e-tests.md
index 861c6001..dc148675 100644
--- a/contributors/devel/e2e-tests.md
+++ b/contributors/devel/e2e-tests.md
@@ -710,7 +710,7 @@ system to 30,50,100 pods per/node and measures the different characteristics of
 the system, such as throughput, api-latency, etc.
 
 For a good overview of how we analyze performance data, please read the
-following [post](http://blog.kubernetes.io/2015/09/kubernetes-performance-measurements-and.html)
+following [post](https://kubernetes.io/blog/2015/09/kubernetes-performance-measurements-and/)
 
 For developers who are interested in doing their own performance analysis, we
 recommend setting up [prometheus](http://prometheus.io/) for data collection,